Claims Based Authentication and Identity: What does it Mean to You?

I hope you enjoyed the five-part series that I did earlier this year about the evolution of identity management, called Identity (Management) Crisis. I want to keep exploring the identity management dilemma by addressing some of the more specific implementation of identity technologies.

Over the last few years, you may have run into the terms “claims based identity” and “claims based authentication” and “claims based access control” but what exactly does that mean? Microsoft introduced the idea of a claims based identity model to developers back in the 3.0 version of the .NET Framework, as a way to address the problem of having applications authenticate users who don’t have Windows domain accounts.

As I mentioned in an article I wrote earlier, First Look at Dynamic Access Control in Windows Server 2012, DAC relies on claims based authentication. In this two part article, we’ll first look at the concept of claims based security mechanisms and in part two, we’ll examine how modern Microsoft technologies take a claims based approach.

Why do we need a new identity model?

Windows already has a well-established system for authenticating users via the user’s Windows domain account. Applications can use Windows integrated authentication to leverage the power of Kerberos. The user logs onto the domain and is authenticated by the domain controller, and is issued a credential called a master ticket. To authenticate to the application, that master ticket is presented and this gets you a ticket from the Kerberos server to the particular service you want to access. That ticket is presented to the service/application to prove your identity.

Think of this real life analogy: You have to present credentials such as a birth certificate or passport, social security card and possibly other documents to obtain a driver’s license or state ID card, which is like the master ticket. The driver’s license is a general form of identification, which you can present to get a more specific “ticket” to use a particular service – for example, to open a bank account. The bank relies on the driver’s license (master ticket) and doesn’t make you show them your birth certificate and social security card every time you want to cash a check. That’s more convenient for you and easier for the bank.

So if this method has been working fine for all these years, why do we need a new identity model in the first place? What happens if you have a user who doesn’t have those original credentials that get the ball rolling? Many years ago in the “real world,” I remember my grandfather telling me about having to deal with that problem. He was born at home so there were no hospital records, and he didn’t drive a car on public roads (just tractors and trucks and other farm implements on private property). He worked on his parents’ farm and back then, didn’t have to get a social security card. So when the time came, late in life, when he needed to prove his age and birth date, he had a problem. The state government ended up accepting sworn affidavits from people who had known him all his life and a handwritten entry in a family bible, and he was able to get his government ID that he needed to get into a hospital program – but not without a great deal of time and effort and frustration.

In the world of computers, you may have users outside your organization who need to access your services, but they don’t have accounts in your Windows domain so they’re missing that first set of credentials on which the Kerberos process depends. What do you do with them?

Today, and even more so in coming years, computing will be all about the cloud. And cloud computing is going to introduce even more complexity into the problem of authenticating users across different organizations and networks. Most of us have multiple digital identities for different applications and services, and the same identity information may be presented to them in entirely different ways. Application developers need a better way to ensure that users can be properly authenticated, and that’s the idea behind claims based authentication and identity.

How claims based identity works

The foundation of claims based identity is, as the name implies, claims. This term is used in this context as a name for what those of us familiar with Active Directory schema might think of as attributes. Once you realize that, it clears up a lot of the mystery surrounding claims based identity.

The dictionary definition of “claim” is “an assertion of the truth of something.” A claim, then, is a single piece of information about an individual user that the one making the claim asserts to be true. A specific claim, alone, might or might not be unique to that individual. One claim would be the user’s name, another claim would be his/her age, another would be his/her gender, another would be his/her role in the organization, and so forth. Claims are not just descriptors, however; the user’s right to access a particular server or file can also be represented as a claim.

All of the claims for a particular user are contained in a security token, which is the complete set of claims information in digital form that is associated with that user.

Security tokens often (but not always) use SAML (Security Association Markup Language), which is built on the XML standard.

Tokens are used to transfer the authentication/identity information between the identity provider and the service provider. The token is created and issued by a Security Token Service (STS), which is operated by an identity provider. Obviously anyone could claim anything, so it’s up to the identity provider to verify and then guarantee that these claims are indeed true. The identity provider’s STS serves as an intermediary between the user and the application or service that the user wants to access. Here’s the process:

1. The user requests to access the application or service.
2. The application or service sends a request to the STS for a token for that user.
3. The STS authenticates the user (for example, via a password or smart card or biometric scan.
4. The STS generates the token.
5. The STS digitally signs the token and the digital signature becomes part of the token.
6. The STS returns the token to the application or service that requested it.
7. The application verifies that the digital signature is valid and that it came from an STS that the application trusts (each application will have a list of trusted STSs).
8. The application processes the claims information to determine whether to allow the user to access the service or application, and what level of access the user will have.

Advantage of claims based identity

The big advantage of claims based identity is that the burden of authenticating users is moved from the application or service to an identity provider. Because this is the primary job of the identity provider and not just an afterthought, as security often is for application developers, it’s likely that the identity provider will do a better job of vetting and correctly identifying the users and their claims. And the application no longer has to maintain a database of user information or get different pieces of information about the user from different systems. The user benefits because this should also speed up the process of being granted access to the application or service.

Trusted providers

This brings us to the obvious question: Who (what entity) is to be entrusted with the task of verifying identities in the first place, and issuing tokens? Within a company or other organization, the company itself can act as the identity provider.

If your organization and another organization have a trust relationship and want users from the two different companies to be able to access resources on both companies’ networks, you can set up a federated identity relationship where your services and applications trust the other company’s STS and vice versa. Claims based identity makes it easy to do this, even if the companies’ networks use different operating systems and authentication protocols. The STS authenticates the users with whatever protocols their companies use and then issue SAML tokens, so it doesn’t matter if one company is using Windows domain networking and the other isn’t.

For accessing resources outside the company, such as public social networking sites, you will generally use providers operated by those sites. Large companies such as Microsoft and Google that operate many different Internet services have moved to consolidate their identity services. This means that instead of having to log onto several different services separately (such as your Hotmail account and your SkyDrive account), you log onto all of them with a Windows Live ID account. Likewise, your Google account gets you into your Gmail, Google+ account, Google Voice and so forth.

The Holy Grail is “one identity to rule them all,” better known as single sign-on (SSO). The problem has been: What entity does everyone trust to serve the role of universal identity provider? Some might trust Google while others would trust Microsoft. Still others might trust neither, but would trust Facebook. Should governments – which, after all, issue “real world” identity credentials – be entrusted with this task?

With claims based identity, an application can explicitly trust multiple STSs – or it can be configured to trust an STS that is trusted by the STS that it trusts. This is like having someone you know vouch for the integrity of someone you don’t know. This is another instance of identity federation.

Claims based authentication through AD FS

The many enterprise networks that are based on Windows Active Directory domains can take advantage of claims based identity and authentication within their organizations by using Active Directory Federation Services. AD FS can serve as an internal identity provider and STS, and/or as a federation identity provider/STS.

The current version is AD FS v.2.0 and it supports SAML, along with the WS-Trust and WS-Federation protocols. AD FS can be used to create federations with non-Microsoft identity technologies such as Oracle Identity Federation (OIF) and Shibboleth 2. AD FS interoperates with Windows Identity Foundation (WIF) applications. AD FS can provide single sign-on (SSO) to applications and services located in different networks in a way that is seamless to users.

A big advantage of AD FS is that it’s free. You can download it from the Microsoft Download Center and install it on Windows Server 2008 or Windows Server 2008 R2 (Standard, Enterprise, Datacenter, and Foundation editions). AD FS 2.0 is deployed as a server role and managed with Server Manager. It acts as the identity provider for claims based applications.

In a claims based authentication scenario, the claims provider is the software component that issues claims and packages them into security tokens; a claims provider is a type of identity provider. There are also relying parties, which can be either the applications that rely on the claims provider’s validation of the claims, or it can be another, intermediary STS that validates claims coming from a different provider that it trusts.
AD FS can be configured to act as either a claims provider or a relying party. When acting as a claims provider, the AD FS service authenticates users and issues claims for them that go to other STSs. The service issues tokens based on the claims information that it gets from an attribute store. “Attribute store” is Microsoft’s terminology for a directory or database that holds user accounts and their attributes (e.g., the Active Directory. These attributes (such as the user’s name, email address, User Principal Name, role in the organization, group to which the user belongs, etc.) become the basis for the claims that are created by AD FS. Note that despite its name, AD FS supports attribute stores other than Active Directory, including SQL Server databases and custom attribute stores created by application developers.

Note:
Forefront Identity Manager (FIM) can synchronize claims information across multiple attribute stores.

When acting as a relying party, the AD FS service receives incoming claims/tokens from other providers (rather than getting them directly from an attribute store) and validates them, then passes on the validated claims to its own relying parties. AD FS can apply claims rules to incoming claims before producing outgoing claims based on them. Note that claims rules aren’t shared across multiple trusts; they have to be created individually for each federated trust relationship. AD FS includes claim rule templates to make it easier for admins to create the rules.

Claims based identity through Windows Azure

As computing moves into the cloud (both the private and public variety), identity takes on an even more important role at the same time that it increases in complexity. Microsoft has repeatedly renewed their vow of “all in” commitment to the cloud concept, so it makes sense that they also have focused on developing a strong identity solution for cloud based applications.

Cloud based applications generally need a cloud based identity provider/STS, but AD FS is designed as an on-premise enterprise provider. This is where the Windows Azure AppFabric Access Control Service comes in. ACS can work with AD FS, to allow cloud based applications to accept the security tokens that have been issued by an AD FS STS, as well as those issued by other on-premise identity providers.

But that’s not all – ACS can also enable those cloud based applications to accept the tokens issued by other cloud based identity providers such as Facebook, Google or Microsoft’s own Windows Live ID. In order to be a broad based identity provider, ACS supports a wide span of protocols and token formats. It issues and accepts SAML 1.1 and 2.0 tokens. It also supports Simple Web Token (SWT), which is designed to be included in an HTTP header.

Clients can use WS-Trust and WS-Federation. The WS extensions are security standards by which web service requests are made. WS-Trust allows the exchange of security tokens for credentials in different trust domains. WS-Federation allows the relying party to control access based on the credibility of the claims validated by a different security realm.

Note:
A custom STS that supports WS-Trust is called an Active STS; a custom STS that supports WS-Federation is called a Passive STS.

ACS can also use OpenID 2.0 and OAuth 2.0 to request tokens. These are custom identity providers that can be added to ACS. OpenID was created by the open source community and anyone can become an OpenID provider. OpenID authentication is used by more than 50,000 web sites and over a billion users. Sites and services that use OpenID include Google, Yahoo, Flickr, MySpace and WordPress.

OAuth is an authorization open standard that allows a user to allow applications or web sites to act on the user’s behalf without sharing his/her credentials. It was first developed for use with Twitter. Thus a user can log onto a social network, and then can authorize a web site to access specified data belonging to that user.

ACS can get claims from a social network or email provider or some other identity provider and then pass those claims to another identity provider, which then issues a security token for access to applications that trust that second provider’s STS. The authentication was done by the social network or other provider from which ACS retrieved the claims. To do this, ACS redirects the user to the right identity provider to get authenticated, then sends a token to the relying party (which in this case is a claims based application).

Of course, you might or might not want to trust Facebook as an identity provider. After all, the service doesn’t really do much to vet the identities of users who sign up for accounts, beyond displaying a terms of service that requires the use of your real name, prohibits fake accounts, etc. The good news is that you can configure ACS to accept authentication from those identity providers that you want to trust, and exclude those you don’t trust. Users can select which of ACS’s trusted providers they want to use to authenticate.

Claims based identity through Windows Live ID

Microsoft already has a widespread implementation of a rather simplified claims based identity service in the cloud: Windows Live ID. Its claims based architecture was designed to work across different security boundaries and on different operating system platforms. You don’t have to belong to a Windows domain, or even be using a Windows OS, to sign into Windows Live ID.

Services can use Windows Live ID as a cloud based identity provider. For example, SharePoint 2010 can delegate authentication to the Windows Live ID STS. The user enters his/her Windows Live ID user name and password, and Windows Live ID issues a a SAML claims token that contains a unique identifier (a Passport Unique Identity or PUID) and email address. The token is encrypted with the Windows Live ID public key. The SharePoint server converts the Windows Live ID token into a SharePoint Server token. You can read more about this in this TechNet article titled Configure claims-based authentication using Windows Live ID (SharePoint Server 2010).

Windows Live ID can be added as an identity provider for ACS, as well.

The role of the identity library

As you can see, Microsoft has several different identity providers for different situations: AD FS, Azure AppFabric Access Control Service, Windows Live ID. All of these use the same identity library: Windows Identity Foundation (WIF). The identity library is the component that verifies whether a security token has a valid signature, determines by which STS the token was issued and verifies that the issuing STS is trusted by the application and assesses the claims that are contained in the token.

WIF does all this for SAML 1.1 and 2.0 tokens and is extensible to allow support for additional protocols. AD FS 2.0 is based on WIF. WIF is a framework with a set of APIs on which developers can build claims based applications (relying parties). Here is more information about WIF.

Future evolution of claims based authentication

As we’ve explored in the earlier parts of this article, in the broad sense the systems we’ve been using for years to authenticate users (such as Kerberos and NTLM) are claims based in that the user names, passwords, roles and group memberships are forms of claims. The “new” claims based identity platforms go much further, with the goal of removing the authentication burden from the “relying parties” – the individual applications (and their developers) and placing it on a trusted identity provider.

This is not a new concept, either; Public Key Infrastructure works in the same basic way. A trusted third party (certificate authority) verifies credentials and provides a means (public/private key pair) that others can rely on to authenticate an entity’s identity and other “claims.”

Why bother to establish a new standardized method of authenticating identities? Because identity and authentication are the foundation of all computer/network security. But application developers often aren’t security experts, and may not get that piece right. The beauty of a claims based system is that different authentication methods (Kerberos, smart cards, forms, etc.) can be used when desired, but the claims based systems will handle users outside the organization (partner organizations, customers, etc.) and those that use non-Windows operating systems. Trusts can be established between issuing STSs so that identity is easily federated across realms/domains.

Microsoft has been moving toward the claims based model for several years. They’ve provided developers with the Windows Identity Foundation (WIF) so that claims can be used by ASP.NET and Windows Communication Foundation (WCF) applications. WIF includes the FedUtil.exe utility that developers can use to generate federation metadata for applications. They also have provided ADFS 2.0 for creating a Security Token Service (STS). SharePoint 2010 supported claims based authentication. But all of that was only the beginning. Microsoft’s upcoming products, currently in beta, move further toward the claims based model.

Claims in latest and future Microsoft products

We’ve already discussed how the Dynamic Access Controls (DAC) feature in Windows Server 2012 is built around claims based authentication. We also discussed the Active Directory Federation Server (ADFS) 2.0, which is a component of the Windows server platform. The claims based identity model is also supported by other Microsoft products that interact with Windows Server components.

Claims based identity in Office 365

Microsoft’s Office 365, which provides cloud-based access to Microsoft Office applications, Exchange Online, SharePoint Online and Lync Online, supports claims based authentication with single sign-on through the Active Directory Federation Service (ADFS) 2.0, which we discussed in Part 3 of this series.

Users must be authenticated to use Office 365 (with the exception of SharePoint Online sites that are configure to accept anonymous connections). Users can use the same network credentials that they use to log onto their Active Directory domains when directory synchronization is deployed to sync the AD FS on the corporate network with the Microsoft Online Services Directory.

Note that Office 365 supports both these federated identities and cloud identities (Microsoft Online Services cloud IDs). The cloud identities are separate identities with different credentials from the users’ on-premise Active Directory credentials. Cloud identities are authenticated via the traditional challenge/response method in the cloud. When users sign on with single sign-on, they are authenticated by AD FS on the corporate network.

Office 365 users can be authenticated from a web browser (SharePoint Online, OWA, etc.). When the user enters his/her corporate credentials in the Office 365 sign-in service web page, the browser is redirected to the AD FS 2.0 on the corporate network for authentication after detecting that the user belongs to a federated domain. The user is authenticated via Kerberos or NTLM and then AD FS creates a SAML token, the sign-in service in turn creates an authentication token that’s presented to the Office 365 service the user is attempting to access, and the user is logged into the service.

Office 365 users can also be authenticated from Microsoft Office applications installed on the local machine. In this case, Office 365’s Microsoft Online Services Sign-in Assistant goes through AD FS 2.0 to authenticate the user’s credentials and then gets a token to allow the user to log onto the service.

Claims based identity in SharePoint

Microsoft included a claims based identity model (Claims Mode Authentication) in SharePoint 2010 for creating web applications. SharePoint 2013 carries that forward, providing SharePoint with the ability to authenticate both users of Windows based systems and non-Windows systems as well as delegation of user identity between applications. Windows claims mode sign-in is the default. SharePoint 2013 also supports SAML passive sign-in mode, ASP.NET membership and role passive sign-in and Windows classic mode sign-in.

User identities are presented to the application in the form of claims, so that the application is no longer responsible for authenticating users, storing the user account and password information, looking up user details in directories or integrating with other identity systems.

In web applications, the user’s browser sends the claims via an HTTP POST. This can be cached for later use. For web services, the claims are in the SOAP envelope’s security header. The claims include the digital signature of the claims issuer. The issuer is a web application or service that issues security tokens. Windows Identity Foundation creates the security tokens and encrypts them. The tokens are SAML formatted.

WIF includes the Claims to Windows Token Service (C2TWS). You start it manually and must configure it with a list of allowed callers. C2TWS provides a way for relying party applications to access external back-end servers (such as SQL servers) by taking the UPN claims from non-Windows security tokens and creating Windows security tokens that let the applications impersonate the user. For more information on how this works, see the MSDN article Claims-based identity and concepts in SharePoint 2013.

Claims in the cloud

The cloud brings new challenges for identity management because there is no universal directory service so the old ways (Kerberos, NTLM) aren’t appropriate for the new environment.

It’s obvious that Microsoft sees the claims based identity model as the future of authentication, with claims based DAC in Server 2012 and claims mode the default in SharePoint 2013. That makes sense when you think about the company’s commitment to cloud computing. As more and more of computing moves to the cloud, and as client computing becomes more heterogeneous with the Bring Your Own Device (BYOD) trend in the enterprise, we need an authentication model that will work across different operating systems that are not all operating within a Windows domain. Claims based authentication fills that bill. It provides a secure and very flexible means for authenticating users to cloud applications.

Claims are platform-agnostic. The claims based authentication model allows for the creation of cloud applications that don’t have to deal with the authentication process. It provides consistency whether servers are on premises or in the cloud and works in almost every situation.

In the cloud, we encounter different hosting technologies as well as different client technologies accessing them. Claims based authentication removes the burden of identity management from the resources and places it in the hands of an entity (the Identity Provider) that is dedicated to that task. Authentication is done by the Identity Provider and authorization is done by the resource based on the claims presented (although the IP may make some authorization decisions).

Claims can be used in any network environment, but it is especially suited for distributed systems, and the cloud is a large scale distributed system. Thus as we march inexorably “to the cloud,” claims based solutions are likely to become the standard for authenticating users across domains, organizations and networks.