Identity & Access Management
Providing user accounts to a large workforce who access multiple applications is as frustrating for users as it is burdensome to your operations team. That's why Fourth's ID & Access Management provides flexible integration options for user account and credential management. As well as providing single sign-on across Fourth modules, it uses industry-standard protocols to offer:
- Outbound federation: enabling users to log into other applications using a Fourth account
- Inbound federation: enabling users to log into Fourth using corporate credentials managed by another Identity Provider
- Synchronization: managing accounts with other systems through synchronizing user data
As an Identity Provider itself, Fourth ID & Access Management includes strong security features, such as:
- Robust authentication services to verify users
- Centrally-controlled access permissions for modules
- Customer-specific password complexity rules
- Enforcement of two-factor authentication
- Identity event logs, for auditing purposes
Fourth Accounts hold the details of Fourth users, like their name and email address, and provides login credentials for any Fourth modules they have permission to use.
Each person who accesses Fourth — from your management team viewing Analytics, or your casual staff checking payslips through Engage — is provided with a Fourth Account. This means that employees who aren't traditionally provided accounts by your organization's Identity Provider have accounts in Fourth, by default. Integrating with Fourth's ID & Access Management offers a way to supplement your organization's own solution to cover a much larger percentage of users.
The life cycle of a Fourth Account is managed by Fourth based on the user's employment status:
- When a new active employee is added to the Fourth HR module, Fourth creates and issues an account
- When an employee is listed as terminated, Fourth deactivates their account
This keeps the Fourth identity store always up-to-date with the current user and employees.
Inbound Federation allows another authentication provider, such as Active Directory or Okta, to authenticate users accessing Fourth. This means that users can log in using their corporate credentials into Fourth, 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
The protocol that enables this is SAML (Security Assertion Markup Language). A SAML assertion is passed from the authentication provider back to Fourth, which authenticates the user without Fourth having to have access to the user's credentials. A SAML assertion is a signed XML document which is passed between two trusted parties and contains a number of configurable settings.
In order to set up a trust relationship between two parties — in this case Fourth and the other authentication provider — these configuration settings need to be agreed upon. Fourth requires the standard SAML settings when setting up a new trust relationship and are usually available as a downloadable XML file (called the metadata xml file) from the authentication provider. Once the configuration is completed by Fourth, another metadata file will be generated which needs to be imported into the other authentication provider to complete the trust relationship.
SAML Identity Type
The users’ username (in the form of an email address) is used as the identifier between the other authentication provider and Fourth.
Configuring SAML for Inbound Federation
To configure SAML for inbound federation, you'll need to:
- Get the authentication provider (IdP) to provide:
- Federation metadata XML
- Certificate (x508)
- IdP Login URL
- Get Fourth to provide:
- The service provider metadata XML
- ACS URL
- Test the single sign on connection
- Go live!
Outbound Federation enables users that are already authenticated with Fourth to log into another external application without having to enter their credentials again and without the other application having access to their credentials. An examples of this is where employees have access to a number modules in Fourth and also to a LMS (Learning Management System). In this scenario, once they have logged in they can move seamlessly between Fourth modules and the LMS.
This is enabled using a SAML assertion which is passed from Fourth to the other application (called a Service Provider). This means that for a service provider to integrate with Fourth's Identity & Access Management, they must support receiving SAML assertions. In order for the service provider to be able to validate the assertion, Fourth requires the following information from the service provider:
- Entity ID: This must be a URL under the control of the service provider.
- ACS URL: The endpoint that the SAML token will be POSTed to.
Fourth will use this information to set up a trusted application which users can access. Once the application is set up, a metadata file will be created and shared which will contain the configuration of the assertion (as below) and also the X508 certificate information.
Default Fourth Identity Provider Information
|SAML Identity Location||Name Identifier element of the Subject statement|
|Name ID Format||Unspecified|
|SP Initiated Request Binding||HTTP POST|
By default, Fourth sends the following additional claims to the service provider in the SAML assertion.
|The email address of the user (not guaranteed to be unique).|
|firstName||The first name of the user.|
|lastName||The last name of the user.|
|longUserId||Fourth's 18-digit alphanumeric string uniquely identifying the user.|
In addition to inbound or outbound federation, Fourth's ID & Access Management can synchronize user account details with other applications and authentication service providers. When a new user is created or terminated in Fourth, the service provider needs to be notified of this in order to synchronize the users. This can happen through a number of different channels:
- API: An API which can be queried for all employees (including terminated employees). The service provider can then use this employee list to synchronize the users.
- Export: An export can be generated from Fourth with all the employees with the same data as the API. Processing can be done in the same way.
- JIT Provisioning: The authentication token protocol supports “Just in Time” provisioning, which means that a system that supports it can create the authenticated user when they log in the first time.
The choice of which one to use depends on both the capability of the service provider to consume data and how much information is required in order to create the user. For example, if detailed information about the user (such as job title or division) is required, the API route is recommended as it can provide more information. In the case of JIT Provisioning, less information is passed in the token, but the user is created as soon as they log in the first time.