Home > .NET, Identity Management > Configuring Multiple Attribute Stores in Geneva Server

Configuring Multiple Attribute Stores in Geneva Server

September 30th, 2009 Leave a comment Go to comments

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

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.

Categories: .NET, Identity Management
  1. No comments yet.
  1. No trackbacks yet.