Single Sign-On & SAML

Introduction

This page provides an overview of single sign-on and SAML, as well as some general information about Fourth’s implementation. You may also want to read:

What are the benefits of single sign-on?

Single Sign-On (SSO) allows an end user to access multiple web applications using just the one set of credentials. This saves the user from needing to remember multiple usernames and passwords, while still providing strong authentication. And, once they have logged in, an end user can access other connected web apps without logging in again, until their authenticated session expires.

Fourth offers single sign-on across our platform, with customers, and to connected partners. Our partners use single sign-on because it:

• Outsources the authentication method and user's credentials to just one source (normally Fourth) to manage
• Gives partners the option to create "Just in time" accounts for legitimate end users
• Removes some of the hassle of managing user accounts by leveraging what Fourth already knows about the user
• Means end users are less likely to contact your support about authentication details
• Provides a great user experience, as the user doesn't need to log in multiple times or remember different credentials
• Makes our mutual customers happy!

Fourth offers SAML 2.0 for SSO integrations. Most of our partners use third-party software to manage SAML interactions, rather than building their own solution.

What is SAML?

Security Assertion Markup Language (SAML) is a popular, industry-standard, XML-based data exchange format used for SSO. It is an open standard, which means that you can develop your own SAML integration without additional licencing or access costs. There are a number of open source SAML toolkits available for different programming languages, and applications such as CRM systems will usually include the ability to manage SAML authentication. 

SAML roles

These entities are involved in a SAML interaction:

• Principle — normally an end user, which is the term we prefer to use.
• Client — the end user's browser.
• Identity Provider (IdP) — The system in charge of authenticating the end user.
• Service Provider (SP) — the application the end users is accessing.

How does it work?

SAML requires the SP and IdP to first establish a trusted relationship with one another. They do this during integration by providing each other with relevant metadata and certificates. They also agree on some configuration settings that determine what information is sent in SAML messages. One of these settings is the value that the two systems will use to identity the end user. This is called the Federation ID, and is often the end user's email address or their Fourth Account ID.

Once integrated, the IdP can begin authenticating users on behalf of the SP. These types of messages are sent between the SP and the IdP as part of the SAML process:

• AuthnRequest (SP to IdP): This is a request to authenticate a user. It is embedded within a redirect.
• SAML Assertion (IdP to SP): This is a signed XML document, containing the authentication details for the end user.

Both parties can initiate the process:

• IdP initiated: If an end user interacts with the IdP initially, then the IdP sends a SAML assertion to the SP when the user accesses the SP site. No AuthnRequest is required.
• SP initiated: If an end user interacts with the SP initially, the SP needs to send an AuthnRequest to the IdP. The IdP authenticates the user and then returns a SAML assertion. 

IdP-initiated workflow

This workflow is used between Fourth and our partners with connected apps, with Fourth acting as the IdP.

1. The user visits the IdP.
2. Once the user successfully authenticates, the IdP generates a SAML Assertion and sends this to the client. This contains:
   1. The user's Federation ID
   2. Additional data (attributes) about the user
   3. Data about how and when the user authenticated
   4. The X509 certificate public key of the IdP
3. The client both forwards the SAML Assertion and redirects the user to the SP.
4. The SP examines the assertion, validating the IdP's X509 certificate public key. The SP then gives the end user access to their services, using the Federation ID as the identifier for the end user.

SP-initiated workflow

This workflow is not commonly used between Fourth and our partners, but is still possible.

1. The end user visits the SP.
   The SP can determine whether the user should authenticate with the IdP by checking the subdomain visited, the user's IP address, or a similar method.
2. The SP generates a SAML AuthnRequest.
   An X509 certificate public key can optionally be included to authenticate the request.
3. The client both forwards the request and redirects the user to the IdP specified in the SAML AuthnRequest.
4. The IdP checks whether the user has a currently authenticated session open. If not, the IdP provides the end user with a login screen.
5. Once the user successfully authenticates, the IdP generates a SAML Assertion and sends this to the client. This contains:
   • The user's Federation ID
   • Additional data (attributes) about the user
   • Data about how and when the user authenticated
   • The X509 certificate public key of the IdP
6. The client both forwards the SAML Assertion and redirects the user to the SP.
7. The SP examines the assertion, validating the IdP's X509 certificate public key. The SP then gives the end user access to their services, using the Federation ID as the identifier for the end user.

What happens when a user logs out?

There are two options that can occur based on the behavior the IdP and SP have agreed upon:

• Independent logout: The user is logged out of the session that they currently have with either the IdP or SP only.
• Single logout: The user is logged out of all sessions with the SP and IdP that are using the same single sign-on. The IdP also updates any other third-party SP sessions that support single logout.

Your business can choose whether or not to support single logout.

What about mobile apps?

Single sign-on is possible even if your product uses a native app, rather than a web app. This is achieved by embedding a web view within your application. We can provide further advice if you wish to use SAML with your native app, just get in touch with our Partnerships Team.

Types of integrations

Fourth offers these types of integrations with SAML 2.0:

Outbound Federation

Outbound Federation is used between Fourth and its partners.

With Outbound Federation, Fourth acts as the IdP, and users log into other applications using their Fourth account.

This is the SSO option that connected apps must use, but it is also used by other web applications providing complementary services to our customers, such as learning management systems or application tracking systems. These apps benefit from Fourth's strong IdP security features, such as handling customer-specific password requirements, and Fourth's ability to authenticate users who do not have existing credentials for the web application.

FIND OUT MORE

Federated Authentication

With Federated Authentication, another system, such as Active Directory or Okta, is the primary authentication provider.

This SSO option is useful when Fourth is integrating into a larger corporate environment where user credentials are already managed by another IdP. 

Fourth continues to act as the IdP for partners.

FIND OUT MORE