I noticed that almost all of my most recent blog posts on the new claims features of SharePoint 2010 involve using ADFS 2.0 in some way. However, I don’t want to leave folks with the impression that this is a requirement. In fact, when SharePoint 2010 reaches RTM, you’ll be able to happily federate SharePoint 2010 directly to OpenID, Windows Live, or any other identity provider out there without needing to go through ADFS 2.0 at all. However, there some interesting capabilities that ADFS 2.0 provides that might lead one to consider it.
One of those features is the ability to enhance an authenticated user’s claims with additional data residing in an attribute store. ADFS 2.0 supports three kinds of attribute stores: Active Directory, LDAP, and SQL. ADFS 2.0’s custom rules engine allows you to connect to these stores, match records up on the claims you have so far, and add new ones to the token. This capability is particularly suited for managing the entitlements a user should have in the target system (SharePoint 2010 in our case). This turns out to be fairly easy to do.
To start out, I created a simple database in SQL to store my user entitlements. Hopefully, this diagram is pretty self-explanatory:
Next, I added a record that represents my test OpenID account (by email address), added some roles, and assigned my account to those roles. The result looks like this:
So you can see my test account holds both the “Product A Admin” and “Product B Viewer” roles. Next, I switched over to ADFS 2.0 and created a new Attribute Store by right-clicking the “Attribute Stores” container. You can see that only the attribute store type and connection string is necessary at this point.
Now comes the fun part. We right-click “Relying Party Trusts” and add the following custom rule, which is mostly based on our SQL query:
c:[Type == “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress”]
=> issue(store = “SP2010 Entitlements”, types = (“http://schemas.microsoft.com/ws/2008/06/identity/claims/role”), query = “SELECT dbo.Roles.Name FROM Users INNER JOIN RoleAssignment ON Users.UserID = RoleAssignment.UserID INNER JOIN Roles ON Roles.RoleID = RoleAssignment.RoleID WHERE Users.EmailAddress = {0}”, param = c.Value);
The nice thing here is the rule uses the current email address claim to filter the SQL query. For each row returned by the query, it’s value is packaged in it’s own Role claim. The end result in SharePoint 2010 looks like this:
These Role claims can then be used to manage entitlements within SharePoint (via the User Picker).
So as you can see, we now have a straightforward way to assign and manage user entitlements in SharePoint 2010 without having to touch Active Directory groups. This has great benefits to pubic-facing SharePoint 2010 sites that want to provide premium content for, say, subscribers.
I’d also like to point out that this very thing can be done without ADFS 2.0. So see what that’s about, take a look at the excellent article: “Writing a Custom Claims Provider for SharePoint 2010 Part 1” by “Steve” (Share-n-dipity).
One of those features is the ability to enhance an authenticated user’s claims with additional data residing in an attribute store. ADFS 2.0 supports three kinds of attribute stores: Active Directory, LDAP, and SQL. ADFS 2.0’s custom rules engine allows you to connect to these stores, match records up on the claims you have so far, and add new ones to the token. This capability is particularly suited for managing the entitlements a user should have in the target system (SharePoint 2010 in our case). This turns out to be fairly easy to do.
To start out, I created a simple database in SQL to store my user entitlements. Hopefully, this diagram is pretty self-explanatory:
Next, I added a record that represents my test OpenID account (by email address), added some roles, and assigned my account to those roles. The result looks like this:
So you can see my test account holds both the “Product A Admin” and “Product B Viewer” roles. Next, I switched over to ADFS 2.0 and created a new Attribute Store by right-clicking the “Attribute Stores” container. You can see that only the attribute store type and connection string is necessary at this point.
Now comes the fun part. We right-click “Relying Party Trusts” and add the following custom rule, which is mostly based on our SQL query:
c:[Type == “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress”]
=> issue(store = “SP2010 Entitlements”, types = (“http://schemas.microsoft.com/ws/2008/06/identity/claims/role”), query = “SELECT dbo.Roles.Name FROM Users INNER JOIN RoleAssignment ON Users.UserID = RoleAssignment.UserID INNER JOIN Roles ON Roles.RoleID = RoleAssignment.RoleID WHERE Users.EmailAddress = {0}”, param = c.Value);
The nice thing here is the rule uses the current email address claim to filter the SQL query. For each row returned by the query, it’s value is packaged in it’s own Role claim. The end result in SharePoint 2010 looks like this:
These Role claims can then be used to manage entitlements within SharePoint (via the User Picker).
So as you can see, we now have a straightforward way to assign and manage user entitlements in SharePoint 2010 without having to touch Active Directory groups. This has great benefits to pubic-facing SharePoint 2010 sites that want to provide premium content for, say, subscribers.
I’d also like to point out that this very thing can be done without ADFS 2.0. So see what that’s about, take a look at the excellent article: “Writing a Custom Claims Provider for SharePoint 2010 Part 1” by “Steve” (Share-n-dipity).
