SharePoint 2013 integration configuration - SSO

In this example configuration, the e-mail attribute of the user from Ubisecure SSO is the identifying claim. In addition, the user's role is transferred as an additional claim. The role determines the user's access rights. In a situation where all the users are stored in the Active Directory, using the UPN as the identifying claim might be a more appropriate choice. We start with the following assumptions:

• SharePoint 2013 has been installed to ad.local
• SSO has been installed to sso.example.com
• The SSL certificates are set up properly

If needed, a self-signed certificate can be generated quickly using IIS 7. For more information, please see the article Create a Self-Signed Server Certificate in IIS 7 in Microsoft TechNet.

Configuring SharePoint 2013 for claims-based authentication:

On the SharePoint server, open the SharePoint 2013 Management Shell and enter the following commands to set up a new claims-based WS-Federated authenticator:

• $cert=New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("c:\full\path\to\SharePoint-site-certificate.crt")

• New-SPTrustedRootAuthority -Name "Name for the Certificate" -Certificate $cert

• $email=New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" –SameAsIncoming

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

• $realm = "urn:sharepoint"

• $x=New-SPTrustedIdentityTokenIssuer -Name "Name for the authenticator" -Description "Description for the authenticator" -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $email,$role -SignInUrl " https://sso.example.com:8443/uas/wsf/PassiveRequestorService " -IdentifierClaim http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress

The value for the $realm can be chosen freely, but it must remain consistent throughout the configuration process.

The SignInUrl must correspond to the value used in the SSO installation. The value is found in the WS-federation metadata, please see 2011693593 for detailed instructions.

Configuring Ubisecure SSO as an IDP (claims provider) for SharePoint:

1. Create a new WS-Federation relaying party application in the Ubilogin Management application in an appropriate site. Ensure that
   1. the desired authentication methods have been configured:
      
      1. for the site (under the Site Methods tab of the site) and
      2. for the application (under the Allowed Methods tab of the application)
   2. the user group of any test user is added to the Allowed To tab of the application.

2. Set the Compatibility Flags field to
   MetadataCertificate AssertionSignCertificate TokenTypeSAML11


   Figure 1. Checking compatibility flags and activating the agent from the Ubisecure SSO interface

3. Activate the application by creating the required metadata about the SharePoint installation for the SSO. Use the following metadata as an example. 

   <EntityDescriptor ID="_7ad7a8b6-c123-462e-9e81-928bf42c8235"
     entityID="urn:sharepoint" xmlns="urn:oasis:names:tc:SAML:2.0:metadata">
     <RoleDescriptor xsi:type="fed:ApplicationServiceType"
         protocolSupportEnumeration="http://docs.oasis-open.org/ws-sx/ws-trust/200512 http://schemas.xmlsoap.org/ws/2005/02/trust http://docs.oasis-open.org/wsfed/federation/200706"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:fed="http://docs.oasis-open.org/wsfed/federation/200706">
         <fed:PassiveRequestorEndpoint>
              <EndpointReference xmlns="http://www.w3.org/2005/08/addressing">
                     <Address>https://ad.local/_trust/</Address>
              </EndpointReference>
         </fed:PassiveRequestorEndpoint>
     </RoleDescriptor>
   </EntityDescriptor> 

   Change the following parameters in the metadata:

   • "urn:sharepoint"= realm, which must correspond to the realm chosen when configuring SharePoint
   • "https://ad.local/_trust/" = SharePoint's WS-Federation endpoint

4. Activate the application using the previously created metadata: Application → New Application → Type WS-Federation → Activate → Paste text → OK

   Figure 2. Entering the metadata for agent activation

5. Create an Authorization Policy in Ubisecure SSO Management's Authorization Policy → Attributes tab with the following attributes:

   Name: emailaddress Name Format: http://schemas.xmlsoap.org/ws/2005/05/identity/claims Value: user:mail

   Name: role Name Format: http://schemas.microsoft.com/ws/2008/06/identity/claims Value: text: SharePoint Users

   Figure 3. Creating an Authorization Policy ("Claim rule")

   Attach the policy to the application from the Authorization Policy applications tab

   Figure 4. Adding the policy to the application

6. Add the desired authentication methods to the "Site Methods" tab in <site name> → Site Methods

   Figure 5. Adding the desired authentication methods for the site

7. Add the allowed user groups to the "Allowed To" tab

   Figure 6. Adding user groups

8. Ensure that Ubisecure SSO home page (Home → Server → Compatibility Flag field includes MetadataCertificate.

   Figure 7. Confirming that the required compatibility flag is included

9. Get the Ubisecure SSO WS-Federation metadata FederationMetadata.xml from the address https://sso.example.com:8443/uas/wsf/FederationMetadata.xml (Replace sso.example.com:8443 with your SSO server address)

10. Extract the certificate from the metadata and save using the name UASWSF.cer

    Figure 8. Extracting the certificate form the metadata

11. Find and record the value of PassiveRequestorEndpoint in FederationMetadata.xml. This will be used later as the $signinurl value.

    Figure 9. Extracting the $signinurl value from the metadata

12. Open the SharePoint 2013 Management Shell and run it as Administrator.

    Figure 10. Starting the SharePoint Management Shell as an Administrator

13. Execute the following commands in the SharePoint Management Shell:

    $certPath = "C:\path_to_certificate\UASWSF.cer" $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("$certPath") New-SPTrustedRootAuthority -Name "UAS Token Signing Trusted Root Authority" -Certificate $cert $map1 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" –SameAsIncoming $map2 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" -IncomingClaimTypeDisplayName "Role" –SameAsIncoming $realm = "urn:sharepoint" $signinurl = "https://sso.example.com:8443/uas/wsf/PassiveRequestorService" $ap = New-SPTrustedIdentityTokenIssuer -Name "sso.example.com" -Description "sso.example.com" -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1,$map2 -SignInUrl $signinurl -IdentifierClaim $map1.InputClaimType

    TIP: Write down the name given to the New-SPTrustedIndentityTokenIssuer. It will be needed in several upcoming steps.

    TIP: On the last step above, -IdentifierClaim must only list a single claim type to be used as the identifying claim, even if there are multiple claim mappings defined with -ClaimsMappings

14. Adjust the Cache expiration according to Microsoft requirements as stated in: https://msdn.microsoft.com/en-us/library/hh446526.aspx
    "Make sure that the value of the LogonTokenCacheExpirationWindow property is always less than the SAML token lifetime; otherwise, you'll see a loop whenever a user tries to access your SharePoint web application and keeps being redirected back to the token issuer."
    Adjust the cache expiration by executing the following commands at the SharePoint Management Shell:

    $ap = Get-SPSecurityTokenServiceConfig $ap.LogonTokenCacheExpirationWindow = New-TimeSpan -minutes 1 $ap.update() IIsreset

15. Open SharePoint 2013 Central Administration → Open Manage web application → New Web Application

    Figure 11. Creating a new web application in SharePoint

    Create the SharePoint site. Open the SharePoint Central Administration, navigate to Application management → Manage web applications and click the New Web Application Ribbon.

    Figure 12. Creating a new site collection in SharePoint

16. Configure the site as follows:
    
    

    IIS Web Site

    Create a new IIS web site: Name for the site

    Port: 443

    Security Configuration

    Allow Anonymous: No

    Use Secure Sockets Layer: yes

    Claims Authentication Types

    Uncheck Enable Windows Authentication

    Check: Trusted Identity Provider -> sso.example.com (the name given for the New-SPTrustedIdentityTokenIssuer in point 14)

    Public URL

    URL: https://ad.local:443

    Application pool

    Create new application pool -> Select a security account for this application pool -> Predefined [Network Service]

17. Open Central Administration → Create Site Collection and choose at minimum the title, the site template, and a user name for the primary site collection administrator

    Figure 13. Creating a new site collection in SharePoint

18. Set SharePoint permissions:
    1. Go to Central Administration → Manage Web Applications → SharePoint - 443 → User Policy.
    2. Click "Add Users" and select "Default" as the zone.
    3. The add users dialog appears. In the Choose Users field, you can specify which users belong to the authority being created. In this example, the role claim determines its access rights.

Add to Choose Users field:
c:0-.t|sso.example.com|SharePoint Users;


The field has the following syntax:
c:0-.t|sso.example.com|SharePoint Users;
It consists of the following parts:

• c:0-.t states for the role attribute, that is to say a claim that is the type of
  http://schemas.microsoft.com/ws/2008/06/identity/claims/role
• sso.example.com states the identity provider being used to generate the claims. This was defined in step 14 as the name for the New-SPTrustedIdentityTokenIssuer.
• SharePoint Users specifies the value that the claim must have. This can also be left blank to address all possible values.

This means that if a claim of type c:0-.t, a role claim, arrives from the name given for the in point 14 (sso.example.com) with the value "SharePoint Users", give the user the defined permissions.

It is also possible to authorize users by the e-mail address. For instance
i:05.t|sso.example.com|alice@mail.com;
would address a user, whose e-mail address is alice@mail.com. The i:05.t stands for the e-mail type of claim, i.e. a claim type of _http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress_
The claim types are defined in http://schemas.microsoft.com/ws/2008/06/identity/claims/role, some examples are:

• c:0-.t corresponds to Role
• i:05.t corresponds to e-mail
• i:0e.t corresponds to UPN

More information about defining the claim types can be found at: http://social.technet.microsoft.com/wiki/contents/articles/13921.sharepoint-2013-claims-encoding-also-valuable-for-sharepoint-2010.aspx

20. Verify that the SSL certificates are bound to the freshly created site:

Start the IIS manager → Sites → SharePoint – 443.

From the Actions sidebar, choose Bindings.

Choose Edit and verify that an SSL certificate is installed.