In this section, our goal is for the
administrator to gain a deeper understanding of claims-based
authentication, as this is the new default mechanism for SharePoint
2013. We begin by introducing the concept of claims-based identity, and
then describe how to use it, ending with a high-level overview of the
claims authentication process.
Claims-Based Identity
Users new to claims-based identity routinely ask the same set of questions:
- Why do we need yet another way to authenticate users?
- What is user identity?
- What is a claim?
- Why is claims authentication the default SharePoint mechanism?
The answers to these questions are associated
with the key challenges related to providing users with access to
information. These challenges include user identity, user access, and
user information and storage. As you will see, claims-based identity
presents a solution to these challenges.
User Identity
User identity is a fundamental
requirement for application security, in terms of both user
authentication and user authorization. Knowing who is requesting access
to websites and access to object information is critical to providing a
secure environment. The challenge is determining which identity
technology is the right one for a specific application, and then which
one is the best across the enterprise or cloud environment so that you
can accommodate the needs of all the applications. The solution can
become very complicated. You need to satisfy two key requirements:
- How users will gain access to the enterprise’s applications, regardless of their location
- How different types of user information will be retrieved by the
applications so that the applications can accomplish their required
functions
CLAIMS IDENTITY VERSUS CLASSIC IDENTITY
Administrators are very familiar with
classic user identity, which is represented by the domain\username
format. Claims identity is represented by a very different format:
i:0#.w|domain\username, and although there is some similarity they are
very different. A given user can have a classic identity and a claims
identity, and SharePoint will treat this as two totally different
users.
User Access
User access to websites and information
is necessary for sharing and collaborating inside and outside the
organization. Providing user access in a secure manner is critical, and
a key challenge. Administrators and developers need to know whether an
application will be accessed by employees from within the organization,
from a device outside the organization, from the public Internet, or
any combination of these. One technology may not be enough; the
organization may have to support multiple technologies. For example,
you might use Windows integrated security for internal users, and
forms-based authentication (FBA) for users outside the organization;
but this introduces complexity in terms of providing a single
authentication mechanism and the need for storing different user
information in multiple locations. In addition, neither Windows
integrated security nor FBA provide much information about the user,
with the latter providing username and password information only,
unless both the membership and role providers have been created and
configured. In addition, suppose you need to provide access to partner
or vendor employees. For that you need to implement identity federation
using SAML so that users won’t need a separate login. An example of
identity federation would be using Active Directory Federated Services
(ADFS). ADFS would provide a SSO experience for these non-employees,
without IT having to give them a company login account. Finally, keep
in mind that the application requiring login may exist in the cloud, as
this scenario is rapidly gaining popularity; or you could have a hybrid
scenario, with applications both on-premises and in the cloud.
User Information
How will information about users be
stored and retrieved? The application can query the user for some
information and look up other information. This may not sound like a
big issue, but consider the number of different applications in an
organization, and that each may need to store and retrieve information
that is specific to its functionality. Even when your organization
requires simple identity capability, such as all users across the
enterprise authenticating using Active Directory, this type of login
provides very little information about the user.
The Solution
The solution to user access and user
information has typically been solved by each different application
requiring its own login and user information. This may not be an issue
if there is just one application, but when you have multiple
applications this becomes a big problem for both users and
administrators. Claims identity offers a different and better solution:
create a single identity approach for all scenarios so that the user is
authenticated once, and each application is provided with the specific
information it needs. However, you may be wondering why you need to use
claims; wouldn’t SharePoint’s classic mode NTLM and Kerberos work just
fine? The following reasons may help to convince you otherwise:
- NTLM and Kerberos protocols haven’t been significantly updated in many years.
- The need to federate SharePoint with other systems and to establish
hybrid environments that include both on-premise and cloud resources is
here and increasing. NTLM and Kerberos are not particularly well suited
for interoperability with other applications outside your organization.
- Windows claims supports both NTLM and Kerberos.
- Claims alone and in combination with OAuth offers new ways to
delegate authentication and authorization, and to utilize user profile
information.
- SharePoint and SAML open new directory integration possibilities
that Active Directory alone cannot meet. For non-Microsoft products and
technologies, SAML is the standard, just as Active Directory is the
standard for Microsoft products.
- You may already be using claims authentication and not realize it.
For example, when you log in to Windows Live (which has been renamed to
Microsoft ID) or grant access to your Facebook profile, you are using
WS-Federation and OAuth.
Claims-based identity provides a common way for
applications to acquire identity information from users, irrespective
of whether they are inside the organization, in other organizations, or
on the Internet. Now that you understand the concept of claims identity
and its role as a solution for user authentication, the following
section takes a look at using claims identity.
