Authentication, Authorization & Security in SharePoint
2013
User Authentication & Authorization in SharePoint 2013
User Authentication & Authorization in SharePoint 2013
User Authentication
It is the process that verifies
the identity of a user who requests access to a SharePoint web application. An authentication
provider issues the authenticated user a security token that encapsulates a set
of claims-based assertions about the user and is used to verify a set of
permissions that are assigned to the user.
User Authorization
It is the process that determines the users who can
perform defined operations on a specified resource within a SharePoint web
application.
User Authentication
Modes in SharePoint 2013
Claims-based
Authentication - The app
authentication and server-to-server
authentication features of SharePoint 2013 require claims-based authentication.
Because of this, claims-based authentication is the default for new web
applications in SharePoint 2013. When you create a web application in Central
Administration, you can only specify authentication methods for claims-based
authentication.
Classic-mode
Authentication - Classic mode authentication uses Windows
authentication and SharePoint 2013 treats the user accounts as AD DS accounts. Although
Windows Classic mode authentication is still available in SharePoint 2013 and
can be configured through Windows PowerShell, we recommend that you use
claims-based authentication. Windows
Classic mode authentication is deprecated
in SharePoint 2013.
What’s new in authentication for SharePoint 2013
Ø
SharePoint
2013 includes improvements in claims infrastructure and authentication features
that enable new server-to-server and
app authentication scenarios.
Ø
Authentication
enhancements in SharePoint 2013 make the use of claims-based authentication
easier and enable new scenarios and functionality for Exchange Server 2013, Lync
Server 2013, and apps in the SharePoint Store or App Catalog.
Ø
SharePoint
2013 introduces support for server-to-server authentication and app
authentication by utilizing and extending the Open Authorization 2.0 (OAuth
2.0) web authorization protocol.
Ø
OAuth is an industry
standard protocol that provides temporary, redirection-based authorization.
Ø
A
user or a web application that acts on behalf of a user can request
authorization to temporarily access specified network resources from a resource
owner.
Ø
Support for OAuth in SharePoint 2013 allows
users to grant apps in the SharePoint Store and App Catalog access to
specified, protected user resources and data (including contact lists,
documents, photographs, and videos) without requiring the app to obtain, store,
or submit the user’s credentials.
Ø
OAuth allows app and services to act on
behalf of users for limited access to SharePoint resources.
Claims-based Authentication Methods in SharePoint 2013
Ø
Windows claims - The
Windows authentication type takes advantage of your existing Windows
authentication provider (AD DS) and the authentication protocols that a Windows
domain environment uses to validate the credentials of connecting clients.
Windows authentication methods, which are used by both claims-based
authentication and classic mode are NTLM,
Kerberos, Digest & Basic
|
Ø
Security Assertion
Markup Language (SAML)-based claims - SAML token-based authentication in
SharePoint 2013 uses the SAML 1.1 protocol and the WS-Federation Passive
Requestor Profile (WS-F PRP). It requires coordination with administrators of a
claims-based environment, whether it is your own internal environment or a
partner environment. If you use Active Directory Federation Services (AD FS)
2.0, you have a SAML token-based authentication environment.
Ø
Forms-based
authentication claims - Forms-based authentication is a claims-based
identity management system that is based on ASP.NET membership and role
provider authentication. Forms-based authentication can be used against
credentials that are stored in an authentication provider such as AD DS, a database such as a SQL Server database & a Lightweight Directory Access Protocol (LDAP) data store such
as Novell eDirectory, Novell Directory Services (NDS), or Sun ONE. Forms-based
authentication validates users based on credentials that users type in a logon
form (typically a web page). Unauthenticated requests are redirected to a logon
page, where a user must provide valid credentials and submit the form. The
system issues a cookie for authenticated requests that contains a key for
reestablishing the identity for subsequent requests.
These claims-based authentication
methods are now the recommended authentication methods for SharePoint 2013.
Improvements in Claims Infrastructures
SharePoint 2013 also
includes the following improvements in claims authentication infrastructure:
Ø Easier
migration from classic mode to Windows-based claims mode with the new Convert-SPWebApplication
Windows PowerShell cmdlet
Migration can be run
against each content database and each web application. This is in contrast to
SharePoint 2010 Products, in which the migration was run against each web
application.
Ø Login
tokens are now cached in the new Distributed Cache Service
SharePoint 2013 uses a new
Distributed Cache Service to cache login tokens. In SharePoint 2010 Products,
the login token is stored in the memory of each web front-end server. Each time
a user accesses a specific web front-end server, it needs to authenticate. If
you use network load balancers in front of your web front-ends, users need to
authenticate for each web front-end server that is accessed behind the load
balancer, causing possible multiple re-authentications. To avoid re-authentication
and its delay, it is recommended to enable and configure load balancer affinity (also known as sticky sessions). By
storing the login tokens in the Distributed Cache Service in SharePoint 2013,
the configuration of affinity in your load balancing solution is no longer
required. There are also scale-out benefits and less memory utilization in the
web front-ends because of a dedicated cache service.
Ø More
logging makes the troubleshooting of authentication issues easier
SharePoint 2013 has much more logging
to help you troubleshoot authentication issues. Examples of enhanced logging
support are the following:
·
Separate categorized-claims related logs for
each authentication mode
·
Information about adding and removing FedAuth
cookies from the Distributed Cache Service
·
Information about the reason why a FedAuth
cookie could not be used, such as a cookie expiration or a failure to decrypt
·
Information about where authentication
requests are redirected
·
Information about the failures of user migration
in a specific site collection
Server-to-Server Authentication
Ø SharePoint
2013 extends OAuth to implement a
server-to-server authentication protocol that can be used by services such as
SharePoint 2013 to authenticate other services such as Exchange Server 2013 or Lync
Server 2013 or services that are compliant with the server-to-server authentication protocol.
Ø SharePoint
2013 has a dedicated local server-to-server security token service (STS) that
provides server-to-server security tokens that contain user identity claims to
enable cross-server authenticated access.
Ø These
user identity claims are used by the other service to lookup the user against
its own identity provider.
Ø A
trust established between the local STS (the SharePoint 2013 server-to-server
STS) and other server-to-server compliant services (the Exchange Server 2013 or
Lync Server 2013 server-to-server STS) is the key functionality that makes
server-to-server possible.
Ø For
on-premises deployments, you configure the JavaScript Object Notation (JSON)
metadata endpoint of the other server-to-server compliant service to establish
this trust relationship. For online services, an instance of the Azure Access
Control Service (ACS) acts as a trust broker to enable cross-server
communications among the three types of servers.
Ø The new
server-to-server STS in SharePoint 2013 issues access tokens for
server-to-server authentication. In SharePoint 2013 (and also in SharePoint
2010 Products), trusted identity providers that are compliant with the
WS-Federation protocol are supported. However, the new server-to-server STS in
SharePoint 2013 performs only the functionality that enables temporary access
tokens to access other services such as Exchange Server 2013 and Lync Server
2013.
Ø The server-to-server STS is not used for user
authentication and is not listed on the user sign-in page, the Authentication
Provider UI in Central Administration, or in the People Picker in SharePoint
2013 Products.
App Authentication
Ø SharePoint
2013 uses OAuth 2.0 to authorize requests by apps in the SharePoint Store and
App Catalog to access SharePoint resources on behalf of a user. The user grants
permission to apps in the SharePoint Store and App Catalog to access SharePoint
resources on the user's behalf when they are installed. For example, a user
installs an app from the SharePoint Store.
Ø A
SharePoint site contains an embedded HTML inline frame (IFRAME) that the app
renders and that requires the app to access a user list. When a Web browser
displays the site, the app then calls back to the server running SharePoint
2013 to access the list on behalf of the user. After the app obtains the data
from the list, it displays the contents of the IFRAME.
Ø The
app authentication process in SharePoint 2013 uses OAuth to verify a claim that
an app makes and assert that the app can act on behalf of an authenticated
user.
Ø
In SharePoint 2013, an instance of
the Azure ACS acts as the app identity provider. You can also use app
authentication without ACS. The authorization process verifies that an
authenticated app has permission to perform a defined operation or to access a
specified resource.




