Mapping SharePoint 2010 users to K2 users

In classic mode all integration with K2 is done using the Windows authentication mechanism, either NTLM or Kerberos. Users who access K2 or SharePoint resources in this configuration will likely utilize Integrated Windows Authentication to allow their current logged in Windows credentials to automatically logon to SharePoint or K2. A user will be prompted with a Windows Security dialog to provide credentials whenever integration is not available. From K2 blackpearl 4.6.7 on, multiple authentication is supported for SharePoint 2013 and K2 smartforms.

Once users have been authenticated with Window credentials, they are granted access or authorization to SharePoint or K2 based on their configured permissions.

SharePoint maps the authorized user from an underlying information store, in this case Active Directory, to a SharePoint-specific user name, represented in the image below as Account.

Similarly, K2 maps the authorized user from the underlying information store to a K2 fully qualified name user in the format of [Security Label]:[Domain\Username], represented as a K2 field part in the image below.

In claims mode integration, K2 depends on the claims authentication type configured for the current SharePoint user, Windows, Forms or Trusted. Users who access K2 or SharePoint resources in this configuration will either utilize Integrated Windows Authentication or a login form to logon to SharePoint or K2.

SharePoint 2010 provides a SharePoint Security Token Service (STS) that is a specialized Web service designed to respond to requests for security tokens and provide identity management. After authentication, the SharePoint STS issues a trusted security token that it can then present to a relying party application such as K2. K2 establishes a trust relationship with the SharePoint STS. This enables K2 to validate the security tokens issued the SharePoint STS and examine security tokens presented by SharePoint and determine the validity of the identity claims they contain.

The SharePoint STS maps the authorized user from the underlying information store, for example claims-based Active Directory, to a SharePoint encoded claim user name, represented as Account in the image below:

The SharePoint encoded claim user name is a combination of the values for two main claims – Identity Provider and Identity. The identity provider claim type is populated by the SharePoint STS with the value of the provider that performed the authentication. The identity claim type will vary based on the configuration of the authentication provider. SharePoint pre-configures the claim type for Windows, and Forms determines the claim type for Trusted providers when they are registered with SharePoint.

Identity Provider Claim Type

Windows/Forms/Trusted:

Identity Claim Type

Windows/Forms:

Trusted: provider specific

For more information on SharePoint claims users encoding, see the AttributeValue topic in the SharePoint Security Token Service Web Service Protocol Specification: http://msdn.microsoft.com/en-us/library/dd932259(v=office.12).aspx.

K2 implements a similar claims type mapping concept for the relationship between the SharePoint claims user and the K2 fully qualified name user. K2 does not implement an STS and therefore does not retain or pass on 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.

For more information on configuring the trust relationship and user mappings between SharePoint and K2, see Claims and OAuth Configuration.

For more information on available K2 user managers, see Introduction to User Managers.

K2 provides several inline functions to assist process designers in converting between SharePoint claims users and K2 fully qualified name users.

Each function requires input information about the K2 Server, the SharePoint Site URL and user to convert, as either a string or an array of strings.

To use an array of SharePoint claims users as a destination K2 will require the users be converted to an array of K2 fully qualified name users. The To K2 FQN User() (String[]) can be used to do just that.

For more information, see the topic Inline Functions - Conversion in the K2 blackpearl User Guide.

In addition to the specific user conversion functions the standard Text and List functions, such as Split, Join and Index, can be used to parse the SharePoint Claim User string for values such as the identity provider and identity claims. The SharePoint claims user value for Bob using the Forms Authentication provider will be in the following format: i:0#.f|ldapmembershipprovider|bob.

The Index inline function will provide access to the third element in the array that we create by using the Split function to retrieve the elements between the pipe (“|”) character.

The Values will be the results of the Split function using the | character as the separator.

The Index is set to 3 to retrieve the identity claim value.

The result of this inline function at runtime will be just the identity claim value portion of the SharePoint claims user.

For more information on SharePoint claims users encoding, see the AttributeValue topic in the SharePoint Security Token Service Web Service Protocol Specification: http://msdn.microsoft.com/en-us/library/dd932259(v=office.12).aspx.