Logo
HOW TO
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
 
 
Windows Server

Microsoft Sharepoint 2013 : User Authentication (part 2) - Using Claims-Based Identity

11/29/2014 8:08:20 PM

Using Claims-Based Identity

The purpose of this section is to show how claims identity is used to authenticate users. It begins with a real-world analogy that illustrates the use of claims. Then you will learn the technical requirements for implementing claims authentication. Finally, you will walk through the actual claims authentication process.

A Real-World Analogy

It’s very likely that at some point, you have used your driver’s license to establish or verify your identity. Your license contains a set of attributes that assert your identity, such as name, age, eye color, and so on. In order to obtain such a license, prospective drivers must furnish required credentials bearing proof of their identity. This proof might be a birth certificate, a passport, and might even include a utility bill or some other proof of residency. These assertions are verified by the state agency, and the state issues your driver’s license. This list of identity assertions is used by other companies or agencies to verify your identity because they trust the state agency that issued your license.

In claims identity, this list of assertions can be considered a set of claims. Assertions can include a username, a role, an employee ID, and a variety of other attributes pertinent to the individual’s position. The state agency represents the Security Token Service (STS). Users request access to SharePoint resources and are redirected to the STS. The STS verifies their identity (authenticates the user), and then issues a security token that encapsulates the user’s claims. The STS functions as an identity provider (IdP) because it creates and manages security tokens. To create a security token, the STS must be able to locate valid credentials for a user in an attribute store. Active Directory Domain Services can be used as an attribute store for an STS, and would be an example of an authentication provider. SharePoint and other applications trust the STS and therefore do not have to re-authenticate the user. The claims can then be used to determine authorization and permission levels for access to SharePoint 2013 resources.

A relying party is any entity that trusts the issuer of the driver’s license or, in the claims world, the STS. In the physical world, the security agent at the airport is a relying party. In the claims world, SharePoint trusts the STS (or multiple STSs) to have authenticated the users who make requests for SharePoint resources, and therefore is a relying party. In both the real world and the claims world, those who produce the security tokens often add other relevant information about the user to the tokens. In the driver’s license example, address information, height, weight, and a picture are typically included. In the claims world, security tokens can include information that SharePoint can use to authorize the user’s requests for SharePoint resources, such as organization information, group memberships based on geography or job role, or any other information that can be used to determine what a user can do inside of SharePoint. In our driver’s license analogy, the relying party of a driver’s license depend on the birthdate to determine whether a user can purchase alcohol. Note that the relying party makes this decision based on the value of the birthdate, not just the presence of the birthdate. As a relying party, SharePoint uses attributes gathered from Active Directory and other attribute stores. In the case of the driver’s license and the security token, these attributes are added when the token or license is created. This addition of claims is referred to as claims augmentation.

Driver’s licenses expire, and once expired they are no longer considered a legitimate means of providing identification. Similarly, a security token has a defined lifetime after which it is no longer valid.

Driver’s licenses are also subject to being modified or duplicated to provide false information. Relying parties in the physical world (security agents at an airport, for instance) deal with this by not accepting licenses that show signs of tampering. In the claims world, the STS knows the type and number of claims specified by the relying party, and the STS token is digitally signed to protect against tampering and ensure authenticity.

Technical Requirements

To implement claims identity, SharePoint 2013 utilizes a Security Token Service (STS) defined in WS-Trust, and is configured to trust one or multiple STSs. SharePoint 2013 is claims-enabled once it is installed, but the following provides perspective on the key components. Implementing claims-based identity and using claims for authorization generally requires using and understanding a set of core technologies:

  • Windows Identity Framework (WIF) — WIF provides the .NET classes required to enable claims-based authentication. All the required interactions with the security infrastructure (Active Directory, LDAP directories, cloud-based directory services such as Windows Azure Access Control Service, etc.) are enabled by WIF. WIF is based on a set of open-source standards, and specifically includes capability for WS-Security, WS-Trust, and WS-Federation. WIF is part of the SharePoint 2013 prerequisites, and it is automatically installed when you run the prerequisite installer.
  • Security Assertion Markup Language (SAML) — SAML is a markup language that is the recognized standard for communicating identity information. WIF officially supports SAML 1.1, although support for SAML 2.0 is currently available via a Community Technical Preview (CTP) from Microsoft.
  • Open Authorization 2.0 (OAuth) — OAuth is a protocol that enables users to authorize access to resources without user credentials (user ID and password, certificates, etc.). The user is required to authorize this access when it is first requested. Subsequent access is considered to be acceptable to the end user. Access is granted to specific resources for a specific duration. OAuth is the protocol used to allow SharePoint applications from the Office Store or an organization’s application store (known as the App Catalog) to access SharePoint resources on behalf of the user or the application principal. OAuth is used to allow applications that are running outside of SharePoint to access protected SharePoint resources.
  • Active Directory Federated Services 2.0 — ADFS 2.0 provides both identity federation and single sign-on (SSO) solutions. ADFS is an STS. It uses Active Directory as its identity store; and Lightweight Directory Access Protocol (LDAP), SQL, or a custom store as an attribute store. ADFS is not required for SharePoint 2013, but it enables SharePoint 2013 to federate with other applications. ADFS also provides SAML 2.0 support, and it can be used with SharePoint 2013 to deliver this capability.

NOTE Many of the terms associated with claims-based identity and claims authentication are summarized in Table 1. For a deeper explanation of how WS-Trust, WS-Security, and WS-Federation work together in a claims-based authentication scenario, see “Understanding WS-Federation” at http://msdn.microsoft.com/en-us/library/bb498017.aspx.

TABLE 1: Claims-Based Identity Terminology and Descriptions

TECHNOLOGY DESCRIPTION
Windows Identity Foundation (WIF) A set of application programming interfaces (APIs) that can be used by developers to build claims-aware and federation-capable applications. WIF provides a framework to claims-enable your applications and to create custom security token services. This enables enterprises to use a single identity model so that applications can communicate and interoperate using industry standard protocols. See http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=17331.
ADFS 2.0 Provides both identity federation and single sign-on (SSO) solutions. ADFS 2.0 is a security token service (STS) responsible for issuing security tokens. It uses Active Directory as its identity store; and Lightweight Directory Access Protocol (LDAP), SQL, or a custom store as an attribute store. ADFS 2.0 supports both active (WS-Trust) and passive (WS-Federation and SAML 2.0) scenarios. ADFS 2.0 supports SAML 1.1 and SAML 2.0. Windows Server 2012 includes ADFS 2.1.
Claim A claim is an identity assertion about the user, but in general it is any piece of information that describes a characteristic of the user.
Security token A token, or security token, represents a collection (one or more) of claims and a digital signature. The token is digitally signed to protect against unauthorized claim changes.
Secure Store Service (STS) Creates and issues security tokens. The STS is a web service that issues tokens as defined by the WS-Trust security standard.
Identity provider Any organization that backs the STS, ensures that the claims are authentic, and authenticates the user.
Relying party An application that accepts and uses a security token. The application has been configured to trust the STS and is relying on the information contained in the claims.
WS-Security The protocol that defines a security token and how to include and/or refer to one in a SOAP message.
WS-Trust Deals with the issuing, validating, and renewal of security tokens. It also defines the concept of a Security Token Service (STS), and how to request a security token directly from the service, including the format of messages used to request and respond.
WS-Federation Specifies the process for sending and receiving WS-Trust messages via a web browser (passive profile) and SOAP clients (active profile).
Security Assertion Markup Language SAML is an XML-based standard for exchanging authentication and authorization data between applications and services. SAML tokens are XML representations of claims.
SAML Protocol Defines message patterns for requesting and receiving SAML security tokens from a Security Token Service.

Claims-based authentication is user authentication that utilizes claims-based identity. Users can have identities in different directory stores and use them simultaneously to access different resources in SharePoint. Claims-based authentication is the default for SharePoint 2013. SharePoint 2013 supports Windows claims (NTLM and Kerberos), FBA claims, and SAML 1.1 claims. In order to use SAML 2.0, SharePoint 2013 must federate with ADFS, which supports both SAML 1.1 and SAML 2.0. Using claims-based authentication enables you to take advantage of all the new capabilities in SharePoint 2013.


NOTE Claims identity and the claims authentication process in WIF are based on multiple standards and specifications, some of which are listed in Table 1. These standards and specifications are managed by the Organization for the Advancement of Structured Information Standards (OASIS). Interested readers are referred to the OASIS website for more details https://www.oasis-open.org/.
Other -----------------
- Microsoft Sharepoint 2013 : What’s New with Claims and Authorization?
- Sharepoint 2013 : Client-side Programming - Working with the REST API (part 3)
- Sharepoint 2013 : Client-side Programming - Working with the REST API (part 2) - Working with the REST API in JavaScript
- Sharepoint 2013 : Client-side Programming - Working with the REST API (part 1) - Understanding REST fundamentals
- Migrating to Exchange Server 2007 : Migrating from Exchange 2000 Server or Exchange Server 2003 to Exchange Server 2007 (part 7)
- Migrating to Exchange Server 2007 : Migrating from Exchange 2000 Server or Exchange Server 2003 to Exchange Server 2007 (part 6)
- Migrating to Exchange Server 2007 : Migrating from Exchange 2000 Server or Exchange Server 2003 to Exchange Server 2007 (part 5) - Moving Mailboxes
- Migrating to Exchange Server 2007 : Migrating from Exchange 2000 Server or Exchange Server 2003 to Exchange Server 2007 (part 4) - Installing Exchange Server 2007 on a Server System
- Migrating to Exchange Server 2007 : Migrating from Exchange 2000 Server or Exchange Server 2003 to Exchange Server 2007 (part 3) - Installing Exchange Server 2007 Prerequisites
- Migrating to Exchange Server 2007 : Migrating from Exchange 2000 Server or Exchange Server 2003 to Exchange Server 2007 (part 2)
 
 
REVIEW
- First look: Apple Watch

- 10 Amazing Tools You Should Be Using with Dropbox
 
VIDEO TUTORIAL
- How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 1)

- How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 2)

- How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 3)
 
Popular tags
Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 Adobe Indesign Adobe Flash Professional Dreamweaver Adobe Illustrator Adobe After Effects Adobe Photoshop Adobe Fireworks Adobe Flash Catalyst Corel Painter X CorelDRAW X5 CorelDraw 10 QuarkXPress 8 windows Phone 7 windows Phone 8 BlackBerry Android Ipad Iphone iOS
Popular keywords
HOW TO Swimlane in Visio Visio sort key Pen and Touch Creating groups in Windows Server Raid in Windows Server Exchange 2010 maintenance Exchange server mail enabled groups Debugging Tools Collaborating
Top 10
- Microsoft Excel : How to Use the VLookUp Function
- Fix and Tweak Graphics and Video (part 3) : How to Fix : My Screen Is Sluggish - Adjust Hardware Acceleration
- Fix and Tweak Graphics and Video (part 2) : How to Fix : Text on My Screen Is Too Small
- Fix and Tweak Graphics and Video (part 1) : How to Fix : Adjust the Resolution
- Windows Phone 8 Apps : Camera (part 4) - Adjusting Video Settings, Using the Video Light
- Windows Phone 8 Apps : Camera (part 3) - Using the Front Camera, Activating Video Mode
- Windows Phone 8 Apps : Camera (part 2) - Controlling the Camera’s Flash, Changing the Camera’s Behavior with Lenses
- Windows Phone 8 Apps : Camera (part 1) - Adjusting Photo Settings
- MDT's Client Wizard : Package Properties
- MDT's Client Wizard : Driver Properties
 
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
2015 Camaro