Claims User Identity Flow

Claims User Identity Flow

This section explains how a claims-based user identity flows in a specific environment with the following systems configured in a particular manner as described throughout this topic:

For more information on configuration, see Configuration

AD FS 2.0 Configuration

AD FS 2.0 is configured to provide the following claims from the LDAP attribute store.

SharePoint 2010 Configuration

SharePoint 2010 is configured for claims authentication using AD FS as a trusted provider mapping the http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name claim type as the Identifier Claim and E-mail Address and Role as additional claims.


$map1 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" -IncomingClaimTypeDisplayName "Name" -LocalClaimType "http://schemas.k2.com/identity/claims/name"
$map2 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "Email Address" -SameAsIncoming
$map3 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" -IncomingClaimTypeDisplayName "Role" -SameAsIncoming

$ip = New-SPTrustedIdentityTokenIssuer -Name $trustedName -Description $trustedDescription -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1, $map2, $map3 -SignInUrl $signInUrl -IdentifierClaim $map1.InputClaimType

SharePoint has several reserved claim types that require mapping to a unique, non-reserved claim type.  For more information, see the SPTrustedClaimTypeInformation.IsClaimTypeReserved Method: http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.claims.sptrustedclaimtypeinformation.isclaimtypereserved.aspx.

The default claim type provided by AD FS for Name is reserved in SharePoint and must be mapped to a unique claim type.  The Name claim type is configured to map to the http://schemas.k2.com/identity/claims/name claim type in SharePoint.  K2 receives the claim set from SharePoint and therefore must be configured to use the mapped claim type value of the identity claim.
The following PowerShell command is used to determine the MappedClaimType of Identity Claim Type configured for a Trusted Provider in SharePoint.


DisplayName                    : Name
InputClaimType                 : http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
MappedClaimType                : http://schemas.k2.com/identity/claims/name
IsIdentityClaim                : True
AcceptOnlyKnownClaimValues     : False
ClaimValueModificationAction   : None
ClaimValueModificationArgument :
KnownClaimValues               : {}
UpgradedPersistedProperties    :

K2 Configuration

K2 is configured to map configured to map identity and role claims from the trusted:ADFS LDAP identity provider to the K2 LDAP user manager with the K2ADFS security label.  Additionally, identity and role claims from the windows identity provider are configured to map to the K2 Active Directory user manager with the K2 security label.

    <issuer name="SharePoint Security Token Service" thumbprint="8BD27388714EC92EA0433BE660BA7698430CE4FF" />
    <issuer name="SharePoint Security Token Service Encryption" thumbprint="54722E70106DF64E48DD2FF2AFC8BC4F8DE231B1" />
    <claimTypeMapping securityLabel="K2ADFS">
      <identityProviderClaim originalIssuer="SecurityTokenService" claimType="http://schemas.microsoft.com/sharepoint/2009/08/claims/identityprovider"
                              claimValue="trusted:ADFS LDAP" />
      <identityClaim originalIssuer="TrustedProvider:ADFS LDAP" claimType="http://schemas.k2.com/identity/claims/name" />
      <roleClaim originalIssuer="TrustedProvider:ADFS LDAP" claimType="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" />
    <claimTypeMapping securityLabel="K2">
      <identityProviderClaim originalIssuer="SecurityTokenService" claimType="http://schemas.microsoft.com/sharepoint/2009/08/claims/identityprovider" claimValue="windows" />
      <identityClaim originalIssuer="Windows" claimType="http://schemas.microsoft.com/sharepoint/2009/08/claims/userlogonname" />
      <roleClaim originalIssuer="Windows" claimType="http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid" />

Logical Flow

User requests for content and data from SharePoint and K2 will follow this flow.

  1. The client sends a request to access the SharePoint 2010 site.
  2. IIS refuses the connection and redirects the user to the trusted claims provider for SharePoint 2010 – AD FS 2.0.
  3. The client sends a request for a token from AD FS 2.0.
  4. AD FS 2.0 returns a logon page to the client prompting users for credentials.
    If the client already has a valid Kerberos ticket on the network, and AD FS 2.0 is setup for Integrated Windows Authentication, then this ticket is presented to AD FS 2.0 in the first request, skipping steps 4-7.
  5. The user provides their credentials.
  6. AD FS 2.0 validates the credentials with the identity store, in this case Active Directory.
  7. Active Directory validates the client.
  8. AD FS 2.0 provides a claim for access to SharePoint 2010 data.
  9. The client presents the claim from AD FS 2.0 to the SharePoint 2010 server.
  10. The SharePoint 2010 server decrypts and validates the claim, then encrypts the claim with additional SharePoint claims and provides the claims for access to K2 data.
  11. The K2 server validates the claim is from a trusted issuer (the SharePoint STS) and decrypts the claim.
  12. The K2 server matches the identity provider in the claim to one registered in K2 configuration.
  13. The K2 server retrieves the K2 user manager security label and the identity claim value to construct the K2 fully qualified name user.
  14. The K2 server switches the context to the K2 FQN user.
  15. During workflow runtime, if the K2 workflow server needs specific user properties such as email address, it must retrieve them directly from the actual user store.
  16. The K2 server makes a call via the K2 user manager associated with the K2 FQN user, directly to the user data store via LDAP, to retrieve the K2 FQN user’s email address.
  17. The user store, in this case Active Directory via LDAP, returns the email address for the associated K2 FQN user.
  18. The K2 server sends a notification email to the email address of the K2 user.
  19. (Optional) The K2 server accesses LOB system data via Kerberos or Pass-through Authentication using the context of the K2 FQN user.
  20. (Optional) The LOB system requested data is returned to the K2 server.
  21. The K2 data is returned to the SharePoint 2010 server.
  22. The SharePoint 2010 server presents the K2 FQN user with the requested information.

K2 does not implement an STS and therefore does not retain or pass-on to external LOB systems any of the claims provided with the user from SharePoint.  K2 utilizes the configured claim mappings to determine the appropriate K2 fully qualified name user.  Once the K2 fully qualified user name context has been determined, all processing in K2 occurs using that same user context just as it does for non-claims-based users.

Validation of Flow

The display of the SourceCode.Sample.Claims.WebPart can be used to understand the flow of user context between SharePoint, AD FS and K2.

The three claim types configured for the claim rule in AD FS have resulted in a total of 4 claims.  One for the Name, one for the E-mail Address and two for Role which corresponds to the two Active Directory groups that Joe is a member – Domain Users and Legal.

In addition, SharePoint has added several claims, including the identity provider claim used by K2 to determine which K2 user manager and security label to map the incoming user.

In the end the K2 server correctly transformed the logged in SharePoint claims user to a K2 fully qualified name user using the LDAP user manager with the K2ADFS security label.



K2 blackpearl Help 4.6.11 (4.12060.1731.0)