Building Identity Solutions for today’s environments – Part 1 of 4

John Craddock is a Microsoft Dircetory Services MVP and has designed and implemented computing systems ranging from high-speed industrial controllers through to distributed IT systems with a focus on security and high-availability. 

For many years we have been providing identity solutions that meet the needs of managing authentication and authorization within our own secure boundaries. The user’s identity, services and applications are all contained within the same boundary; probably all members of a Microsoft Active Directory. When we allow access to external users, we often create and maintain the identity store for those external users within our bastion.

Times have changed and we now have to stretch our boundaries to embrace resources that could be hosted on-premises, or in the Cloud. The users want to access those resources not only from their PCs, but also tablets and phones. The user’s identity may be asserted by our organization, a partner organization or a third-party identity provider. Federation provides the tools to create identity solution that spans the requirements of resources anywhere, devices anything, and identity anyone, what I call the Triple-A paradigm. See Figure 1.

In this four part blog I will show you show you the components that will allow you to build identity solutions for the future. You could learn more through the use of demos at the ANYWHERE, ANYTHING, ANYONE - Building Identity Solutions event on the 10th of June.

Part 1: An Introduction to federated identity

Part 2: Supporting federation on-premises with AD FS

Part 3: Microsoft Azure Active Directory

Part 4: Hybrid identity solutions with AD FS and the Microsoft Azure Active Directory

An Introduction to federated identity

Let’s start by looking at the current Kerberos authentication and authorization model used in the Microsoft Active Directory environment. A user logs in and is given a Ticket Granting Ticket (TGT) by the Kerberos Key Distribution Centre (KDC); this TGT is used when the user interacts with the KDC to request a Session Ticket (ST) to a service. The service could be an application or a native service such as the file server. A simplified view of this is shown in figure 2, a lot of the detail has been left out but all the essentials are there to illustrate this process.

The user, KDC and service are the three actors in the game, they all trust each other because they are members of the same Active Directory. Through these explicit trusts, the service trusts the ST presented by the user. The user is authenticated to the service; but what about the authorization data that will control the user’s access to the service? This information is held as part of the Kerberos token in a field called the Privileged Attribute Certificate (PAC). The big challenge with a Kerberos ST PAC is that one size fits all. The PAC is crammed with all of your group memberships regardless of the information that a service requires. If the service only needs to control access based on a user’s membership of one group, it still has to enumerate potentially 1000+ groups. I’m sure many of you have suffered from Kerberos Bloat. See figure 3.

In addition to the potentially bloated token, Kerberos is not an Internet friendly protocol and does not easily work between disparate organizations. We need better solutions for connecting users and services that are distributed between on-premise, partner and Cloud locations.

Federation to the rescue

In the simplest federated model we have the three actors, the user, the Security Token Service (STS) and the application/service to which the user wants to be authenticated and authorized. The application/service is referred to as a Relying Party (RP). The STS can authenticate the user against an identity store and consequently works as an STS/Identity Provider (STS-IdP).

The user authenticates with the STS-IdP, the STS can then create a security token ST which is specifically crafted for the service/application the user is trying to access. See figure 4. To support federation the application must be claims-aware. For the Windows platform, claims-aware application can be created using .NET libraries. Most other platform will support the development of claims-aware applications through appropriate extensions.

A claim is a named value pair consisting of a claim type and a value. The table below shows some examples.The ST contains claims about the user. The ST is digitally signed with a X.509 certificate and after validating the signature the RP accepts the ST as proof that user is authenticated and that the claims are valid.

The fact that the ST is digitally signed with a X.509 certificate means that once the trust is established between the STS and the RP, authentication will work regardless of whether the RP is located on-premises or in the Cloud. In contrast to the one-size fits all Kerberos token, the STS knows about each relying party and can create a token with the appropriate claims for each one. The RP can make authorization decisions based on the claims contained within the token. Tokens created by some STS-IdPs are very sparsely populated and it may be necessary for the RP to gather additional information before making authorization decisions.

Federation comes in two flavours, “Active Profile” and “Passive Profile”. Using the Active Profile, code running on the client machine actively requests a token from the STS. Passive Profile allows a dumb browser (“dumb” is probably unfair these days) to interact with the application and the STS using standard https redirects and POSTS. See figure 5.

Enterprise protocols for federation have typically been SAML-P or WS-Federation and the token is a SAML token in XML format. While these protocols are still very much in use, particularly with browsers, when we throw device equals anything into the mix and the need to access web REST APIs we need a simpler format. OAuth 2.0 has become the de facto standard for authorizing access to services and for authentication Open ID Connect is becoming prevalent. In contract to the SAML token, OAuth 2.0 uses a JSON Web Token (JWT) which has a much simpler format and can be carried in the HTTP header making it ideal for accessing REST APIs.

Protocols

In this series of articles I will be mainly illustrate examples using WS-Federation as this is the standard that Microsoft uses for claims-aware websites including SharePoint. In my one-day seminar in addition to looking at WS-Federation I will show you OAuth 2.0 in action and how it is used for workplace join and work folders.

That’s it for now, in my next blog I will show you how to create the on-premises infrastructure to support claims-aware applications. We will be using AD FS and the Web Application Proxy.