Understanding the User Authentication Process and Authentication Providers
User authentication scenarios in
SharePoint 2013 can be as straightforward as using Windows Integrated
Security and Active Directory or as complicated as using Windows Azure
Access Control Service as a federation provider. The process for user
authentication with a trusted IdP and using SharePoint’s internal STS
is a complex process. This process is shown in Figure 1,
and described in the following steps. This example uses SharePoint as
the relying party, but the relying party could be any claims-enabled
application.
1. The process
begins when the user makes a request to access SharePoint resources or
a SharePoint website. In reality, a web browser or other client acting
on behalf of the user makes an HTTP Get request. SharePoint checks to
see if the request contains a SAML token with the user’s identity. Once
a valid SAML token is identified, SharePoint 2013 then inspects the
target URL of the incoming request to see whether it references a
standard SharePoint site or a child site associated with a specific app
web. If the incoming request targets a standard site, SharePoint 2013
conducts its authentication and authorization process granting access
to the requested resource. However, if the request targets an app web,
SharePoint initiates an OAuth process. In our scenario, the client is
requesting access to a SharePoint website, and has not yet been
authenticated, so no SAML token is present.
2. Since the
user has not been authenticated, SharePoint sends an authentication
request redirect to the client so that it can be authenticated by its
IdP.
3. The client
issues an authentication request to its IdP, which can be Active
Directory, FBA, or any SAML-based system, and the client is
authenticated based on the user’s credentials. In general, the request
also contains information identifying the application to which the user
wants access. The IdP performs a lookup in the appropriate user
directory or database and validates the user’s identity.
4. Once the client is authenticated, the IdP returns a Windows token, FBA token, or SAML token to the client.
5. The client
sends the authentication token to SharePoint, and the SharePoint STS
creates a new token with the appropriate claims. The SharePoint STS can
perform claim transformation and claims augmentation, the former
modifying the claims information while the latter includes adding
additional claims information.
6. The
SharePoint STS sends the new SAML token back to the client. So, at this
point we have two tokens, an authentication token from the IdP and a
SAML claims token from the SharePoint STS.
7. The client
submits the SAML token to SharePoint, and SharePoint reviews the token,
as in Step 1. SharePoint or the application verifies the token’s
signature, confirming that it originated from a trusted IdP, and the
claims are accepted. The token can also contain claims about the user
that SharePoint can use for authorization.
8. SharePoint issues a response with the requested content to the client, and the process is complete.
Claims authentication is based on delegating user
authentication to a trusted STS that is backed by the identity
provider. The trust is established and verifiable by the STS and the
claims-consuming application (SharePoint) using the public:private key
pair of a digital certificate.
A key benefit of claim identity and claims
authentication is that the application does not have to authenticate
the user. The application can focus on authorization because it no
longer needs to authenticate the user. An application can specify
exactly what claims it needs and which identity providers it trusts.
Because the application doesn’t have to authenticate the user, it can
be deployed on-premise or in the cloud without change. The application
only needs to be configured to trust the appropriate STS, and the
administrator configures the STS to issue the right claims required by
the relying party.
Authentication providers are the means by which
users are authenticated, because they represent a directory or database
containing the user’s credentials. An example of an authentication
provider is Active Directory Domain Services (AD DS). Other terms for
an authentication provider that you may see used are user directory and attribute store.
Claims authentication represents an authentication type, and it is a
specific way of validating credentials against one or more
authentication providers. SharePoint 2013 includes a local or internal
STS and WIF to claims-enable web applications; therefore, SharePoint
2013 websites are configured to utilize claims.
NOTE Classic-mode
authentication is still supported, but it is being deprecated, so
organizations are encouraged to use claims authentication. Classic-mode
configuration is done using PowerShell cmdlets; it cannot be
implemented using Central Administration.
Claims authentication in SharePoint 2013 supports
all the authentication providers supported in SharePoint 2010: Windows
authentication (Kerberos, NTLM, Basic), forms-based authentication
using ASP.NET membership and role providers, and SAML token-based
authentication. When you create a new web
application, the default authentication type is claims, and the default
authentication provider is NTLM. You have the option to also choose
Kerberos, and this type of configuration is very important for
establishing a SharePoint farm to support business intelligence. In general, organizations that don’t use AD DS can use
either FBA or SAML, as outlined here:
- For organizations using an LDAP directory, FBA is easier to
implement than SAML, although both approaches are available. SharePoint
Server 2013 has a built-in LDAP provider. FBA can utilize the default
providers that are included with ASP.NET, or organizations that have
very specific security requirements (and very good developers) can
create their own providers if necessary.
- SAML is recommended for those organizations already using an
authentication environment that supports WS-Federation 1.1 and SAML
1.1, which are both supported by SharePoint 2013. SAML tokens can be
produced by identity providers such as Active Directory Federation
Services (ADFS) and others.
- Utilizing ADFS and services such as Windows Azure Access Control
Services (ACS) as federation providers enables end users to
authenticate against many common identity providers or even another
organization’s Active Directory instance. ADFS 2.0 also supports SAML
2.0, so ADFS can be used to federate with SharePoint 2013 to enable
integration with third-party SAML 2.0 providers.
The process for using FBA and SAML authentication
providers with SharePoint 2013 is similar to that for SharePoint 2010,
and is discussed in detail on TechNet. Several key references that
describe the configuration are described in Table 2.
TABLE 2: References for Configuring FBA and SAML Authentication Providers
| AUTHENTICATION PROVIDER |
REFERENCES |
| Forms-based authentication |
http://technet.microsoft.com/en-us/library/ee806890
http://www.microsoft.com/en-us/download/details.aspx?id=34684
|
| SAML authentication using ADFS |
http://technet.microsoft.com/library/hh305235.aspx
http://technet.microsoft.com/en-US/library/jj219641.aspx
|
NOTE Claims-based
authentication is Microsoft’s recommendation for all web applications
and zones of a SharePoint 2013 farm, as this enables you to take
advantage of all the new features and scenarios in SharePoint 2013 that
use server-to-server authentication and app authentication.
WARNING The
new Office Web Applications can only be used by SharePoint 2013 web applications that use
claims-based authentication. Office Web Apps rendering and editing will
not work on SharePoint 2013 web applications that use classic-mode
authentication.
Several scenarios require the use of additional
identity capability. One such example is federated user authentication,
which is discussed in the next section.
