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.
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 1583219225 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
- the desired authentication methods have been configured:
- for the site (under the Site Methods tab of the site) and
- for the application (under the Allowed Methods tab of the application)
- the user group of any test user is added to the Allowed To tab of the application.
- the desired authentication methods have been configured:
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 addresshttps://sso.example.com:8443/uas/wsf/FederationMetadata.xml
(Replacesso.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
inFederationMetadata.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 theLogonTokenCacheExpirationWindow
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:
- Go to Central Administration → Manage Web Applications → SharePoint - 443 → User Policy.
- Click "Add Users" and select "Default" as the zone.
- 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 |