If you would like to read the other parts in this article series please go to:
- Claims Based Identity: What does it Mean to You? (Part 1)
- Claims Based Identity: What does it Mean to You? (Part 2)
Now, in the third and final installment in this series, we’re going to look at claims based identity going forward, in relation to Microsoft’s soon-to-be-released operating systems (Windows 8 and Windows Server 2012) and server products (such as SharePoint 2013). We’ll also look at claims based identity in Office 365.
Evolution of claims based authentication
As we’ve explored in the earlier parts of this series, 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.
You can read more about how this works in the white paper Microsoft Office 365 Single Sign-on (SSO) with AD FS 2.0.
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.
Going forward, claims based identity will almost certainly take on even more importance, due to its ability to offer capabilities for cloud computing that are difficult with other types of authentication. Thus far, our discussion has centered on Microsoft technologies that implement claims based authentication. In our last installment, Part 4 of this series, we’ll take a look at non-Microsoft solutions for claims based identity management.
If you would like to read the other parts in this article series please go to: