The standard RFC 8693 defines delegation and impersonation as follows:
| A principal P impersonates principal B, which means P is given all of B's rights within a defined context. P is indistinguishable from B in this context. |
| A principal P is a delegate of principal B, which means P still has its own identity separate from B, and it is explicitly understood that while B may have delegated some of its rights to P, any actions taken are being taken by P, representing B. |
Within the context of the Token Exchange service, IAM supports impersonation and delegation as follows:
- In the request, the mandatory
subject_token
must be supplied. - The Token Exchange server can either validate the entire
subject_token
or only extract the claims from the token without signature validation. - In the request, an optional parameter
actor_token
may be supplied. - The Token Exchange server can either validate the entire
actor_token
or only extract the claims from the token without signature validation. The actor information can then be added to the resulting token in the act claim. - If an act claim is added to the exchanged token, this is considered a delegation. If the act claim is missing from the exchanged token, this is considered an impersonation.
An example use case would be a help desk employee who needs to represent a customer during a phone call. The help desk employee needs to exchange the current access token with a token that allows him to represent the customer as a delegation.
- Request parameters
subject_token
: JSON structure that contains the customer's information. A claim extractor plugin is recommended to process this token.actor_token
: Access token of the help desk employee. A validator plugin is recommended to process this token.
In the REST response, a new access token is issued to the client of the help desk employee with the following contents:
- Exchanged token content
sub
= customeract
= help desk employee
Recommendations:
For security reasons, it is recommended that at least one token is validated. It depends on the use case scenario which token should be validated.
In a delegation use case, both subject and actor information should be logged.