Overview
Allowing someone to act on behalf of someone else is a common requirement for identity and access management systems. Examples include a parent acting on behalf of a child, a caregiver acting on behalf of an elderly person (power of attorney - PoA), or a call centre operator acting on behalf of a caller.
ForgeRock Identity Cloud can be configured to enable an authorized user to act on behalf of another user to support caregivers, PoA, support scenarios, and other use cases. To achieve this, it offers several capabilities, including:
- OAuth 2.0 token exchange
- Client Initiated Backchannel Authentication (CIBA)
- Changing an authentication session’s user ID
OAuth 2.0 token exchange
What is it?
OAuth 2.0 token exchange is an extension of the standard OAuth 2.0 protocol.
With OAuth 2.0 token exchange, client applications can request and obtain security tokens or access tokens from authorization servers, including security tokens employing impersonation and delegation.
Both impersonation and delegation can be used for performing actions on behalf of another user (known as a subject). With ​​impersonation, the person acting on behalf of the subject pretends to be the subject when performing a job or duty. With delegation, a job or duty is given to someone else who performs the job on a subject’s behalf.
How is it achieved in Identity Cloud?
Identity Cloud supports RFC 8693 OAuth 2.0 token exchange for OAuth 2.0 and OpenID Connect tokens. It can be configured to implement user delegation and secure impersonation use cases and flows.
OAuth 2.0 token exchange uses two kinds of input tokens; a subject token and an actor token. The subject token represents the identity of the party on behalf of whom the request is being made. The actor token is an optional input token that represents the identity of the acting party.
In impersonation use cases, a client obtains a subject token with the user’s authorization. It exchanges this token for a new token it can use directly to access a protected resource. For further information, see Impersonation.
In delegation use cases, a client obtains a subject token with the user’s authorization and an actor token for itself or a user it represents. The client exchanges both tokens for a new token that it can use to access a protected resource. The subject can decide to only delegate certain rights. For further information, see Delegation.
For further information on implementing OAuth 2.0 token exchange with Identity Cloud, see:
- Exchange tokens for impersonation or delegation
- Does the ForgeRock solution support secure impersonation?
- OAuth2 Token Exchange (training video)
- Token Exchange Impersonation (training video)
Business benefits
OAuth 2.0 token exchange provides organizations with granular capabilities to address the complexities of use cases such as elderly people signing over PoA and responsibility.
When users need temporary access to certain applications or resources, delegation can provide a secure and controlled way to grant that access without compromising security. It eliminates the need to create new accounts or modify permissions temporarily. Instead of giving an application unrestricted access, organizations can provide only the necessary permissions for the requested tasks.
Client Initiated Backchannel Authentication (CIBA)
What is it?
Client Initiated Backchannel Authentication (CIBA) is an extension to OpenID Connect.
With CIBA, a client application (known as a consumption device) can acquire user authentication and consent without the user needing direct interaction with the client application. Instead, the client application initiates a backchannel request to the user’s authentication device, such as an authenticator app on a smartphone. This allows the user authentication and consent to be established.
Some examples of CIBA use cases include:
- Enabling secure impersonation so that users can hand over temporary control of their account to another party for a set period of time.
- Allowing a user to use their smartphone to authorize a payment they are making at a point-of-sale terminal.
- Allowing a device to authenticate and gain consent from its registered user after receiving a request to transfer money to a third party.
How is it achieved in Identity Cloud?
The backchannel request grant is used when performing CIBA with Identity Cloud. ForgeRock’s implementation of CIBA is based on the OpenID Connect Client-Initiated Backchannel Authentication Flow specification.
NOTE: ForgeRock applies the guidelines suggested by the FAPI Working Group to implement CIBA.
For further information on preparing for CIBA and implementing the backchannel request grant in Identity Cloud, see:
Business benefits
CIBA can enhance security by enabling call centre or helpdesk staff to authenticate callers with methods such as sending a prompt via a mobile app or text rather than callers having to answer weak authentication questions.
CIBA helps prevent fraud by reducing the exposure of user credentials to the client application and by allowing authentication and consent to occur separately from the client-user interaction. Since CIBA involves a dedicated authentication device, such as a smartphone with a secure authenticator app, it adds an extra layer of security to the process.
Changing a session’s user ID
What is it?
With this method, impersonation or delegation is achieved by switching a session’s username (user ID) to the user who will act on behalf of the user during an authentication session.
How is it achieved in Identity Cloud?
This method can be achieved using ForgeRock’s Intelligent Access journeys and Scripted Decision nodes.
You can create a journey that includes a Scripted Decision node that augments the user session with the username of the impersonated user. The protected application must be altered to use the impersonated user ID field. Alternatively, if ForgeRock Identity Gateway is deployed, an IG filter can replace the credentials during the resource access request.
For further information on impersonation or delegation by switching a session’s user ID, see:
- Journeys
- Scripted Decision node
- Gateway Guide
- Does the ForgeRock solution support secure impersonation?
Business benefits
Obtaining an authentication session on behalf of another user can help with user support and troubleshooting, for example by allowing support personnel to log into user accounts and replicate the issues they are facing.
Another example is in critical situations where a user is unable to access their account, where authorized personnel can use session delegation to ensure business continuity.