4me can be configured to use an organization’s existing identity provider (such as Microsoft Active Directory, OneLogin, the Okta Application Network, etc.) instead of 4me’s own authentication mechanism to determine whether a user should be given access to 4me.
By using an existing identity provider, the organization’s 4me users (including the end-users who need to be able to use Self Service) will not require a separate password to access 4me.
SAML-based Single Sign-On Transaction Steps
The image above illustrates the following 10 steps that complete one SAML-based SSO transaction:
The user attempts to access the 4me account of his/her organization using a browser application such as Microsoft Internet Explorer, Google Chrome, etc.
4me looks up the settings of the 4me account of the user’s organization and sees that SSO has been configured in this account. That is why, rather than prompting the user for an email address and password, 4me generates a SAML authentication request. 4me then encodes this SAML authentication request and embeds it into a redirect URL that is intended for the SSO service of the identity provider that the user’s organization uses. Also embedded in the redirect URL is the encoded destination URL within the 4me account that the user is trying to reach.
4me sends the redirect URL to the user’s browser.
The user’s browser redirects to identity provider’s SSO service.
The identity provider decodes the SAML request and extracts the destination URL. The identity provider then authenticates the user.
The identity provider generates a SAML response that contains the authenticated email address of the user and the destination URL. In accordance with the SAML 2.0 specification, this response is digitally signed with the identity provider’s public and private DSA/RSA keys.
The identity provider encodes the SAML response along with the user’s email address and destination URL, and provides a mechanism so that the user’s browser will forward this information to 4me.
The user’s browser forwards the encoded information to 4me.
4me verifies the SAML response using the SHA1 fingerprint of the identity provider’s SAML certificate. If the SAML response includes just-in-time provisioning attributes, the JIT End User Access Provisioning functionality is triggered to automatically generate a new person record if one does not yet exist with the user’s email address, or to automatically update the user’s person record in 4me.
If the SAML response is successfully verified, and the necessary just-in-time provisioning actions have been completed successfully, 4me redirects the user to the destination URL within the 4me account of the user’s organization. The user is now logged in to 4me.
How to Enable SSO for 4me
To make SSO work for an organization’s 4me account, the 4me account owner will need the following information:
the remote login URL of the organization’s identity provider (also known as the SAML Single Sign-On URL),
the SHA1 fingerprint of the identity provider’s SAML certificate.
This information can then be entered by the 4me account owner in the Single Sign-On section of the Settings console.
Once SSO has been enabled, the account owner can check whether it works by logging out of 4me and subsequently trying to access 4me again by going to the URL of the 4me account. If the account owner is already logged in to the identity provider, 4me should no longer ask for an email address and password. Instead, the account owner is directly taken to the 4me inbox.
Using the SSO Configuration of the Directory Account
Support domain accounts are able to use the single sign-on configuration of their directory account. After SSO has been enabled in a directory account, the checkbox ‘Login using SSO configuration of directory account’ becomes available.
Checking this box hides the SAML SSO URL field as well as the Certificate fingerprint field. The values for these fields are obtained from the directory account when this feature is in use.
Secure Hash Algorithm
The following secure hash algorithms are supported by 4me:
If SSO has been enabled for an 4me account, but it does not appear to work, then the account owner can access 4me again by adding
/access/normal to the URL of the 4me account. Once the owner is back in 4me, the System Logs section of the Settings Console can provide some useful information about why SSO is not working. Whenever there has been an authentication failure, an entry will have been added to the log with an explanation of what went wrong.
Another useful source of information is the SAML meta data.
Also keep in mind that the clock of the servers of the identity provider need to be synchronized. If the clock is more that 2 seconds out of sync, the SAML response from the identity provider will not be accepted by 4me.