I’ve spoken to many people recently about enabling Microsoft SharePoint 2010 to work with Claims to enhance both Authentication and Authorization in SharePoint. I’m finding that many people are still trying figure out where all the pieces fit in a SharePoint architecture that makes use of claims – there are new concepts to understand and often new infrastructure to be configured. Overall the concepts tend to be easier to understand than people realize once they dig into them a little. This article is designed to explain the concepts and applications required in one example of a SharePoint 2010 architecture which enables Claims Based Authentication and Authorization.
If you are completely new to the concept of claims I would suggest reading the following article as a primer: What are Claims – Using of Claims in SharePoint.
Lets start with a diagram of what a SharePoint server architecture that uses Claims can potentially look like. The following is just one example of such a server architecture. Depending on your requirements, you may have need of more or less components, but this serves as a good basis for this discussion. As well, you will note that I’ve left out a few components that may be required just for simplicities sake (ex. a domain controlled).
Microsoft SharePoint 2010 Server Architecture with Claims
This architecture involves a number of server applications which form the SharePoint server and the trusted identity provider. It also shows the sequence of messages involved in authenticating a user to SharePoint 2010 at Sign In time using claims based authentication. At a high-level, if you follow the message sequence you get the following series of actions:
-
1. From the end user’s perspective, they simply pull up their web browser, navigate to the SharePoint 2010 URL, enter their user name and password and click Sign In. These credentials are sent to the SharePoint server.
- A trust relationship between SharePoint 2010 and ADFSv2 (so ADFSv2 trusts an incoming request from SharePoint and so that SharePoint trusts a response from ADFSv2)
- The claims that ADFSv2 will include in a response to an authentication request (these are called ClaimsDescriptions or ClaimTypes in ADFSv2)
- The Active Directory attributes which ADFSv2 must retrieve when a SharePoint request comes in
- How to map or transform the retrieved AD attributes to claims that SharePoint 2010 is expecting
2. In this architecture, SharePoint 2010 is configured to perform claims based authentication and connect to a trusted identity provider. SharePoint will pass the user’s credentials to the trusted identity provider and request authentication and a token.
3. The trusted identity provider in this case is made up of a ‘Secure Token Server’ and a data source (database or LDAP directory). The secure token server is Active Directory Federation Services version 2.0 (ADVSv2) in this case, and our data source is Active Directory. ADFSv2 will connect to Active Directory to retrieve attributes about the user signing in. In configuring ADFSv2, you’ll configure several things but there are 4 configurations that are most critical:
4. ADFSv2 will authenticate the user (validate that their username and password are correct) and create a token. With ADFSv2 the token created can be one of 2 standards-based formats: either SAML 1.1 or WS-Federation. The token will be digitally signed before it is returned to the calling application. The token can also be encrypted if the environment requires it.
5. The signed token is then returned to the calling application, in our case SharePoint 2010. This is done using either the SAML 2.0 protocol or the WS-Federation protocol depending on the configuration of ADFSv2. Note: SharePoint 2010 supports SAML 1.1 for the token format, and SAML 2.0 for the protocol.
Once SharePoint receives the token, it will then validate the digital signature on it to ensure that it can trust the token and the claims within it. Once this process is complete and the signature has been validated, the user is now logged into SharePoint. SharePoint now has the current user’s claims in memory (in the SPUser object) and SharePoint knows that it can trust them. At this point, the authentication process is complete. We can now do some interesting things with those claims like implement authorization policies that are very specific to this user at that particular point in time.
Lets take a look at that diagram again and describe the different components involved from an authorization perspective. You’ll notice that I’ve added a few new components/concepts.
Using Claims for Authorization in SharePoint 2010
Trusted Identity Provider
This component is often made up of a Secure Token Server and a data source (database or LDAP directory). The architecture shown here is geared towards a deployment within a corporate environment. However, with additional configuration SharePoint 2010 could be configured to connect to a third party trusted identity provider on the Internet. As well, identity providers like ADFSv2 can be used to enable Federation so that users outside the corporate network can sign in and access SharePoint as well.
Secure Token Server (ADFSv2)
The secure token server is a 3rd party that sits between SharePoint 2010 and Active Directory – it is part of the trusted identity provider. In our case the secure token server is Active Directory Federation Services version 2.0. There are other 3rd party secure token servers out there that can also be used. You can even chain secure token servers together for various advanced authentication requirements.
When configuring ADFSv2 you have to configure a Trust Relationship with each application that is going to call it for authentication and expect a token back as a response. ADFSv2 has a nice wizard for doing this, but you do need to be careful. Although the process is not too difficult, it is not very forgiving. If you make a typo you often have to start over and some creative powershell’ing may be involved. This trust relationship is called a Relying Party Trust – the Relying Party is the calling application, in our case SharePoint.
Data Source (Active Directory)
The secure token server needs to be configured to talk to a data source. This can be any LDAP directory or SQL database. In our case we’re using Active Directory. In fact, ADFSv2 will automatically be configured to use Active Directory as a data source to retrieve user attributes. At minimum, ADFSv2 requires an Active Directory install to have a service account, but it can be configured to use other LDAP directories (of the non-AD variety) or databases as its primary source of attributes. It can even be configured to use multiple data sources at once.
We have seen some issues in the field with in using ADFSv2 with non-AD directories when doing forms based authentication to SharePoint. Those are still under investigation though and I’ll post more info here when we have it. Let us know if you have any tips on getting this to work or if you’ve run into similar issues.
In configuring our Active Directory here, there really wasn’t anything special to do. We used a standard Active Directory instance. However, using claims does require some thought around which attributes you are going to use in your policies. You can use the standard attributes present, as AD has quite an extensive schema already. Or, you can add custom attributes to AD and make use of those – there are many blogs and articles out there on how to do this. Just be aware that when you add custom attributes to AD, they cannot be removed so the change is permanent. It is worth looking to see if an appropriate attribute already exists before adding new ones.
Microsoft SharePoint Server 2010
Here we’re using Microsoft SharePoint Server 2010. Claims support was only introduced in SharePoint 2010, so these concepts are not supported in Microsoft Office SharePoint Server 2007 (MOSS). In this case, SharePoint is configured to perform claims based authentication using a trusted identity provider. SharePoint can be configured in several ways to perform this type of authentication without necessarily connecting to a separate server application that acts as the trusted identity provider – for some small businesses, this could be a very viable configuration. However, from a scalable and flexible enterprise perspective it is often recommended to use a separate server as the trusted identity provider.
Once the ClaimTypes (or ClaimsDescriptions) are defined in ADFSv2 that will be returned to SharePoint, you will need to run some PowerShell scripts on the SharePoint server in order to map those Claims so that SharePoint is expecting them and can read them. For some details on those scripts, please see one of my earlier blog posts (look inside the attached deck on that post): Using Claims to Strengthen Data Governance.
SAML or WS-Federation Tokens
SharePoint can work with 2 different format of tokens: SAML 1.1 or WS-Federation. You configure which token to use when you configure the Relying Party Trust in ADFSv2. Keep in mind that the token is different from the protocol. Although SharePoint 2010 supports the SAML 1.1 token specification, it uses the SAML 2.0 protocol for communication.
The token you chose will depend very much on your requirements. We’ve had success configuring either SAML or WS-Federation tokens, although there are distinct differences between the 2 – details on those can be found at this excellent blog post on SAML vs WS-Federation. Please note, this article compares SAML 2.0 to WS-Federation, and not SAML 1.1.
Overall, a big advantage of SAML is that it is standards-based (developed by the OASIS group) and does not have dependencies on other WS-* services. Although I have not tried it myself, I have also been told that if you need to actually encrypt the token (not just sign it) that this can be challenging to do with WS-Federation. So, if you are working within a corporate environment where you can rely on being completely or almost completely within a Microsoft environment and digitally signing tokens is sufficient, then using either WS-Fed or SAML tokens should be fine. However, if you need to connect ADFSv2 to another secure token server (which speaks SAML), or if you need SharePoint to pass the token onto another service then you’ll likely need to use the SAML format.
Claims Rules (and the Claims Rule Language)
ADFSv2 has the ability to modify or transform claims before they are sent back to the calling application. This is a very useful feature for enabling certain policy requirements to be realized. For example, you can combine various attributes together, or issue different attributes depending on the existance of certain attributes or on the values themselves. For each relying party trust in ADFSv2 you can configure one or more claims rules – you must configure at least one or no claims will be returned to SharePoint. When configuring this, there are several templates to choose from, or you can use the Claims Rule Language to define very specific logic for how claims are returned to SharePoint.
The simplest claims rule involves just mapping an attribute from AD to a claim defined in ADFSv2. For example, you can configure a rule that retrieves the organizationalStatus attribute from AD and maps it to an EmployeeStatus claim that is defined in ADFSv2 and that SharePoint is expecting. Here we are just mapping an attribute name to a claim description. You may or may not need to change the name of the attribute when mapping it a claim as we have here, but you are able to if needed.
Other templates exist as well for performing simple modifications on attributes before they get sent back as claims. They can also help you retrieve all the groups a user belongs to and send them back to SharePoint all listed in 1 claim. As well, the claims rule language built into ADFSv2 is very useful for transforming claims to meet specific policy needs. More on that in a future blog post.
Custom Claims Provider in SharePoint 2010
Within SharePoint itself, you can choose to use something called a Custom Claims Provider. This is not required, but can be a useful option for various policy requirements. There is a default claims provider built into SharePoint, but you can build and deploy one or more of your own with its own custom logic. A custom claims provider is a piece of code that runs on the SharePoint server itself and is deployed as a SharePoint feature receiver.
In our configuration, after a user has authenticated to SharePoint through a trusted identity provider, SharePoint will then call each of the custom claims providers that it has currently deployed. The claims provider has 2 purposes:
- A custom claims provider can access any claims returned from the trusted identity provider and modify them (also called augmenting them).
- A custom claims provider can be used as an alternative to a trusted identity provider – it can be built to connect to a data source like a SQL database, retrieve attributes about the user or perhaps about the current environment (like the connection type) and set those as claims in the currently logged in user’s identity
Again, using a custom claims provider is just an option, but it can be a very useful option in retrieving additional data that can be used as a claim in determining what content is user is permitted or not permitted to see.
Summing It All Up…
Overall, a claims based architecture for SharePoint does involve some planning, some decisions about what components to use, possibly some development and some configuration. The requirements will vary based on the complexity of your business, your environment and your policies. Microsoft SharePoint 2010, Active Directory Federation Services v2.0 and other Microsoft components provide many useful options to use in making these decisions and hopefully some of the insight in this article will help clarify these options.
-Antonio
