Federated User Authentication Process
As collaboration boundaries expand and
need for information increases, access to resources that are not hosted
by your company or an organization that knows you is needed. For
example, many people want to use Internet-based resources such as
Facebook, Twitter, and so on. Because accessing any computer-based
resources involves some type of authentication, authorization, and user
administration, this greatly complicates our access requirements, and
therefore our ability to access external resources. In claims
terminology, the user wishes to access an application that doesn’t
trust the user’s STS; but what if the application that owns the
resources the user wishes to access trusts an STS that trusts the
user’s STS? This is referred to as identity federation. In this scenario, an identity provider offers an STS (for example, SharePoint 2013) and another STS is offered by a federation provider
(FP). The administrator configures the federation provider STS to trust
the identity provider STS. As a result, the user is allowed to securely
access the necessary resources even though the resources are outside
his or her environment.
Users on the Internet typically interact with
several common IdPs (e.g., Facebook, Microsoft ID, Yahoo, Office 365).
If SharePoint 2013 or any claims-enabled application in general needed
to accept identities from each of these (i.e., trust them), two
different approaches could be used:
- Configure SharePoint 2013 or the application to trust each STS.
Users would be presented with a list of available STSs, choose the one
they want to use, and proceed to authenticate against that STS.
- Use a federation provider (FP) such as ADFS 2.0 or Windows Azure
Access Control Service. The FP trusts each of these STSs and provides
an abstraction layer between them and SharePoint or the application. In
this case, SharePoint or the application is configured to trust only
the federation provider STS.
The FP simplifies administration, especially if
multiple applications need to be configured. FPs can also provide
claims transformations that alter the type and number of claims. FPs
are an abstraction layer that can shield an application from the
peculiarities of each STS that the application needs to support. The
claims transformation capabilities enable claims that originate from
each different STS to be mapped to a consistent set of claims
appropriate for the relying party application. Figure 2
shows an overview of the federated user authentication process with a
FP, such as ADFS or Windows Azure Access Control Service (ACS), and a
different IdP that is trusted by the FP. The following steps in the
process illustrate two new key points: how an STS can act as a
federation provider, accepting one token and producing another, and how
one STS can trust another STS:
1. A web
browser or other client on behalf of the user requests access to
SharePoint 2013. SharePoint provides information about which STSs it
trusts. In this example, SharePoint trusts only one STS, the FP STS.
2. The client
contacts the FP. The FP STS offers the user a choice of identity
provider STSs that it trusts. The FP STS is configured to trust
multiple STSs, such as Microsoft ID, Azure ACS, Facebook, and others.
Since SharePoint trusts the FP, this trust relationship allows users to
authenticate against these other IdPs and gain access to SharePoint.
3. The
appropriate IdP STS is chosen, and the web browser or client contacts
the selected IdP STS. The necessary credentials are provided to the
chosen IdP STS, and the IdP STS authenticates the user and generates an
IdP security token. This token can’t be used to access SharePoint
because SharePoint doesn’t trust this IdP.
4. The browser submits the IdP token to the FP STS, which validates the token to ensure it came from a trusted STS.
5. Once the
IdP token is validated, the FP STS generates a new security token and
sends the FP token back to the client. The FP STS can also transform
the claims that come from any IdP STS so that the token sent to the
SharePoint-relying party looks the same regardless of which IdP STS
authenticated the user.
6. The client
submits the FP STS token to SharePoint 2013, which verifies that that
the FP token was issued by a trusted STS, the claims information is
processed as appropriate, and the user is granted access. The token can
also contain claims about the user that the application can use for
authorization.
7. SharePoint issues a response with the requested content to the client, and the process is complete.
This process illustrates how one STS can trust
another STS, and how federated identity can be used across environments
and applications. ADFS 2.0 supports both web browsers and other
clients, such as Office desktop clients and those built using Windows
Communication Foundation (WCF). The ADFS 2.0 STS can be used entirely
inside an organization, exposed on the Internet, or both. ADFS 2.0 is
not required to use SharePoint 2013 claims-based identity. CBA or
federated CBA can be implemented using an STS from any vendor, or even
a custom-built STS.
Part of the beauty of this process is that users
gain access to resources without explicitly logging into the desired
application. Users log in to their familiar application, and they have single sign-on (SSO) with the desired application.
