Jan 21, 2013 9:02:07 AM
Claims-based Authentication and Authorization with ADFS 2.0 and SharePoint 2010

A lot of technical notes and web articles talk about different aspects for claims-based federation between ADFS 2.0 and SharePoint 2010. In this blog, we will primarily focus on claims mapping, setting for authentication and authorization process.

Let’s walk through an end-to-end scenario below:

1. The user attempts to access SharePoint 2010 claims-based web application.

2. SharePoint redirects the access request to ADFS based on SharePoint Trusted Identity Token Provider configuration with setting up federation trust relationship with ADFS.

$Name = New-SPClaimTypeMapping "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" -IncomingClaimTypeDisplayName "Display Name" –LocalClaimType "http://schemas.contoco.com/identity/claims/name

$Role = New-SPClaimTypeMapping "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" -IncomingClaimTypeDisplayName "Role" –SameAsIncoming

$ap = New-SPTrustedIdentityTokenIssuer -Name "ADFSv2" -Description "Active Directory Federation Services 2.0" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $Name, $Role -SignInUrl $signInURL -IdentifierClaim $Name.InputClaimType

Notice that Name claim type http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name is reserved by SharePoint. In this example, we use –LocalClaimType to perform claim type mapping to http://schemas.contoso.com /identity/claims/name. We will see the reason why later. In SharePoint terms, this mapped claim type http://schemas.contoso.com/identity/claims/name is so called custom claim type (un-pre-defined claim type).

3. ADFS authenticates the user, generates the security token with 2 claims and posts back to SharePoint.

<saml:Attribute AttributeName="role” AttributeNamespace=" http://schemas.microsoft.com/ws/2008/06/identity/claims">

<saml:AttributeValue>SharePoint Users</saml:AttributeValue>

</saml:Attribute>

<saml:Attribute AttributeName=“name“ AttributeNamespace="http://schemas.xmlsoap.org/ws/2005/05/identity/claims">

<saml:AttributeValue>Jake</saml:AttributeValue>

</saml:Attribute>

4. SharePoint Security Token Service validates the security token, consumes the claims, remaps the Name claim and also generates its own claims as additions. All claims together will be passed to claims-based web application.

http://schemas.contoso.com/identity/claims/name = Jake

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/role = SharePoint Users

http://schemas.microsoft.com/sharepoint/2009/08/claims/userid = 0ǵ.t|ADFSv2|Jake http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name = Jake

http://sharepoint.microsoft.com/claims/2009/08/isauthenticated = true

Notice that the first claim is remapped by SharePoint based on the claim mapping in the configuration.

$Name = New-SPClaimTypeMapping "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" -IncomingClaimTypeDisplayName "Display Name" –LocalClaimType "http://schemas.contoco.com/identity/claims/name

The last 3 claims with pre-defined claim types are generated by SharePoint and values are calculated based on the incoming claim values. The SharePoint generated claim with type http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name is included as well. That is the reason why we need to use –LocalClaimType when setting up Trusted Identity Token Issuer mentioned in the step 2. The last claim http://sharepoint.microsoft.com/claims/2009/08/isauthenticated = true is based on authentication statement from the incoming security token.

5. Before all claims are passed to claims-based web application, SharePoint will perform authorization check. We can use People Picker to setup permission for authorization decision purposes. However in this blog, we would like to show how to use powershell to implement such permission settings.

For instance, we would like to allow all authenticated users to access this web application in the SharePoint group of “SharePoint Web Home Visitors” with Read permission level, we can do the following:

$web = Get-SPWeb "https://www.sharepoint.com:4443"

$Group = $web.SiteGroups["SharePoint Web Home Visitors"]

$claimPrincipal =New-SPClaimsPrincipal -EncodedClaim "c:0(.s|true"

$newUser = New-SPUser -UserAlias $claimPrincipal.ToEncodedString() -Web $web

$group.AddUser($newUser)

Notice that the "c:0(.s|true" is the encoded claim string for “All Authenticated Users”. The encoded claim string is based on SharePoint claim mapping format and rules as below:

c -> other claim (than Identity claim)

( -> claim type character of http://sharepoint.microsoft.com/claims/2009/08/isauthenticated

s -> local STS (SharePoint STS is the issuer for this claim, ie SharePoint generates its own)

true -> claim value (remember http://sharepoint.microsoft.com/claims/2009/08/isauthenticated = true)

To allow all authenticated users with claim of role “SharePoint Users” to access this web application in the SharePoint group of “SharePoint Web Home Visitors” with Read permission level, we can do the following:

$web = Get-SPWeb "https://www.sharepoint.com:4443"

$Group = $web.SiteGroups["SharePoint Web Home Visitors"]

$sts = Get-SPTrustedIdentityTokenIssuer "ADFSv2"

$claimPrincipal = New-SPClaimsPrincipal -ClaimValue "SharePoint Users" -ClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" -TrustedIdentityTokenIssuer $sts

$newUser = New-SPUser -UserAlias $claimPrincipal.ToEncodedString() -Web $web

$group.AddUser($newUser)

6. Once the access is authorized, SharePoint will set FedAuth cookie and redirects the request to the original target.