New ActAs authorization controls


Identify*STS already supported the ActAs feature, but without authorization in earlier versions. From 4.3, it is now possible to control authorization for the ActAs functionality at the connection and the user levels

ActAs Authorization at User Level

This authorization level is to map a specific certificate (represented by a local user) to one or more services for which ActAs is allowed.

The following is a sample scenario showing how this feature is used:

  • There is a requester (named as A, let's say A is a local user having a list of actas-authorized-service-uris) who executes issue requests. The RST has the following properties:
    • ActAs element, which is a SAML 2 token or an x509 certificate (named as B).
    • AppliesTo, which is a service that is secured by Identify*STS that A wants access to and acts as B.
  • After Identify*STS processes this request, it will respond with a security token having claims extracted from A and B (depends on the settings)
  • In order to grant authority to A to execute the ActAs issue token request, on user A’s details form, you must make sure that the AppliesTo on RST be one of the act-as-authorized-service-uris list (as on the below image):


Please notice that the comparison between the AppliesTo and each actas-authorized-service-uri is equal.

ActAs Authorization at Connection Level

With this authorization level, Safewhere*Identify allows a per-request authorization pipeline for ActAs on the WS-Trust connection. It is possible to select a set of authorized claims for each connection. A user may negotiate for the ActAs security token if he or she has at least one of the authorized claims.

On the WS-Trust connection, we have a new control:

An ActAs user needs to have at least one claim matching with the ones specified on the above setting in order to pass authorization checking.