Federated Authentication
Introduction
Federated Authentication allows another authentication provider, such as Active Directory or Okta, to authenticate users accessing Fourth. With SAML or OIDC Federated Authentication:
- A separate system is the primary Identity Provider (IdP)
- Fourth acts as a SP with the IdP. However, for connected partners, Fourth continues to be the IdP.
This page explains how to integrate with Fourth to provide Federated Authentication. You may also want to read:
| Fourth Identity & Access Management for an overview of our solution. | Single Sign-On & SAML if you need more information about these topics. | Outbound Federation if you are a partner integrating with Fourth. |
Why Federate?
Federation Authentication allows users to log into Fourth using existing corporate credentials, which has a number of benefits:
- Single Sign On: Users don't need to remember another set of credentials.
- Compliance: The corporate password complexity and rotation policies implicitly cover logging into Fourth as well.
- User management: When a user is deactivated with the authentication provider, they cannot access Fourth anymore.
- Partner compliance: The same functionality and benefits are inherently applied to partners with connected apps in Fourth.
Federation ID options
The Federation ID is the identifier that the SP and IdP agree to use to identify each end user. For Federated Authentication, the end user's email address is used as the default identifier between the other authentication provider and Fourth.
However, Fourth is also able to configure support for single sign-on via:
- The Fourth canonical user ID / Fourth Account ID (FAID) - as generated by Fourth on user creation
- The employee's Payroll ID - as supplied by the customer's HRIS system
- The employee's External ID - as supplied by the customer's HRIS system
- Any other arbitrary federation identifier - explicitly supplied as a user property by the customer's IDP
Synchronizing user accounts
Fourth and the authentication provider will need to notify one another whenever a new user is created or terminated, so that our systems remain synchronized.
We will work with your team to determine the best way for Fourth to get user data from the authentication provider. For getting user data from Fourth, we offer these options:
Fourth Account SCIM API
This API leverages the existing System for Cross-domain Identity Management (SCIM) standard. It's ideal for applications that need to know a small range of employee data useful for user provisioning, such as their name, job title, location, or preferred language.
Workforce Management APIs
Connect to one of our Workforce Management APIs to send and retrieve extensive employee information about both current and terminated employees. We recommend this option if you need detailed information about the user (such as job title or division).
- UK Employee API, GET Employees endpoint.
- Labour Productivity API
Workforce Management Export
Fourth can generate a .csv file with the same employee data that is available through the Workforce Management APIs. Fourth can also accept employee data via a .csv file.
Just-in-time (JIT) Provisioning
SAML supports JIT provisioning. Less information is passed in the token, but the user is created as soon as they log in the first time. Note that Fourth does not support JIT provisioning of users in our own system.
Steps to integrate
| Step | Description |
|---|---|
| Step 1 | You provide the Identity Provider (IdP) metadata to Fourth. This is normally available as a download from systems such as Okta or Active Directory. We require the standard SAML/OIDC settings when setting up a new trust relationship. This contains:
|
| Step 2 | Once we complete our configuration Fourth generates the SP metadata file that you will need to import into the IdP. This contains our:
|
| Step 3 | Fourth tests the single sign-on connection. To do this, we will need you to provide a login to a suitable environment and user accounts. |
| Step 4 | Go live! |
How are users logged 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.
Sample SP metadata file
Note that the EntityID and ACS URL shown in this sample are not to be used - the actual values vary by region and configuration. Your Fourth Solution Consultant will be able to provide the correct information for your customer's situation.
<?xml version="1.0" encoding="UTF-8"?><md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://fourth-app.my.salesforce.com" validUntil="2029-01-24T14:18:54.233Z" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<md:SPSSODescriptor AuthnRequestsSigned="true" WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<md:KeyDescriptor use="signing">
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>acx...09O=</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://fourth-app.my.salesforce.com/services/auth/sp/saml2/logout"/>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://fourth-app.my.salesforce.com/services/auth/sp/saml2/logout"/>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://secure.fourth.com/services/auth/sp/saml2/logout"/>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://secure.fourth.com/services/auth/sp/saml2/logout"/>
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://fourth-app.my.salesforce.com?so=00D24000000H3sX" index="0"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://secure.fourth.com/login?so=00D24000000H3sX" index="1" isDefault="true"/>
</md:SPSSODescriptor>
</md:EntityDescriptor>