Blog

Imagine a world where you don’t have to worry about handling authentication for different types of users of your application.  In modern day information technology, businesses want to interoperate with other businesses, and government organizations want to provide more integrated services to citizens.  However, different systems use different authentication systems and businesses want to integrate in a secure, legally compliant manner.

Given this environment where user accounts and applications are located in completely different networks or organizations, imagine that every request to your application already includes the information you need to make access control decisions, to allow seamless single-sign-on (SSO) entry , and to personalize the application for the user. Enter claims-based authentication.

Claims-based authentication enables systems and applications to authenticate a user without requiring the user to disclose more personal information (such as social security number or date of birth) than necessary. But what are claims?  In its simplest form, a claim is comprised of statements made about a user so that they can permitted to access to an application. Each statement (for example name, identity, group) corresponds to a value that is stored in the claim.

The diagram below demonstrates the simple and fundamental process behind claims-based authentication:

Untitled-300x276_0.png

An example of claims-based authentication is someone claiming to be over 18 years old or someone claiming to be in a company's HR group. An external system/application (relying party) needs only to trust the attribute store that can validate those claims to allow the user to be authenticated for specific functions. The attribute store is sometimes also referred to as a trusted authority/issuer or an authentication authority.

Another key cog in claims-based authentication is the Secure-Token-Service (STS) which depends on the trusted store to verify the claim made by the user.  The STS then creates and returns a token to the relying party, which authenticates the user based on the validity of the signed token issued back from the STS. With claims-base authentication, the components of the token itself is at the core of the design and it consists of a set of one or more claims.

In a typical SharePoint 2010 implementation, the relying party would actually be SharePoint itself and the attribute store could be Active Directory(AD) or any directories/databases that an organization uses to store its user accounts and their associated attribute values. With ADFS 2.0, partner organizations can bypass requests for extra credentials by providing trust relationships (also known as "federation trusts") that these organizations can use to project a user's digital identity and access rights to trusted partners.

Although claims-based authentication has been around for years, most SharePoint 2010 deployments will be using it as their default SSO authentication protocol, so it’s important to understand its merits. When implementing SharePoint 2010 along with ADFS within an enterprise, we realized that the coordination and planning between the various partner-organizations is just as crucial as the architecture itself. If you'd like to hear more about how we are helping our clients implement this for their enterprise SharePoint environment, we would be happy to discuss it further!