1. Reviewing the concepts of authentication and authorization
A computer security system performs two basic functions:
authentication and authorization.
A security system uses authentication to determine the identity of a
caller. The first part of the authentication process attempts to map
the caller to an existing security principal. For example,
authentication could map the caller to a user account in an Active
Director domain. When this process is successful, the system
establishes the caller’s identity by creating a security token which
contains attributes of the security principal in question.
For example, the Windows operating system creates a special type of
security token known as a Windows security token when it authenticates
a user. A Windows security token is an in-memory data structure that
contains the user’s logon name and a list of security groups in which
the user is a member.
If the authentication process asks the question “who are you?”, the authorization
process asks “what can you do?” The authentication process must occur
before the authentication process. The reason for this is that you must
determine the caller’s identity before you can determine what the
caller can do.
Before the authorization
process can begin, the authentication process must create a security
token that maps the caller to a security principal. During the
authorization process, the system examines information contained by the
security token to determine whether the caller should be allowed access
to the requested resource(s).
2. Understanding SharePoint 2013 authentication
Every version of SharePoint has provided support
for authenticating users and configuring user permissions. However,
SharePoint 2013 is the first version to add support for authenticating
apps. This section will begin with a brief explanation of how user
authentication works, and then it will dive into the details of app
authentication.
2.1 Understanding user authentication in SharePoint 2013
The first thing to understand is that the SharePoint platform itself
does not supply the actual code to authenticate users. Instead, the
SharePoint platform relies on external user authentication systems such
as Windows Server and Active
Directory or the built-in support in ASP.NET for FBA. After an external
system has authenticated a user and created a security token, the
SharePoint platform is then able to create a profile around that
security token to establish and track the user’s identity within the
SharePoint security system.
Let’s quickly revisit how user authentication has evolved in
SharePoint over the last decade. SharePoint 2003 was pretty limited
because it only offered support for Windows authentication. This meant
that each and every authenticated user required an Active Directory
account.
SharePoint 2007 made a step ahead by adding support for ASP.NET FBA.
The new support for FBA was a welcomed change to developers and system
integrators, especially for common scenarios such as extranets and
publically-facing Internet sites for which it was impractical to create
and maintain an Active Directory account for each user or site member.
However, it was with SharePoint 2010 that Microsoft really changed
how user authentication works with the introduction of claims-based
security. Prior to SharePoint 2010, the SharePoint platform tracked
user identity by using the security token created by the underlying
authentication system. For example, SharePoint 2007 tracks user
identity via two types of security tokens:
Windows security tokens, which are created by Windows Server, and FBA
security tokens, which are created by the ASP.NET runtime.
With claims-based security, the SharePoint platform moves to a
single, unified format for the security tokens that are created during
the user authentication process. More specifically, the user
authentication process creates security tokens by using an XML-based
standard known as Security Assertion Markup Language (SAML). Within
developer circles, this type of security token is commonly referred to
as a SAML token.
Let’s walk through the authentication process in a SharePoint
environment configured for claims-based security. In this scenario, the
user is
authenticated by using either Windows security or FBA. The first part
of the authentication process essentially remains unchanged with
respect to the fact that it creates a Windows security token or an FBA
token. The end of the authentication process is where things are
different. This is because any Windows security token or FBA token must
be converted into a SAML token.
Every SharePoint web server runs a local service known as the
Security Token Service (STS). The STS is responsible for converting
Windows security tokens
and FBA tokens into SAML tokens as the final part of the authentication
process. In SharePoint 2010, these SAML tokens are cached in memory on
a per–web server basis and can be reused across multiple requests from
the same user. SharePoint 2013 further optimizes the caching of SAML
tokens with the Distributed Cache Service, which can be configured to
maintain a farm-wide cache of SAML tokens.
SharePoint’s adoption of claims-based security and SAML tokens has
another significant effect: it has dramatically increased the number of
identity providers that can be integrated with a SharePoint farm. In
addition to supporting Windows authentication and FBA, claims-based
security makes it possible for a SharePoint farm to authenticate users
by using external identity providers such as Windows Azure Access
Control Service (ACS), Windows Account, Google, and Facebook.
Configuring user authentication in web applications
The manner by which SharePoint authenticates users is configured at
the web-application level. When you create a web application in a
SharePoint farm, you have the option of creating it in either claims
mode or classic mode. A web application created in claims mode
authenticates users as described in the previous section. The important
point is that a SAML token is created during the user authentication
process to establish user identity.
SharePoint’s support for creating classic-mode web applications is provided for backward
compatibility. It should be avoided except for rare scenarios in which
a SharePoint farm contains content migrated from earlier versions which
rely on older custom components that need to be rewritten before they
can support running within a claims-mode web application.
The bottom line is that you should avoid
creating classic-mode web applications in SharePoint 2013 except for
scenarios in which you are forced into it to support legacy components.
With SharePoint 2013, Microsoft has deprecated the use of classic-mode
web applications and removed the ability to create them through Central
Administration. The only way to create a classic-mode web application
is by using Windows PowerShell.
A significant reason to avoid the use of classis-mode web
applications is that they do not support installing and running
SharePoint apps. All of Microsoft’s design and testing of the
SharePoint app model assumes that apps are always installed on sites
hosted by claims-mode web applications.
