The 15 Factors of ASP.NET — Authentication and Authorization

One of the 15 factors that I discuss in my free O’Reilly eBook, Beyond the 12 Factor Application, is Authentication and Authorization. Security is critical for every application you deploy.

Even if you’re planning on allowing completely anonymous access to your application, everyone involved with this application needs to be aware of its security needs. Are you using SSL? If so, where are you terminating the SSL? Are you using client certificate validation? How will users authenticate to the site? If they authenticate, how do you authorize what actions they can perform?

All of these questions need to be answered in great detail before you deploy your application. As I mention in the book, security cannot be an afterthought and you should know the security profile of your application as soon as possible (ideally before the first iteration).

In this blog post, I’m going to discuss the various authentication and authorization options available to ASP.NET developers, with special emphasis on those people who are working on legacy ASP.NET applications and looking to move them onto a scalable PaaS (Platform as a Service) foundation like Cloud Foundry.

Windows and Basic HTTP Authentication

When building applications for an intranet, Windows authentication has historically been the easiest and most widely used form of site authentication. This makes total sense because in a classic Microsoft-based enterprise, all your intranet servers (physical or virtual) ran Windows, they were all joined to a domain, were remotely configured via policy and other Microsoft management tools like SMS, etc. Most importantly, in these enterprises, the users all had accounts in an Active Directory, and you could often infer their roles and privileges from their AD groups.

This made perfect sense, and you’d see the incredibly simple configuration in a Web.config file that looked like this:

<authentication mode="Windows" />

But what do you do in the cloud? What do you do when your application could move between data centers at a moment’s notice, when the host operating system is created and destroyed frequently, and is not a part of your domain?

Whether you end up using Basic HTTP Auth or direct challenge windows authentication, Integrated Windows authentiation in the cloud is an anti-pattern. I’ll talk about alternatives near the end of the post.

Forms Authentication (Cookies)

Probably the second most common form of authentication on ASP.NET websites is forms authentication. In this model, your website is configured something like this:

<authentication mode="Forms">
   <forms forms="myApp" loginUrl="/login.aspx" />
</authentication>

Your app is responsible for detecting when users are logged in (cookie detection), authentication and authorization, and presenting the appropriate screens. ASP.NET makes a lot of this very easy, and a lot of implementations like this are backed by databases.

There’s nothing about this pattern that makes it automatically “bad” for the cloud, but there are ways to make it difficult or awkward, like relying on the existence of some types of infrastructure that might not be available when running in the cloud.

Bearer Tokens, SSO, and Federation

With Windows authentication not being a viable option, and plain old cookies feeling old and stale, what do you do for your enterprise intranet application? What about for your public-facing site that you also want to run in the cloud?

Thankfully there are a number of modern standards available to you as an ASP.NET developer that you can use, all of which are based on the concept of a bearer token. The idea is simple — you delegate the certification of a user’s identity to someone else and you accept as proof of that identity a signed token. Some very common bearer token authentication schemes include:

• OpenID
• OpenID Connect
• OAuth2
• SAML

Applications that accept authentication information this way can allow users to log in securely with their Facebook credentials, their Google account, LinkedIn, Github, etc.

For intranet applications, your enterprise can stand up its own identity provider. You can still use an active directory, but instead of communicating directly with it, your IDP is issuing tokens based on that directory. For example, an extremely common migration strategy for intranet ASP.NET sites is to move from integrated Windows auth to a SAML-based scheme where the application gets tokens issued by an Active Directory Federation Services server.

If you’re using ASP.NET Web API, you can create an Authentication Filter that will deal with token validation, redirection, and establishment of a user context based on supplied bearer tokens. A quick google search for ASP.NET authentication and ADFS should give you a plethora of examples illustrating how to do this.

If you’re using legacy ASP.NET Web applications, you can create your own custom authentication module (or find one already created). Also, if you pick a third party Identity Provider like Google or Stormpath or Auth0, then those providers publish sample code that illustrates what you’ll need to do to port your application to the new security scheme.

Summary

The good news is that security and the cloud are not mutually exclusive. The bad news is you need to avoid relying upon security mechanisms that are proprietary or have specific OS-level requirements placed on the servers hosting your apps.

What I particularly like about solutions like OAuth2 and OIDC is that solving this problem for one application often results in a solution that can be reused across an entire organization and sometimes even results in a more secure, more robust security solution overall.

Either way, if you’re an ASP.NET developer looking to move your application to the cloud, you should know that you have plenty of security solutions available to you — some provided by PaaS hosts like Azure and Cloud Foundry, others by third parties like Stormpath, Google, and Auth0, or you can roll your own. The key is to put some thought and discipline into how you’re going to secure your apps early.

p.s. I know that a thing once existed called Passport authentication but I’m not going to mention it. The memories are simply too painful.