Asp.net "disable" authentication in the development environment

Question

Is it possible to "disable" authentication in the main asp.net application without changing its logic?

I have a .net site that uses an external authentication server application for authentication. In any case, I would like to be able to make fun of authentication when I develop it (ASPNETCORE_ENVIRONMENT = Development), transferring access to all actions, ignoring authorization attributes.

Is it possible to simply mock some services in the collection of services?

Answer 1

I found a solution to this problem on the illucIT blog .

This code should work:

if (env.IsDevelopment()) { services.AddMvc(opts => { opts.Filters.Add(new AllowAnonymousFilter()); }); } else { services.AddMvc(); } 

Answer 2

It is difficult to give a detailed answer without any details about your end, but I have already achieved this by conditional registration:

• external authentication middleware
• global policy requiring authenticated request

it looked something like this:

 public class Startup { public Startup(IHostingEnvironment env) { Environment = env; } public IHostingEnvironment Environment { get; } public void ConfigureServices(IServiceCollection services) { services.AddMvc(x => { if (!Environment.IsDevelopment()) { var authenticatedUserPolicy = new AuthorizationPolicyBuilder() .RequireAuthenticatedUser() .Build(); x.Filters.Add(new AuthorizeFilter(authenticatedUserPolicy)); } }); } public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory) { app.UseStaticFiles(); if (!Environment.IsDevelopment()) { // Register external authentication middleware } app.UseMvc(routes => { routes.MapRoute( name: "default", template: "{controller=Home}/{action=Index}/{id?}"); }); } } 

In my case, the authorization filter was applied globally, so an authenticated user is required for each action of the MVC application.

If you have different requirements - small [Authorize] attributes for some actions - then you can probably achieve the same result by changing the way you create associated authorization policies. They generally cannot contain any requirements.

 AuthorizationPolicy yourCustomPolicy = null; if (Environment.IsDevelopment()) { yourCustomPolicy = new AuthorizationPolicyBuilder().Build(); } else { yourCustomPolicy = new AuthorizationPolicyBuilder() // chaining appropriate methods to suit your needs .Build(); } 

Answer 3

Another solution you might want to consider is to use the IPolicyEvaluator. This means that you can retain all existing security features.

 public class DisableAuthenticationPolicyEvaluator : IPolicyEvaluator { public async Task<AuthenticateResult> AuthenticateAsync(AuthorizationPolicy policy, HttpContext context) { // Always pass authentication. var authenticationTicket = new AuthenticationTicket(new ClaimsPrincipal(), new AuthenticationProperties(), JwtBearerDefaults.AuthenticationScheme); return await Task.FromResult(AuthenticateResult.Success(authenticationTicket)); } public async Task<PolicyAuthorizationResult> AuthorizeAsync(AuthorizationPolicy policy, AuthenticateResult authenticationResult, HttpContext context, object resource) { // Always pass authorization return await Task.FromResult(PolicyAuthorizationResult.Success()); } } 

In Startup.cs, make sure this is displayed at the top of the ConfigureServices method. For instance.

  public void ConfigureServices(IServiceCollection services) { if (env.IsDevelopment()) { // Disable authentication and authorization. services.TryAddSingleton<IPolicyEvaluator, DisableAuthenticationPolicyEvaluator>(); } ...