Sharepoint 2013 : Claims-based authentication, federated identities, and OAuth (part 1)

Today’s software solutions always require user authentication and authorization. Quite often, however, each application implements its own authentication method, and users are obliged to remember and manage many different credentials. Think about a typical day in your life: you log on to your domain network when you turn on your computer; you log on to Facebook using its specific credentials; next, you log on to http://www.live.com using your Microsoft Account credentials; then, if you need to access your home banking system, you provide yet another set of credentials specific for that system; and so on. The list of examples could be very long, indeed.

The problem is evident: you and everyone else in today’s digital world have too many sets of credentials to remember, manage, and keep safe. Wouldn’t a better solution be to decouple applications and software solutions from their authentication environments, while taking advantage of a shared set of credentials? In the ideal digital world, you should authenticate once, at the very beginning of the day, and use a worldwide single-sign-on infrastructure.

Now consider the scenario of the emerging cloud-computing offerings. Quite often, you use some services on-premises, such as domain controllers, file servers, ERP, and so forth, as well as online services, such as Microsoft Office 365 (Office Web Apps, Microsoft Exchange Online, SharePoint Online, Microsoft Lync, and so on), Microsoft CRM Online, and some services built on top of the Windows Azure platform. Of course, users of your internal network’s domain should authenticate on the internal network as well as online, and you should avoid multiplying users’ credentials and authentications. In the ideal world, you should federate your internal network with the online services, providing a single-sign-on experience to your users, utilizing a federated trust between your network on-premises and the online services in the cloud.

Furthermore, from a developer’s perspective, it is hard to implement the authentication and authorization logic for each and every software solution that a user implements. It would be better to externalize the authentication infrastructure, concentrating the software implementation on the business logic and rules, eventually providing a custom authorization environment only.

Many software solutions authenticate their users just because they need to authorize access to resources or functionalities based on users’ identities. They do not really need, however, to collect and maintain users’ credentials. From an authorization viewpoint, it suffices to have some information about the users to cluster them in groups or audiences and authorize access to resources based on their properties.

Pushed by these ideas, a few years ago the software market started working on the goal of defining an authentication infrastructure that could be externalized and that could identify every user as a digital identity. Remember that a claim is a statement that is asserted by an issuer about a subject; this statement is assumed to be true by the reader, due to a trust relationship between the reader and the issuer. The externalized authentication provider is generally defined as the identity provider (IP) and often publishes an STS. The application or software solution externalizing the authentication process is called the service provider or relying party. The consumer, who uses the service provider for authenticating with the IP, is generally called the subject. Figure 1 portrays an extremely simplified authentication architecture employed by a software solution that uses externalized authentication.

Figure 1. A simplified schema showing the architecture of a system with externalized authentication.

From a technology viewpoint, these concepts use such specifications as WS-Security, WS-Trust, and WS-*. The final goal of these specifications is to allow for implementing a token-based authentication and authorization system, in which third parties can issue tokens.

In December 2006, an international and multivendor working group defined a specification called Web Services Federation Language 1.1 (WS-Federation), which states its role is to define “mechanisms to allow different security realms to federate, such that authorized access to resources managed in one realm can be provided to security principals whose identities are managed in other realms.”

From a practical viewpoint, WS-Federation defines extensions to the WS-Security and WS-Trust specifications, which support exchange of authentication and authorization claims between federated partners, identities brokering, and protection of claims during their transmission across partners. One of the most interesting features of WS-Federation is the capability to provide federation techniques that you can use in communication based on Simple Object Access Protocol (SOAP), via WS-Security and WS-Trust, as well as in web browser–based environments. The SOAP scenario is often called active requestor, while the scenario based on web browsers is referred to as passive requestor. From the perspective of SharePoint and web/HTTP, you should be most interested in the passive requestor scenario, because it is the only process that you can manage, as well as experience from a user viewpoint.

Figure 2 illustrates a sequence diagram related to the functional schema of WS-Federation in the passive requestor scenario.

Figure 2. The sequence diagram of WS-Federation for the passive requestor scenario.

In Figure 2, the passive requestor scenario walks through the following steps:

The term passive derives from the fact that the web browser is unconsciously and automatically redirected to the IP/STS, and then automatically sends the token via POST to the SP. Thus, the browser is passive during the authentication process.

If you share the same IP/STS for two or more sites, such as sharing your Microsoft Account across multiple sites, once an end user has authenticated with the IP/STS, he or she will be able to obtain issued tokens for all of the federated sites without authenticating again. This is a powerful single-sign-on scenario.

Furthermore, when you log on to SharePoint 2013 using claims-based authentication mode, the front end does not redirect you to an external IP/STS for authentication. Instead, it communicates on the back end with the internal IP/STS of SharePoint, using SOAP as the communication protocol.

If you want to realize a complete WS-Federation scenario, you need to register an external IP, together with all the information about its STS. Then you will be able to authenticate with third-party solutions, whereupon you will experience the WS-Federation passive requestor scenario concretely.