Claims Supported Configurations (SharePoint 2010)

This topic refers to legacy products, components or features. Therefore, this topic is offered "as is" and will no longer be updated. This topic does not infer that the product, component or feature is supported, or that the product, component or feature will continue to function as described herein.

K2 supports integration with SharePoint 2010 web applications in either classic mode authentication or claims-based authentication when configured according to the details in this section.

SharePoint 2010 claims-based authentication web sites by default are configured to allow the saving of the bootstrap tokens in the IClaimsIdentity and Sessions after token validation. K2 requires the bootstrap token to be present for proper validation of original claim issuers.
The <servicesaveBootstrapTokens="true"> setting can be found in the <microsoft.identityModel> section of the web.config for the claims-based web site and must be set to true.

SharePoint 2010 Claims Authentication Types

Negotiate (Kerberos) is the recommended security configuration to use with Windows authentication. If this option is selected and Kerberos is not configured, NTLM will be used. For Kerberos, the application pool account needs to be Network Service or an account that has been configured by the domain administrator. NTLM authentication will work with any application pool account and with the default domain configuration.

Basic authentication is a sub-option of Windows authentication and is used as a fallback if Integrated Windows authentication is selected and not available.

Basic authentication method passes user credentials over a network in an unencrypted form. If you select this option, ensure that Secure Sockets Layer (SSL) is enabled.

K2 requires that Windows authentication is configured for Integrated Windows authentication using either NTLM or Negotiate (Kerberos) on all zones of claims enabled web applications that have K2 for SharePoint integration components activated.

ASP.NET membership and role provider are used to enable Forms Based Authentication (FBA) for a Web application. After you create an FBA Web application, additional configuration is required. For more information, see Configure forms-based authentication for a claims-based Web application (SharePoint Server 2010): http://technet.microsoft.com/en-us/library/ee806890.aspx

K2 has tested Forms Based Authentication configured for Microsoft’s LDAP Providers.

  • Membership Provider: Microsoft.Office.Server.Security.LdapMembershipProvider
  • Role Provider: Microsoft.Office.Server.Security.LdapRoleProvider

Disclaimer: K2 is expected to be configurable for any Forms Authentication Providers that have been properly configured and proven to work with SharePoint 2010. However, only Microsoft’s LDAP Membership and Role Providers have been tested.

Trusted Identity Provider Authentication enables federated users for a Web application. This authentication is Claims token based and the user is redirected to a login form for authentication.

K2 has tested Trusted Identity Provider configured for AD FS 2.0 with Active Directory and LDAP attribute stores. For more information, see Configuring SharePoint 2010 and ADFS v2 End to End: http://blogs.technet.com/b/speschka/archive/2010/07/30/speschka.aspx

The claim rules tested vary based on the attribute store used.

Rule: Windows Claim

  • Claim rule template: Pass Through or Filter an Incoming Claim.
  • Claim rule name: Windows Account Name Claim.
  • Incoming claim Type: Windows account name.
  • Pass through all claim values: Selected.

Rule: LDAP Claims

  • Claim rule template: Send LDAP Attributes as Claims.
  • Claim rule name: LDAP Claims.
  • Attribute Store: Active Directory.
  • Mapping of LDAP attributes to outgoing claim types.
LDAP Attribute Outgoing Claim Type
Token-Groups – Qualified by Domain Name Role
E-Mail-Addresses E-Mail-Addresses

Rule: LDAP Claims

  • Claim rule template: Send LDAP Attributes as Claims.
  • Attribute Store: LDAP.
  • Mapping of LDAP attributes to outgoing claim types.
LDAP Attribute Outgoing Claim Type
SAM-Account-Name Name
Token-Groups- Unqualified Names Role
E-Mail-Addresses E-Mail-Addresses

Disclaimer: K2 is expected to be configurable for any Trusted Identity Providers that have been properly configured and proven to work with SharePoint 2010. However, only Microsoft’s AD FS 2.0 has been tested.

 

Overview

The K2 installer creates a claims-based authentication configuration during the installation process. The configuration is stored in the K2 database and can be managed through the claims and OAuth management forms.

Legacy Configurations

Prior to K2 blackpearl 4.6.7, the claims configuration supported a single Claims authentication connection and was configured in various config files. This legacy section is kept for those needing to find those configuration settings and those customers who have not upgraded to K2 blackpearl 4.6.7 or later.

K2 allows for the use of incoming claims from SharePoint 2010 claims authentication enabled sites.  K2 must be configured to register the SharePoint Security Token Service (STS) certificates and map the incoming claims that contain user and group information to the appropriate K2 User Manager.  This section explains the configuration settings required and how to determine them.

Example
The following example is for the fictitious Denallix.com SharePoint claims based site on a single server with user mappings configured for Windows (Active Directory), Forms (LDAP) and a Trusted Provider (AD FS for LDAP).

<sourcecode.security.claims>
  <!-- The combination of issuers and claimTypeMappings allows K2 to ensure incoming claims are valid and have not been tampered with -->
  <issuers>
    <!-- An entry for each certificate (signing or encrypting) for a trusted STS -->
    <issuer name="SharePoint Security Token Service" thumbprint="8BD27388714EC92EA0433BE660BA7698430CE4FF" />
    <issuer name="SharePoint Security Token Service Encryption" thumbprint="54722E70106DF64E48DD2FF2AFC8BC4F8DE231B1" />
  </issuers>
  <claimTypeMappings>
    <!--K2ADFS Security/Role Provider for Trusted Provider-->
    <claimTypeMapping securityLabel="K2ADFS">
      <!-- Claim that represents the system issuing the identity and role claims to be mapped to the K2 security label-->
      <identityProviderClaim originalIssuer="SecurityTokenService" claimType="http://schemas.microsoft.com/sharepoint/2009/08/claims/identityprovider" claimValue="trusted:ADFS LDAP" />
      <!-- Claim that represents the user for the K2 security label-->
      <identityClaim originalIssuer="TrustedProvider:ADFS LDAP" claimType="http://schemas.k2.com/identity/claims/name" />
      <!-- Claim that represents the groups for the K2 security label-->
      <roleClaim originalIssuer="TrustedProvider:ADFS LDAP" claimType="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" />
    </claimTypeMapping>
    <!--K2 Security/Role Provider for Windows Authentication-->
    <claimTypeMapping securityLabel="K2">
      <!-- Claim that represents the system issuing the identity and role claims to be mapped to the K2 security label-->
      <identityProviderClaim originalIssuer="SecurityTokenService" claimType="http://schemas.microsoft.com/sharepoint/2009/08/claims/identityprovider" claimValue="windows" />
      <!-- Claim that represents the user for the K2 security label-->
      <identityClaim originalIssuer="Windows" claimType="http://schemas.microsoft.com/sharepoint/2009/08/claims/userlogonname" />
      <!-- Claim that represents the groups for the K2 security label-->
      <roleClaim originalIssuer="Windows" claimType="http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid" />
    </claimTypeMapping>
    <!--K2FORMS Security/Role Provider for Forms Authentication-->
    <claimTypeMapping securityLabel="K2FORMS">
      <!-- Claim that represents the system issuing the identity and role claims to be mapped to the K2 security label-->
      <identityProviderClaim originalIssuer="SecurityTokenService" claimType="http://schemas.microsoft.com/sharepoint/2009/08/claims/identityprovider" claimValue="forms:LdapMembershipProvider" />
      <!-- Claim that represents the user for the K2 security label-->
      <identityClaim originalIssuer="Forms:LdapMembershipProvider" claimType="http://schemas.microsoft.com/sharepoint/2009/08/claims/userlogonname" />
      <!-- Claim that represents the groups for the K2 security label-->
      <roleClaim originalIssuer="Forms:LdapRoleProvider" claimType="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" />
    </claimTypeMapping>
  </claimTypeMappings>
</sourcecode.security.claims>

Issuers

K2 supports a one-to-many mapping between K2 and the certificates that the SharePoint STS uses to sign (SharePoint Security Token Service) and encrypt (SharePoint Security Token Service Encryption) the security tokens it issues.  The default installation of SharePoint will generate and store individual certificates for both signing and encrypting on each server in the farm.  The image highlights the values required for an <issuer> entry – the name and thumbprint for each individual signing and encrypting certificate for the STS.

Claim Type Mappings

K2 recommends a one-to-one mapping between a K2 User Manager (UM) and an incoming claim set Identity Provider (IP).  Each <claimTypeMapping> will contain an entry for the Security Label of the associated K2 UM and three claim types to be mapped from the IP: Identity Provider, Identity and Role. 

It is recommended that one K2 User Manager is mapped to a single Identity Provider.  However, if more than one mapping is required, the runtime resolution of users is determined by the order they are registered in the <sourcecode.security.claims> configuration.  Furthermore, it is recommended that the Windows Identity Provider, typically used for service accounts only, be the last one registered in the <sourcecode.security.claims> configuration.

The image below highlights the values required for a <claimTypeMapping>.  The claimTypeMapping requires a unique K2 UM securityLabel to be configured.  The identityProviderClaim requires an originalIssuer, claimType and claimTypeValue to be configured while the identityClaim and roleClaim require originalIssuer and claimType to be configured.

Legend

1  Identity Provider
2  Identity
3  Role

K2 requires the claimType for the identityClaim to match the claim mapping configured in SharePoint as the Identifier Claim. The K2 Server Configuration section provides automatic and manual approaches that aid in configuring the appropriate identity claim type mapping for K2.

K2 Server Configuration

The <sourcecode.security.claims> section must be manually added to the K2HostServer.exe.config file.  However, the method used to generate the configuration section values can be automatically generated or manual. Using the automatically generated approach is recommended.

Automatically Generated Approach

This option requires the use of PowerShell scripts available as a download for this topic that will interrogate a SharePoint 2010 claims configuration and automatically generate all the resulting <sourcecode.security.claims>  configuration section for K2HostServer.exe.config.

SharePoint Central Administration
Run these commands on the SharePoint Central Administration server or for single server farm configurations.

  1. Download and extract the Get-ClaimTypeMappings.ps1 script.
  2. Start SharePoint 2010 Management Shell.
  3. Execute Get-ClaimTypeMappings.ps1 and provide the values requested at the prompts.
    1. For more information on the options available, execute:
      Get-Help .\Get-ClaimTypeMappings.ps1
    2. NOTE: The script will stop executing if the SharePoint environment is not properly configured for K2 claims support. 
  4. Open the [Installation Directory]\Host Server\Bin\K2HostServer.exe.config file.
  5. Add the resulting <sourcecode.security.claims> XML to the end of the <configuration> section.
  6. Save the file and restart the K2 blackpearl Server service.

SharePoint Web Front Ends
Additionally, run these commands on the SharePoint web front ends for multi-server farm configurations.

  1. Download and extract the Get-AdditionalIssuers.ps1
  2. Start SharePoint 2010 Management Shell
  3. Execute Get-AdditionalIssuers.ps1
  4. Open the [Installation Directory]\Host Server\Bin\K2HostServer.exe.config file
  5. Add the resulting <issuer> XML to the end of the <configuration><sourcecode.security.claims><issuers> section
  6. Save the file and restart the K2 blackpearl Server service
  7. Once the K2 Server has restarted an IISRESET will be required

    Download: You can download the SourceCode.Security.Claims sample scripts by clicking here.

Manually Generated Approach

This option requires extensive knowledge of the SharePoint claims configuration and optionally the use of the community provided SourceCode.Samples.Claims.WebPart.

The image below highlights the values required in K2HostServer.exe.config as returned by the SourceCode.Samples.Claims.WebPart.

Legend

1  Identity Provider
2  Identity
3  Role

  1. Download and install the SourceCode.Samples.Claims.WebPart
  2. Open the [Installation Directory]\Host Server\Bin\K2HostServer.exe.config file
  3. Add the example <sourcecode.security.claims> XML from this topic to the end of the <configuration> section
  4. Update the values in the example with the values from your environment for
    1. Issuers – certificate name and thumbprint for SharePoint Security Token Service and SharePoint Security Token Service Encryption certificates for all servers in the farm.  These values can be determined by using the MMC Certificates Snap-in and navigating to the Local Computer\SharePoint\Certificates node or using the SharePoint 2010 Management Shell and executing the following PowerShell commands.

      (Get-SPServiceApplication -Name SecurityTokenServiceApplication).SigningCertificateThumbprint
       (Get-SPServiceApplication -Name SecurityTokenServiceApplication).EncryptionCertificateThumbprint

    2. Claim Type Mappings – identity provider claim, identity claim and role claim for each authentication provider associated with the web application.  These values can be determined from the scripts used to configure SharePoint for claims authentication or the community provided web part.
  5. Save the file and restart the K2 blackpearl Server service
  6. Once the K2 Server has restarted an IISRESET will be required 

Download: You can download the SourceCode.Sample.Claims.WebParts sample scripts by clicking here.

The SourceCode.Sample.Claims.WebPart is provided as an example only.

SharePoint Multi-Authentication

SharePoint supports implementing more than one claims authentication type on a single web application zone. Microsoft recommends when using claims authentication and implementing more than one type of authentication, that you implement multiple types of authentication on the default zone. This results in the same URL for all users. For more information, see Planning Zones for Web applications: http://technet.microsoft.com/en-us/library/cc262350.aspx#section6.

The Microsoft SharePoint Search crawl component requires that Windows authentication is configured for Integrated Windows authentication using either NTLM or Negotiate (Kerberos) to access the content of the Web application.

K2 also requires that Windows authentication is configured for Integrated Windows authentication using either NTLM or Negotiate (Kerberos) on all zones of claims enabled web applications that have K2 for SharePoint integration components activated.

The SharePoint crawl component and K2 server utilize the Protocol Discovery Request defined in the Office Forms Based Authentication Protocol Specification to interact with claims based Web applications from Windows based service accounts. The specification provides for the use of request headers to enable authentication through services without login forms.

For more information, see the Protocol Discovery Requests topic in the Office Forms Based Authentication Protocol Specification: http://msdn.microsoft.com/en-us/library/dd773463(v=office.12).aspx.

Supported
The following SharePoint 2010 multi-authentication combinations are supported by K2.

Classic Mode

  • Windows

Claims Mode

  • Windows
  • Windows + FBA
  • Windows + Trusted
  • Windows + FBA + Trusted

Not Supported

The following SharePoint 2010 multi-authentication combinations are not supported by K2.

  • FBA (requires Windows on same zone, see above)
  • Anonymous
  • FBA + Anonymous
  • Trusted (requires Windows on same zone, see above)

SharePoint 2007 forms-based authentication is not supported by K2.

Claims customers are required to implement Windows Authentication on the same zone as they plan to utilize for process design time and runtime. Designing against one SharePoint URL and executing against another SharePoint URL is currently not supported. Not having Windows Authentication enabled on the design time URL is not supported. The following article includes some potential workarounds: http://msdn.microsoft.com/en-us/library/hh237665.aspx. However, it is not necessary to complete all steps that this article describes as there is no need for custom code. The two configuration steps below will enable Windows Authentication for K2 and suppress the Windows Authentication from the designers and runtime users in SharePoint.

Step 1 can be followed if Active Directory users in the people picker are not necessary. Step 2 can be followed if the Active Directory users in the people picker are indeed necessary.

Step 1 – Disable AD in People Picker

  • Run the following commands from a SharePoint Management Shell to disable AD users from appearing in People Picker.

$cpm = Get-SPClaimProviderManager
$ad = Get-SPClaimProvider -Identity "AD"
$ad.IsVisible = $false
$cpm.Update()

Step 2 – Configure Single Login

  • Navigate to Central Administration > Manage Web Applications.
  • Select the claims-based web application and click Authentication Providers.
  • Select the zone with Windows Authentication + (Trusted and/or Forms Based Authentication).
  • Change the Sign In Page URL to Custom Sign In Page and enter the URL for either Trusted or Forms Based Authentication.

NOTE: One provider needs to be picked to bypass the drop down.

  • Trusted – replace {ProviderName} with the name of your provider, for example: ADFS LDAP

/_trust/default.aspx?trust={ProviderName}&ReturnUrl=/_layouts/Authenticate.aspx?Source=%2F&Source=%2F