Garrett's Tech Musings

For my current project, I’ve been researching Facebook Connect.  As I’ve been digging into it, I’ve been thinking about the huge vulnerability in using third-party authentication methods such as OpenId, Live ID, and Facebook Connect.  The problem, which people have highlighted in the past, is that you are now reliant upon another company to be available for your users to log in to your site.

The reality of this situation has been brought home over the past week for me.  I’m going on day 6 of not having access to Facebook.  The login page just tells me that my account is “temporarily unavailable due to site maintenance” and it should be back “within a few hours.”  Easy means of support is pretty much unavailable, which is sort of understandable for a site that boasts more than 300 million active users (and growing).  Unfortunately, there’s nobody to contact for any sort of problem, and all I can find is a few blogs where other people are having the same problem.

Just a few more hours...

So imagine the hypothetical case that some of your users had registered for your site using Facebook Connect, they normally come in and simply login using their Facebook ID on the Facebook login page, and over time they’ve entered a wealth of information under this account.  Now all of a sudden, they can’t get in to your site since Facebook is “undergoing maintenance” for days on end.  With Facebook being unavailable for support, they’ll more than likely turn to your company for answers.  Unfortunately, Facebook, as they say, has no skin in the game so there is no motivation for them to fix the problem.

Just a few things to think about when relying on a third party for authenticating your users.  It adds convenience when all is well, but it could mean a lot of unhappy users if something breaks.

With the pending introduction of Microsoft’s Geneva Framework and Geneva Server (now officially named Windows Identify Foundation and Active Directory Federation Services, respectively), a claims-based and federated security model is now available to the .NET world.  The use of SAML-based authentication tokens distributed by Secure Token Servers (STS’s) is primed to be the next step in providing a more simplified identity management scheme throughout organizations and beyond into the “cloud” of Azure and Internet-based systems.

Claims-based authentication scenario

If you haven’t been exposed to the concept of claims-based security, it’s a bit of a mind-shift from how application rights and user properties have been typically implemented so it may take some time to fully grasp.  A claim, to put it simply, is any attribute that can be ascribed to a user (or any resource).  For example, a user’s claims may consist of his name, birth date, gender, and role within an organization.

What makes this different from traditional role-based security is that these claims are authenticated by a trusted third-party.  One of the best analogies is to think of a person going to buy alcohol at a bar.  The bartender must prove that the person is of legal age so he asks for an authenticated record from a trusted third-party, which in this case is a driver’s license from the DMV.  The claim is that this person is over 21 years old, and the identity provider is the Department of Motor Vehicles.

A Boon to Developers and Organizations

OK, so this is all well and good but how does this make developing applications easier?  The short answer is that claims alone don’t make things much easier, but what does simplify matters is the use of federated authentication.  In our previous example, the bar knew nothing about the person buying a drink.  There was no big filing cabinet with everybody’s name and birth records stored in the back room of the bar (at least you hope not).  The problem is that this is how many applications work today.  Each application stores off its own set of users and profile data, and therefore, the application (and consequently, the application developers) must be responsible for authenticating users.

By utilizing federation, the job of validating that a user is who he claims to be is now handed off to a third party, and a trust is established between our application (the relying party, or RP).  If our identity provider (IP) says that Joe Smith is really Joe Smith, we can trust that this is true.  Immediately, you can probably see that this is a boon for developers everywhere, who are tired of creating user login pages and databases.  In addition, this now enables Single Sign-On (SSO) within a network of applications that share the same IP.

Putting it All Together

Now that you can probably see how claims and federated security can be of benefit, the next question is how all of this works within the current world of application security.  The good news is that Microsoft seems to have done an admirable job of building on top of existing technologies (e.g., Active Directory and ASP.NET authentication) and providing flexibility to leverage existing security mechanisms (e.g., OpenID, Live ID, etc.).

The Geneva Framework is a set of assemblies that forms the foundation of the entire security suite.  Using the Framework (otherwise known as Windows Identity Foundation, or WIF), developers can claims-enable their ASP.NET applications with just a handful of configuration settings.  In addition, WIF can be used to create a custom Secure Token Server (STS) that can perform user authentication and claims look-ups using any technique imaginable.  This open foundation will encourage developers and IT organizations to move towards this model.  In addition, Geneva Server is a robust and freely available STS that can be rolled out within an organization, making federated security a reality in fairly short order.

Further Reading

This discussion barely scratches the surface and depth of Geneva so I would encourage you to read more on the blogs and Microsoft sites out there:

• Vibro.Net – Vittorio Bertocci is a Microsoft architect/evangelist and a prolific blogger on Geneva
• Geneva Framework Whitepaper for Developers
• Microsoft Identity Management Developer Center

The new Active Directory Federation Services (formerly named Geneva Server) is an extensible Secure Token Server (STS) that enables claims-based authentication. When an application requests for a user to be authenticated against AD FS, it not only expects back a valid token stating the user’s identity, but it can also specify a set of claims (user attributes) to be returned in the form of a SAML token. These claims are not stored within AD FS but instead reside in an externally configured Attribute Store.

Out of the box, AD FS provides several options for the Attribute Store: an LDAP source (such as Active Directory DS), SQL Server, or a custom store defined in a .NET library. In many situations, there may not be a single source for all of the user’s profile data (e.g., birth date, email address, phone numbers, etc.) In these situations, AD FS gives you the ability to have several stores and then determine which attribute store to use based on the claim being requested. Setting up this within AD FS (at least in the beta version) is not the most intuitive process.

Configuring Attribute Stores

The first step is to configure the attribute stores within AD FS, which is accomplished in the Attribute Stores section. An Active Directory store which points to the domain AD instance is setup by default so that’s taken care of. Next, we will need to add our secondary attribute store. When you add a new store, you will see that you have three options: Active Directory, LDAP, or SQL. For an LDAP or SQL source, you simply need to provide a connection string. For my application, I needed to access a SQL Server instance, so I just gave it a unique name and plugged in the SQL connection string.

AD FS Attribute Store

Claim Rules

Once the attribute stores have been setup, you need to setup claims rules either at the Relying Party or Identity Provider level to dictate which claims will be retrieved from which attribute store. Optionally, these claims can also be converted into another claim. Both of these tasks are accomplished using Microsoft’s new claim rule language. The syntax for defining claims transformations is sparsely documented at this point, and the only definitive source that I’ve found is on TechNet: http://technet.microsoft.com/en-us/library/dd807118%28WS.10%29.aspx.

To access the user data that’s stored in our SQL Server database, we need to write the query using a claim rule. Within the Relying Parties section, right click on the appropriate application and select “Edit Claim Rules…” Next, we will need to create an Advanced Rule since there currently isn’t a nice wizard to step us through this process. Within the rule definition window, type up your rule using syntax such as below:

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/dateofbirth"]
=> issue(store = "AdventureWorks Attribute Store", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/dateofbirth"), query = "SELECT BirthDate FROM [HumanResources].[Employee] WHERE LoginID = {0}", param = c.Value);

This isn’t an easy mechanism and hopefully Microsoft polishes this interface in future releases, but in the end, we do have claims being sourced from multiple locations, which will be very useful when developing a claims-enabled application.