Federated Authentication

Introduction

Federated Authentication allows another authentication provider, such as Active Directory or Okta, to authenticate users accessing Fourth. With SAML 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 identifier between the other authentication provider and Fourth.

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 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).

Workforce Management Export
Fourth can genearte 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 settings when setting up a new trust relationship. This contains:
  • X509 certificate information
  • IdP Login URL
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:
  • Entity ID
  • Assertion Consumer Service (ACS) URL
Step 3  Fourth tests the single sign-on connection. To do this, we will need you to provide a login to a sandbox environment and dummy 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

This sample shows:

  • Our EntityID: https://fourth-app.my.salesforce.com
  • Our default ACS URL is: https://secure.fourth.com/login?so=00D24000000H3sX
<?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>