Pass-through authentication lets you validate passwords with a remote service.
Secure systems typically store passwords using one-way hash algorithms to make the passwords hard to crack. Unless all systems support the same one-way hash algorithms, however, 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, and 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 Identity Cloud.
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 Identity Cloud doesn’t support the hash algorithm.
Before using pass-through authentication:
Set up a connector to the remote authentication service.
If Identity Cloud saves a copy of the password on successful authentication, align password policies so the remote password is certain to pass password validation.
If you synchronize Identity Cloud profiles from the remote accounts, do not synchronize the passwords from the remote service to Identity Cloud.
Identity Cloud uses the local account to find the appropriate identifier, and the connector to authenticate remotely.
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.
Identity Cloud performs authentication through a connector. It also stores the captured password securely using a strong, one-way hash algorithm. Identity Cloud 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 Identity Cloud. The user no longer needs to authenticate using the remote service:
Here’s what happens in this example journey:
The Data Store Decision node attempts local 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 Patch Object node 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 sample 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.
You can use the Passthrough Authentication node for remote authentication. This is useful when you cannot synchronize hashed passwords or use Identity Cloud 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 Identity Cloud temporarily. Identity Cloud 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: