SharePoint 2013 Claims Integration with K2 blackpearl API through WCF

Create SharePoint STS Trust with K2

• SharePoint 2010 components require that K2 trust the SharePoint STS. Since the installer has not been creating the trust relationship for me, below are my steps to manually configure K2 to trust SharePoint.
  
  
• First, lets make sure we are working of the correct issue. The instruction sbelow deal with an issue that manifests as failures in the K2 SharePoint Configuration page  as a blank environment dropdown and a failure to run the configuration

• A blank environmental dropdown field in a SP 2010 for 2013 K2 site is the most obvious sign of an STS trust failure.
  
  

• If the Configuration is attempted with the blank environment, ULS Log errors will show errors similar to the following

  SPApplicationAuthenticationModule: Authorization header doesn't contain Bearer, can't try to perform application authentication. The Request Management Service is offline or unprovisioned. Request Management is disabled. Status = {0} SPAce PrincipalName found account renamed to NULL SID. Using new name. Cannot find site lookup info for request Uri urn:schemas-microsoft-com:sharepoint:service.

• There are two steps required to make the SP 2010 components function:

1. Add Claims mappings to K2HostServer.exe.config
2. Create a SharePoint STS trust in K2

Step 1

The first step is to update C:Program Files (x86)K2 blackpearlHost ServerBinK2HostServer.exe.config with the appropriate claim mappings and Issuers.

• Run the attached Get-ClaimTypeMapping.ps1 PowerShell script in a SharePoint 2013 Management Shell on a SharePoint.  This script will render the claims xml needed to add to K2HostServer.exe.config
  
  Syntax: .Get-ClaimTypeMappings.ps1 -WebAppUrl https://FQDN -WindowsK2SecurityLabel K2 -OutputFilename ClaimTypeMappings.xml
• Open the output file and copy the contents into K2HostServer.exe.config just above the closing configuration tag.

Step-2

The next step is to update the K2 Database

• Posts suggesting this can be fixed by creating a new Claim Issuer entry using K2 Designer are only partially correct. There are everal entries needed across 4 different tables and the method described is only one piece of the puzzle. The least error-prone way to update the configuration is to use the following SQL script.
  **This script is also attached below.

USE K2

-- Set ThumbPrint equal to the resulting value from the following SharePoint PowerShell Command
-- (Get-SPServiceApplication -Name SecurityTokenServiceApplication).SigningCertificateThumbprint 

DECLARE @issuerId INT, @ThumbPrint VARCHAR(50)
SET @ThumbPrint = '<INSERT_STS_THUMBPRINT_HERE>'


INSERT INTO [Identity].[ClaimIssuer] (Name,Description, Issuer, Thumbprint, Uri, UseForLogin)
    VALUES ('SharePoint Windows STS', 'SharePoint Windows Authentication', 'SharePoint', @ThumbPrint, null, 0)
    SET @issuerId = SCOPE_IDENTITY();


UPDATE [Identity].[ClaimTypeMapping] 
    SETIssuerID=@issuerId
    WHERE ID=2  


UPDATE[Identity].[ClaimTypeMap] 
    SET ClaimType = 'http://schemas.microsoft.com/sharepoint/2009/08/claims/userlogonname' 
    WHERE ID=3


INSERT INTO [Identity].[ClaimTypeMap] (ClaimTypeMappingID, ClaimMappingType, OriginalIssuer, ClaimType, ClaimValue)
    VALUES (2,'IdentityProviderClaim', 'SecurityTokenService', 'http://schemas.microsoft.com/sharepoint/2009/08/claims/identityprovider', 'windows' 
 

 Once both steps are complete, restart the K2 service.