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.

TIP: Only one certificate can be used with a single security token service (STS) instance. Please see the article Plan server-to-server authentication in Microsoft TechNet for further information.

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

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

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 2868642329 for detailed instructions.

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

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.
Set the Compatibility Flags field to
MetadataCertificate AssertionSignCertificate TokenTypeSAML11

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

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

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
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
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
Add the allowed user groups to the "Allowed To" tab

Figure 6. Adding user groups
Ensure that Ubisecure SSO home page (Home → Server → Compatibility Flag field includes MetadataCertificate.

Figure 7. Confirming that the required compatibility flag is included
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)
Extract the certificate from the metadata and save using the name UASWSF.cer

Figure 8. Extracting the certificate form the metadata
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
Open the SharePoint 2013 Management Shell and run it as Administrator.

Figure 10. Starting the SharePoint Management Shell as an Administrator

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

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
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
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]
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
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;

TIP: If there are any problems adding the users, double-check that the default zone is used

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


Figure 14. Giving users rights based on claims from the Ubisecure SSO

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.


Figure 15. Finding "Bindings" from the IIS Manager

Choose Edit and verify that an SSL certificate is installed.


Figure 16. Installing an SSL certificate for the site

Browser not supported