Introduction

Since Identify*STS already supported 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

Act As 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 act-as is allowed.

Below 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 request. The RST is having following properties:
  • ActAs element which is a saml2 token or a x509 certificate (named as B).
  • AppliesTo: is a service which is secured by Identify*STS that A wants to access to and acts as B.
• After Identify*STS processes this request, it will response a security token having claims extracted from A and B (depends on our settings)
• In order to grant authority to A to execute the act-as 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 be noticed that the comparison between the AppliesTo and each actas-authorized-service-uri is equal

Act As authorization at connection level

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

On the ws-trust connection, we have a new control:
ActAs User needs to have at least 1 claim matching with the ones specified on the above setting in order to pass authorization checking.