Many clients have Single Sign On (SSO) enabled on their instance of Collaborate. SSO is a feature that permits a user to be automatically logged in to Collaborate once they have logged in to their corporate network, without the need to enter a password or save their password using the "Remember me" option. Currently, SSO is based on the client providing HighQ with a list of all of its corporate IP addresses. If Collaborate detects that a user is coming from one of those IP addresses, it will try to automatically log the user in using their Windows session via ADFS (Active Directory Federation Services), or similar technology. This is referred to as pass-through authentication.
The HighQ platform uses a standard ADFS setup. If your system uses ADFS, then it can use SSO with HighQ.
Below is a primer on how end users will experience SSO.
The end-user experience
Even with SSO enabled a user first needs to have an account created in Collaborate, which can be done by adding that user to a site. If Active Directory/LDAP integration is used, Active Directory will provide an alternate mechanism for creating user accounts in Collaborate.
New user invitations and passwords
Typically, when a new user is added to a Collaborate site, the user is sent an email invitation with a link. Clicking on this link brings up a page asking the user to set their Collaborate password. Even with SSO enabled, when a new internal user, who has not yet set their password, clicks on the email invitation link, they will see the page requesting the user to set their password, rather than simply having SSO directly log the user in to Collaborate.
A user who has an active Collaborate account but has never created a password will, like every other user, be presented with the login page when accessing Collaborate from outside the network. However, because this user does not have a password, they may not know how to proceed. In that case, the user must click on the "Reset Password" link and create their password using the reset password process.
Password Reset
The reset password process is unchanged. With SSO enabled, if a user attempts to reset their password, they will receive the reset password email and may click on the link to initiate the password reset process.
If a user "logs" into Collaborate, either through SSO or manually, any unused password reset links will be deactivated, as the System has determined that the user does not in fact need to reset their password.
Login page and logging out
If an active user goes to the Collaborate login page, they are presented with the manual login page. This allows the user to, for example, change their password.
If the user who is on the login page wishes to access Collaborate via SSO, they will need to truncate the current URL and remove the "LoginRequiredPage.action" part of the URL. This means that if users are going to bookmark a page to access Collaborate directly using SSO, it should not be to the login page. A good approach is to bookmark the link to the Dashboard.
If a user clicks on the "Logout" link, they will be signed out and taken to the login page. However, there is no reason for a user to logout when they are inside the network, as they can simply log themselves back in automatically with SSO.
Archived accounts
If a user's Collaborate account has been archived and the user attempts to access Collaborate, that user will be presented with the login page, even if SSO has been enabled. They will see the login page and a login error message.
The user's account can be reactivated only if the user is added to a site, or if a System Administrator specifically reactivates the user's account.
Different client instances with SSO enabled
If two separate firms have SSO enabled on their own instances of Collaborate and a user from one firm is invited to a site on the other firm's instance, that user will be able to access the other firm's Collaborate instance using SSO, assuming that the user's email address is the same in both instances. For example, Acme Corp and Zebra Corp both have Collaborate instances with SSO enabled. Joe from Acme Corp (joe@acme-corp.com) is invited to a site on Zebra Corp's Collaborate instance. If Joe accesses the Zebra Corp instance from inside of Acme Corp's network, he will be able to access Zebra's instance directly, without logging in or needing to set a password, provided that Joe's email address in the Zebra Corp instance is listed the same way ("joe@acme-corp.com").
Single Sign-On using a SAML provider
Users can also authenticate via a SAML provider (Security Assertion Markup Language) unrelated to a firm's range of IP addresses. This enhancement also includes the ability to restrict users in a particular organisation from logging in with their Collaborate credentials. If that setting is enabled when SSO has been implemented, then the affected users will only be able to access Collaborate via SSO.
Single Sign-On/SAML
The current implementation of Single Sign On (SSO) is based on a client providing HighQ with a list of the IP addresses (or range of IP addresses) for the client's offices. A user accessing Collaborate from any of those IP addresses with the appropriate email domain will automatically be logged in using their Windows login or similar, provided they already have an account in Collaborate. SSO permits users to avoid manually entering their Collaborate login credentials to access Collaborate.
Collaborate provides an additional and/or alternate method for users to log in to Collaborate while bypassing the need to enter Collaborate login credentials. If a client has a SAML provider they use for accessing third-party web services, then that SAML provider can also be used to allow their users to authenticate into Collaborate.
There are three ways that users can be granted to authenticate with Collaborate:
- Using their manual Collaborate credentials,
- Via IP-address based SSO, or
- By using a SAML provider, which may require that the user first log in to their SAML provider and create a SAML session.
As noted above, the SAML-provider approach can be used in conjunction with or as an alternative to IP-address based SSO. Further, Collaborate can be configured so these users can be barred from authenticating with Collaborate using Collaborate credentials.
Key benefits
- No need to remember Collaborate credentials - Users who typically use SSO to authenticate will often not remember their Collaborate credentials, as they manually login only on rare occasions. (This might compel them to use the reset password approach.) With the SAML-provider authentication approach, users simply need to enter their SAML credentials, which they may use in many contexts and therefore will remember those credentials. A client's SAML provider may also have enhanced security requirements for authenticating, such as a multi-factor authentication mechanism.
- Option to restrict the use of Collaborate credentials - The other advantage is that a user can be restricted from using, or even setting, Collaborate credentials, so that the user can log in only by using SSO/SAML. This provides a client with a way of better managing their own users' access and to ensure that users who have left a client's employ no longer have access to Collaborate, as presumably the user's SAML account will have been disabled. This setting can be enabled on the System Admin > Org Admin page for a specific organisation, by enabling the "Restrict direct login" checkbox:
This setting can be enabled for any organisation, even those that do not use IP-address based SSO or a SAML provider. If this feature is turned on when only IP-address based SSO is enabled, then client users will only be able to access Collaborate from inside the network.
Other Changes When SAML is used
If SAML-provider authentication is enabled, when a user attempts to access Collaborate and has a SAML session, they will automatically be logged in to Collaborate. Otherwise, a user will need to manually login to SAML to create a session.
- Like the existing IP-address-based SSO, logging in via a SAML provider will bypass Collaborate's two-factor authentication, if that feature had been enabled. However, if the SAML provider uses its own two-factor authentication mechanism, that mechanism will be respected when a user attempts to authenticate with their SAML provider.
- An additional link will be added to the Collaborate login page to permit client users to access the login page for their SAML provider. As noted below, the name and URL for this link must be provided. (If a client has a custom login page, then this login page must be altered to include the link to the SAML provider login page.) After the user logs in manually to the SAML provider, they will be redirected back to Collaborate, with a logged-in session.
Other Changes When Direct Logins are Restricted
Here are a few other changes that affect users who are in an organisation that cannot directly login to Collaborate.
Additional information will be provided to the client to complete setup.
- When such a user attempts to log in manually from the login page, they will automatically be forwarded to the SAML-provider login page instead.
- When such a user attempts a password reset from the login page, they will receive an email that states: "The password for this account cannot be reset because you are required to Log in with [name of SAML provider]," the latter part is a link to the SAML-provider login page.
- When a System Admin attempts a reset password from the System Admin console for such a user, no "Reset Password" link will be shown next to that user's name.
- When such a user receives a site invitation, the invitation email never prompts the user to set a password. Instead, the email notification merely indicates that the user has been invited to the site and can click on a link to login. The link will take the user to the manual login page if the user does not have an active SAML session.
SAML-Provider Implementation
In order to implement authenticating with Collaborate via a SAML provider, the client must provide this information to HighQ, which will configure the feature:
- The fully qualified domain name of the SAML 2.0 server
- The URL of the IdP Metadata XML or a Metadata XML File
- Email domain(s) that can authenticate via SSO/SAML
- The name to provide for the manual federated login link, which will appear on the login page and in reset password emails
