Federated Identity and Single Sign-On

Owned by RecordPoint (Unlicensed)
Last updated: Dec 15, 2016
4 min read
 Article Contents

Overview

As of version 3.9, RecordPoint adds support for the use of Trusted Identity Providers in the SharePoint web applications that it is deployed to. 

This document outlines the various considerations to be taken in to account when deploying RecordPoint to an environment that uses a Trusted Identity Provider. This guide applies to any identity provider that supports SAML 1.1 and that supports SharePoint 2013.

This information applies to RecordPoint for SharePoint 2013 version 3.9 and above.

Sharing with All Users

When content is to be shared with all users, be aware that NT AUTHORITY\Authenticated Users is not a valid entity under a Trusted Identity Provider. Prefer to use "All Users (<Issuer Name>) instead". For example, if your Trusted Identity Token Issuer is called "Contoso ADFS", the group name is "All Users (Contoso ADFS)". 

In the current RecordPoint release there are several SharePoint lists within RecordPoint that are shared with NT AUTHORITY\Authenticated Users by default, to allow the object to be accessed by any user. This doesn't work as intended when signing in with a Trusted Identity Provider. 

To work around this, these lists must be shared with "All Users (<Issuer Name>)": 

  1. RecordPointUserStorage
  2. RecordPoint Requests
  3. RecordPoint Delete Requests (if the Delete Request Processing Infrastructure feature is enabled in Central Administration)
  4. RecordPoint Transfer Batch Numbers

Furthermore, each list item in the "Pages" list must be shared as well.

For your convenience we provide an example PowerShell script to automate this process, ADFSApplyPermissions.ps1: ADFSApplyPermissions.ps1

People Picker

The People Picker in SharePoint behaves differently in web applications that use a Trusted Identity Provider. The People Picker will resolve any string entered as a correct user name, even if the value doesn't correspond to an actual user name or UPN in the identity provider. 

SharePoint doesn't have a mechanism to search the user directory that underlies the Trusted Identity Provider by default, so it simply treats all user names as valid. 

See here for more information and alternatives to this SharePoint default behavior: https://blogs.msdn.microsoft.com/kaevans/2013/05/26/fixing-people-picker-for-saml-claims-users-using-ldap/ 

Internet Explorer 11 Compatibility View

When Internet Explorer 11 is used with the default settings, the SharePoint People Picker will not correctly resolve user names from a Trusted Identity Provider. When a user name is resolved with the "Check Names" button, it shows up as a "mailto:" hyperlink. 

This is worked around by turning on Compatibility View for the site in Internet Explorer 11. This can be done from the Internet Explorer 11 Settings Menu and opening Compatibility View Settings. 

Cross Origin Considerations

Special consideration must be given to deployments that host many Web Applications on the same domain with different ports - for example, the RecordPoint Web Application is hosted on https://contoso.local:80/ and the Active Site Web Application is hosted on https://contoso.local:90/. 

In a deployment such as this, Internet Explorer treats the two web applications as being on the same domain, and will therefore use only one FedAuth cookie for both web applications. Users who log in to the RecordPoint Site will not be able to log in to the Active Site, and vice versa.

The solution is to modify the name given to the FedAuth cookie such that the name is unique for each Web Application. This ensures the browser will use one FedAuth cookie per Web Application.

The name of the FedAuth cookie can be specified in the Web Applications web.config file, in the cookieHandler element. An example is shown below: 

Ensure that a different name is given to the Active Site FedAuth cookie (e.g., "asFedAuth"). Ensure that the configuration change is made on all servers in the farm. 

Single Sign-On

There are several features in RecordPoint that communicate across Web Application boundaries via the browser. Examples include:

Record Summary from the Active Site (this calls from the Active Site in to the RecordPoint Site)

Finalize electronic content from the RecordPoint Site (this calls from the RecordPoint Site in to the Active Site)

RecordPoint can be configured to provide a Single Sign-On experience for these features - that is, end users only need to explicitly authenticate once, without having to explicitly log in to the other Web Application.

Note that to provide a single sign-on experience to your users, the same Trusted Identity Provider must be used across all Web Applications. 

Internet Explorer 11 Trusted Sites

The following sites must be added to the Trusted Sites list in Internet Explorer:

  • The Sign-in URL (e.g., the ADFS or Azure ACS site).
  • All Web Application URLs.

Be aware that Internet Explorer 11 will not delete any browser data for sites in the Trusted Sites list by default. To delete browser data for sites added to the Trusted Sites list, the "Preserve Favorites website data" checkbox in the "Delete Browsing History" dialog must be unchecked.

Multi-authentication Screen

A typical federated identity deployment has Web Applications configured with two identity providers in the Default Zone - Windows Authentication and a Trusted Identity Provider. With this configuration end user will see a multi-authentication prompt when they attempt to log in: 

 

This screen must be bypassed in order to provide a single sign-on experience: web service calls are unable to handle this screen and therefore cannot authenticate.

The multi-authentication screen may be bypassed by installing a custom sign-in page that redirects the user straight to the Trusted Identity Provider sign in page. 

Microsoft provide guidance on how this can be achieved here: https://blogs.msdn.microsoft.com/russmax/2014/10/31/bypassing-multiple-authentication-providers-in-sharepoint-2013/ 

Keep Me Logged In

Some Trusted Identity Providers will not transparently log in a user by default, and require the user to opt in to this process by checking a "Keep Me Logged In" or "Remember Me" checkbox when they log in. Be aware that single sign-on will only work if the user checks this checkbox when they log in.