SharePoint 2013 - The New Identity Management

Identity management in SharePoint 2013 is the combination of the following parts:

 

* The set of identifiers for entities, their storage location, the creation of trust relationships among identity stores, and the display of identifier information.

 

* Users, computers, or services are examples of entities.

 

* The methods, typically provided by a form of credential exchange that is protected with cryptography, that use identifiers to authenticate access to a resource.

 

* The methods, typically specified by a set of permissions that are assigned to identifiers, that specify and enforce the authorization of access to a resource.

 

Elements of an identity management system

• A typical identity management system consists of the following elements:
•  Entities
• Stores for accounts and attributes
• Authentication methods
• Authorization methods
• Storage, synchronization, and display of entity attributes

 

The following sections describe these elements and how SharePoint 2013 supports them.

 

Entities

 

Within an identity management system, an entity represents a physical or logical object that requires access to a resource. Entities on a network that uses Active Directory Domain Services (AD DS) include users, computers, and services. Each entity has an identity that can correspond to an account in a directory, such as AD DS. Accounts can consist of a set of attributes that describe the entity, such as name, group membership, email address, and so on.

 

Stores for accounts and attributes

A store that contains accounts and attributes provides a location for entity accounts and their attributes. Networks that use AD DS store accounts and attributes in AD DS. The store that contains accounts and attributes can do the following:

• Validate account credentials during authentication.
• Provide account attributes to the entity that requests authentication so that those attributes can be used for authorization.

 

SharePoint 2013 can use the forms-based or Security Assertion Markup Language (SAML) user authentication methods for AD DS or additional stores. SharePoint 2013 does not include a store for accounts and attributes.

 

Identity federation is the process that links multiple stores of accounts and attributes through trust relationships so that authentication and authorization for access to resources can occur seamlessly across those stores. Forefront Identity Manager 2010 R2 enables you to manage identity life cycle and role management across heterogeneous identity platforms.

 

Methods of authentication

An authentication method is a specific set of messages that computers send to each other to perform authentication. A message validates an identity of an entity. The result of the authentication process is a security token, which typically contains cryptographic proof that a store of accounts and attributes has validated the identity. The security token can also contain entity attributes, such as the list of security groups to which the entity belongs.

For AD DS, the authentication method is typically either NTLM or the Kerberos protocol. For example, when a user logs on to a domain-joined computer, it collects the security credentials from the user and uses the Kerberos protocol to validate those credentials with an AD DS domain controller. The user’s computer receives a Kerberos ticket to use when the user accesses resources. The Kerberos ticket contains cryptographic proof that AD DS has validated the credentials and a list of groups to which the user belongs.

 

Claims-based identity and authentication

Although Kerberos and NTLM work well for AD DS-based networks, they do not extend easily to multiple stores of accounts and attributes from third-party vendors or to identity management systems in the cloud.

For claims-based identity, a user obtains a security token that a trusted security token service (STS) has digitally signed and that contains a set of claims. Each claim represents a specific item of data about the user such as his or her name, group memberships, and role on the network. Claims-based identity enables applications to rely on the security token for proof of authentication and the set of claims for authorization or other processing. Claims-based identity typically enables a user to perform an authentication to obtain the security token and submit that token to applications. The claims-aware application verifies the digital signature of the security token and uses the claims to implement authorization and other application-specific functions.Claims-based identity and authentication in Windows is built on Windows Identity Foundation (WIF), which is a set of .NET Framework classes that is used to implement claims-based identity. Claims-based authentication relies on standards such as WS-Federation, WS-Trust, and protocols such as SAML.A simplified claims-based identity implementation contains the following components:

 

* A claims-aware client application An application that can obtain a security token from an STS and submit security tokens for authentication and authorization. An example of a claims-aware client application is a web browser, such as Internet Explorer.

* An STS A server or service that creates security tokens for claims-aware client applications. The STS that is in SharePoint 2013 provides its own security tokens to requesting claims-aware client applications, and it can also use Active Directory Federation Services (AD FS) 2.0 as an external STS.

* A relying party A computer or application that relies on an STS for tokens. The relying party redirects claims-aware client applications to the STS to obtain a suitable security token. SharePoint 2013 can act as a relying party to an external STS. An example is a SharePoint web application that is configured to use AD FS as its STS.

* A claims-aware server application An application that requires a security token for authentication and authorization. An example is a SharePoint 2013 web application that uses claims-based authentication (the default).

 

SharePoint 2013 supports claims-based identity and authentication for the following entities:

 

* Users The validation of a user's identity against a store of accounts and attributes that contains the user’s credentials and can verify that the user submitted them correctly. User authentication occurs when a user attempts to access a SharePoint resource. For more information, see Plan for user authentication methods in SharePoint 2013.

* Apps The validation of the identity a remote app for SharePoint and the authorization of the app and an associated user to request a secured SharePoint resource. App authentication occurs when an external component of a SharePoint Store app or an App Catalog app, such as a web server that is located on the intranet or the Internet, attempts to access a secured SharePoint resource. For more information, see Plan for app authentication in SharePoint 2013.

* Servers The validation of a server's request for resources that is based on a trust between the STS of the server that runs SharePoint 2013 and the STS of another server that supports the OAuth server-to-server protocol. Based on this trust relationship, a requesting server can access secured resources on the server that is running SharePoint 2013 on behalf of a specified user account, subject to server and user permissions. For more information, see Plan for server-to-server authentication in SharePoint 2013.

 

Methods of authorization

After authentication succeeds, an application must determine whether the entity is authorized to access the requested resource. To perform this analysis, the application compares the identity information about the entity—such as the user name and the groups for which it is a member—in the security token (for claims-based identity) or Kerberos ticket to the list of default or configured permissions for the resource being accessed.

Permissions are settings that specify an entity (such as a user or group name) and what that entity is allowed or not allowed to do (such as read, edit, or delete files in a shared folder). To obtain access to the resources, the configured permissions must permit the type of access that the entity requests.

SharePoint 2013 provides permissions for users to access web applications and their resources, server permissions for server-to-server resource requests, and app permissions for app resource requests.