I was working with one of my ASP.NET projects this weekend and ran into an interesting

problem while I was debugging.  This application was written from the ground up to use ASP.NET identity and OAuth security for all of my authentication and authorization needs.  That also means that my application follows the new default layout for an ASP.NET web forms application, with account management and login capabilities reside in the /Account folder structure.

An interesting series of things happens to web.config when we adapt the OAuth security management in ASP.NET 4.5+  What follows is what I have learned the hard way…

Authentication Information in Web.Config disappears

If you’re a long time developer with ASP.NET like me, you’re accustomed to the FormsAuthentication configuration in web.config.  With the new authentication and identity modules in ASP.NET 4.5, all of this goes away.  This really tweaked me at first, I got confused and followed the code… and trust me, its all good.

Web.Config has its authentication turned off and all identity providers removed.  Check out this snippet from a fresh web.config in a new ASP.NET 4.5 application:

  <system.web>
    <authentication mode="None" />
    <!-- other stuff -->
    <membership>
      <providers>
        <clear />
      </providers>
    </membership>
    <profile>
      <providers>
        <clear />
      </providers>
    </profile>
    <roleManager>
      <providers>
        <clear />
      </providers>
    </roleManager>
    <!-- other stuff -->
    </system.web>
  <system.webServer>
    <modules>
      <remove name="FormsAuthentication" />
    </modules>
  </system.webServer>

That’s some scary stuff right there.  Everything that I’ve known since ASP.NET was released in 2002 screams out: NOOOOOooooooo!  This is the necessary configuration to turn off all of the embedded and automatically activated security modules in ASP.NET  With that functionality shut off, the OAuth security module can step in.

OAuth Security Configuration

Instead, all of the security configuration goodness is kicked off in a new OWIN-compliant manner from within Startup.cs on the root of the application.

[assembly: OwinStartup(typeof(MyApplication.Startup))]

namespace MyApplication
{
  public partial class Startup
  {
    public void Configuration(IAppBuilder app)
    {
      ConfigureAuth(app);
      app.MapSignalR();
    }
  }
}

Check out that attribute at the top of the file, an OwinStartupAttribute that points to this class that contains the codified configuration of the application.  The class is required to have a Configuration method with the same signature in this snippet.  I’m not clear why the class does not adhere to an interface that enforces the presence of this method, but this is the requirement.  You can see from here, that it calls the ConfigureAuth method in the App_Start/Startup.Auth.cs file.  Its in there that we can find all of the configuration for managing the authentication of resources in the application.

public void ConfigureAuth(IAppBuilder app)
{
 
  // Stuff to configure the Identity data storage
  
  // Enable the application to use a cookie to store information for the signed in user
  // Configure the sign in cookie
  app.UseCookieAuthentication(new CookieAuthenticationOptions
  {
      AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
      LoginPath = new PathString("/Account/Login")
      // other stuff
  });
  
  // more stuff down here
}

This is where I was thrown for a loop.  How does ASP.NET know where my login page is?  Its defined right here with the LoginPage configuration property inside of the CookieAuthenticationOptions class.

How is Authorization Handled?

Finally, how is authorization to pages handled?  In the past, I would write blocks of XML with authorization elements that looked similar to the following…

  <location path="Admin">
    <system.web>
      <authorization>
        <deny users="?" />
        <allow roles="Admin" />
      </authorization>
    </system.web>
  </location>

The good news is that none of that has changed, and we can continue to code high-level authorization rules inside of web.config files in ASP.NET 4.5.

Summary

Its not a good idea to tinker with the default security configuration of ASP.NET unless you know where all of the moving pieces are.  In the past, I knew where everything was referencing from web.config through global.asax.cs to verify connections to my application where authenticated and authorized. In the new Owin enabled ASP.NET, those pieces have moved and are now very descriptive in their new locations.  Coming soon, I have a Pluralsight course that will discuss all of the cool things that you can do to configure ASP.NET OWIN security and other Advanced topics.  I look forward to delivering it for you in the very near future.