Pass-through authentication
Pass-through authentication lets you validate passwords with a remote service.
Overview
Secure systems typically store passwords using one-way hash algorithms to make the passwords hard to crack. But, unless all systems support the same one-way hash algorithms, using this security measure alone can impede password synchronization.
A better security practice is to synchronize hashed passwords only between services that support the same password storage schemes. This ensures that the target service will always get passwords that it can read or compare. Only synchronize hashed passwords directly between services that support the same password storage schemes. Otherwise, the target service will get passwords that it cannot read or compare!
For example, Active Directory stores passwords using a hash algorithm that DS doesn’t support. So when you import identities based on Active Directory accounts, IDM can’t synchronize the users' passwords. As a result, these users have no local credentials to authenticate to ForgeRock Identity Platform.
The Passthrough Authentication node uses a connector to validate credentials against the remote Active Directory service. The remote system verifies the user’s password even if the platform doesn’t support the hash algorithm.
Prepare for pass-through authentication
Before using pass-through authentication:
-
Set up a connector to the remote authentication service.
-
If the platform saves a copy of the password on successful authentication, align password policies so the remote password is certain to pass the platform password validation.
-
If you synchronize the platform profiles from the remote accounts, do not synchronize the passwords from the remote service to the platform.
The platform uses the local account to find the appropriate identifier, and the connector to authenticate remotely.
Migrate passwords
When you cannot synchronize hashed passwords, you can use the pass-through authentication node to capture them. The following example journey demonstrates password capture and storage.
The platform performs authentication through a connector. It also stores the captured password securely using a strong, one-way hash algorithm. The platform can then act as the service of record for authentication of that account. After the user has authenticated successfully through this journey, the user can authenticate locally in the platform. The user no longer needs to authenticate using the remote service:
Here’s what happens in this example journey:
-
The Platform Username and Platform Password in the Page Node prompt the user for credentials.
-
The Data Store Decision node attempts local authentication.
-
If authentication succeeds, the Data Store Decision node processes the authentication like the default Login journey.
-
If authentication fails, the Passthrough Authentication node attempts remote authentication.
When configuring the Passthrough Authentication node, you must identify the connector to the remote authentication service in the node’s System Endpoint field.
-
-
The Identify Existing User and Required Attributes Present nodes ensure that the platform has the data needed to update the account.
-
The Patch Object updates the account with the password used for successful remote authentication.
When configuring this node, be sure to select
Patch As Object. -
The rest of the journey processes the authentication like the default Login journey.
|
This journey can fail when the remote password does not respect the password policy. This results in a 
To avoid this problem, align password policies so that the remote password is sure to pass password validation. |
Remote authentication
You can use the Passthrough Authentication node for remote authentication. This is useful when you can neither synchronize hashed passwords, nor use the platform as the service of record for authentication.
The example journey below does not capture the password on successful authentication. But, you could adapt the journey to capture the password. Then you could the cache authentication credentials in the platform temporarily. The platform then serves as a backup authentication service when the remote service is not available. If you adapt the journey in this way, be sure to configure the journey to authenticate periodically with the remote service, and to refresh the cached password.
The following journey demonstrates remote authentication when local authentication fails:
-
The Platform Username and Platform Password in the Page Node prompt the user for credentials.
-
The Data Store Decision node attempts local authentication.
-
If authentication succeeds, the Data Store Decision node processes the authentication like the default Login journey.
-
If authentication fails, the Passthrough Authentication node attempts remote authentication.
-
-
The rest of the journey processes the authentication like the default Login journey.