ActAs functionality at the connection and the user levels


From the user detail page, it must be possible to select which services the user can do ActAs for.


How the ActAs Function Works at User Level

There is a requester (named as A; let's say A is a local user and has a list of actas-authorized-service-URIs) who executes an issue request having the following:

  •   ActAs element as a SAML 2 token or a x509 certificate (named as B)
  •   AppliesTo: A service that is secured by this issued token

When processing this request, Identify will respond with a security token having claims extracted from A and B (this depends on the settings).

To do the ActAs authorization successfully, the ActAs user must meet the following requirements:

  • He’s an Identify local user
  • The AppliesTo must be one of his service URIs listed on his user form.

In addition, the comparison between the AppliesTo and one of his service URIs listed is equal.


How the ActAs Function Works at Connection

On the WSFED Protocol Connection, we have the new control:


ActAs User needs to have at least 1 claim type matching with the ones on this setting to do the ActAs authorization successfully.