Understanding the SharePoint
security model requires understanding the difference between the
authentication process and authorization process. Authentication is the
mechanism whereby systems securely identify the user attempting to
access a resource. Authorization is the mechanism by which a system
determines the level of access the authenticated user or identity has to
a secured resource. The authorization process requires that the
authentication process succeeds and establishes an identity. SharePoint
itself does not perform any authentication; the authentication process
is handled by an underlying authentication system. For example, Windows
authentication is handled by Windows server and Internet Information
Services (IIS). SharePoint performs the authorization to secured
resources contained in sites, lists, libraries, and other such
containers. SharePoint 2010 offers two different authentication modes
natively: classic authentication mode and claims-based authentication
mode.
Understanding
Classic-Mode Authentication
Classic-mode authentication in
SharePoint 2010 uses the Integrated Windows authentication model
supported in legacy versions of SharePoint. In the classic
authentication mode, only mixed-mode authentication is available. In
mixed-mode authentication, a single SharePoint web application has to be
extended to additional IIS applications with different URLs and
authentication providers. The same content is used for the different
URLs, but the different authentication providers can change the access
users have and the permissions.
Understanding
Claims-Based Authentication
Claims-based authentication
for SharePoint 2010 is built by using the Windows Identity Foundation
(WIF) framework. WIF is a set of .NET Framework classes that are used to
implement a claims-based identity. Claim-based authentication was
developed to provide better fine-grained security for a role-based
security model. Most systems, including SharePoint 2007 and its
predecessors, use role (or group)-based security. Complex systems can
use claims-based security to assign permissions on other attributes
(claims) associated with users, such as city or membership in a
distribution list.
Claims-based authentication
in SharePoint 2010 provides a flexible and extensible authentication
system that supports authentication for any identity management system
that supports claims authentication. Claims-based authentication offers
several benefits, including the following:
Further
decoupling SharePoint 2010 from the authentication providers.
Allows SharePoint 2010 to
support multiple authentication providers for a single URL.
Allows identities to be
passed (and impersonated) between systems without Kerberos delegation.
Enables organizations to
use Federation to collaborate.
Allows ACLs to be configured using other
membership objects and containers, such as distribution lists,
audiences, and organizational units.
Organizations can connect to non-Windows-based
identity management systems that support claims.
Provides a common model for
performing identity operations for web browsers, web services, and other
browser-based applications, including the Office suite.
Note
Claims-based authentication is
based on open standards such as WS-Federation 1.1, WS-Trust 1.4, and
SAML Token 1.1. To learn more about these open standards, go to http://www.oasis-open.org/specs/.
The Claims
Authentication Process
Claims authentication
provides the benefit of being simple for authentication purposes, but
under the covers the process has several components that work together.
Claims authentication model has three main components: the identity
provider, the relying party, and the user who was authenticated. Each of
the three components interacts in the authentication process by
exchanging information and claims.
The goal of any
authentication process is to establish an identity. An identity is a
security principal of an authorized user. The primary component in the
claims-based authentication process is a security token that uses the
Security Assertion Markup Language (SAML). The security token is used to
securely identify and describe an identity by containing of a set of
claims (identity assertions) for the identity. A claim is an attribute
that is specific to the identity, such as an employee ID, employee
title, or username. The claims are used to determine the level of access
the identity has to specific SharePoint 2010 resources.
Both the identity provider and
the relying party are implemented as Security Token Services where each
performs a particular role in the authentication process. The Security
Token Service (STS) illustrated in Figure 1 handles the exchange of claims, and it builds, signs, and
issues the security tokens that can be used to authenticate and
authorize an identity. The STS uses a policy to determine the contents
of a security token. The policy is a collection of claims and claim
rules that has been agreed upon between one or more STSs and the
SharePoint web application, as illustrated in Figure 2. Policies are available in a policy store and are accessed by
an STS, based on the requirements of the calling web application. The
attribute stores are made of the various identity systems and providers
containing the user account information, such as Active Directory Domain
Services (AD DS,) ASP.NET authentication providers, and other SAML
token-compliant authentication providers. The STS can perform two roles
in the authentication process: the identity provider STS and the relying
party STS.
Identity Provider
Security Token Service (IP-STS)
The IP-STS is the
identity provider that provides the claim based on the information the
user has provided. In SharePoint, the IP-STS is the local identity
provider for the requesting web application. The IP-STS receives the
authentication request and processes the request. The IP-STS finds the
policy for the requesting web application or relying party STS, and
creates a security token using the identity claims in the appropriate
attribute store.
Relying Party Security
Token Service (RP-STS)
The RP-STS is the
identity provider that has an established trust relationship with the
IP-STS. The RP-STS is used to validate the claims of external users
whose credentials are not stored in the local attribute stores. The
RP-STS creates security token for the authenticating user and the local
SharePoint STS validates the claims for the authenticating user. The
requesting web application authorizes the authenticated external user
after the local SharePoint STS has validated the claims.
Claims Authentication
in SharePoint
In SharePoint 2010,
claims-based authentication is a SharePoint service. SharePoint contains
a local STS as part of the SharePoint farm. A trust relationship exists
between the local SharePoint STS and the SharePoint farm web
applications.
Figure 3 illustrates a sequence of events when a user
authenticates in SharePoint using claims-based authentication:
The user attempts to
connect to a SharePoint web application using a client (a web browser
or office client). The client sends a web request to the web application
for a particular resource.
The SharePoint web application using
claims-based authentication responds with a 302 response that includes a
URL to redirect and authenticate.
The client redirects and submits an authentication
request to the URL for a security token. The authentication request is
processed by the local STS. The local STS performs the role of the
identity provider STS, authenticates the identity of the user, and
creates a security token (SAML token) for the authenticated identity.
The
client receives a security token from the local STS.
The client sends a web
request to the web application for a particular resource with the
security token included. The web application validates the user identity
and retrieves the resources.
The client receives access the resources it requested,
such as a cookie, the HTML page, and its resources.
Claims Authentication
in SharePoint Using Federation
A common scenario
for collaborating with partners is to create a trust between the partner
STS and the local STS. When external users attempt to authenticate in
SharePoint, the request will be made against the partner STS and
validated by the local STS in the SharePoint farm. The external user
will be able to access the web application with their external
credentials.
Figure 4 shows the sequence of events when an external user
authenticates in SharePoint using claims-based authentication:
The user attempts to
connect to a SharePoint web application using a web browser or Office
client. The client makes a web request to the web application.
The SharePoint web
application that uses claims-based authentication responds with a 302
response that includes a URL to redirect to the appropriate partner STS
and authenticate.
The
client redirects and submits an authentication request to the partner
STS for a security token. The authentication request is processed by the
partner STS, authenticates the identity of the user, and creates an
identity provider security token (IP-STS token). The IP-STS token is
sent to the local STS for validation.
The local STS receives the IP-STS token and validates
the claims for the identity. The local STS creates a new RP-STS token
and sends it to the client. The RP-STS token includes additional claims
from SharePoint to identify the user within SharePoint.
The client receives the RP-STS
token from the local STS.
The client sends a web request to the web application
for a particular resource with the RP-STS token included. The web
application validates the user identity and retrieves the resources.
The client receives access
the resources it requested, such as a cookie, the HTML page, and its
resources.
Note
It is important to note that
the IP-STS token is different from the RP-STS token. The RP-STS token
contains information and claims specific to the SharePoint identity. The
token is used to create the SPUser object within the SharePoint farm.
