User representation system design

UserRepresentation_SystemOverview

Virtual hosts (session domains)

User representation requires that the representee's login is created in an additional session while the representer's session stays alive. This requires configuring at least two virtual hosts in the , one for the representer's login and the other for the representee's login.

In the system design diagram, there are even three different virtual hosts configured (as shown in the diagram on User representation system design):

  • admin.bank.ch – which can only be accessed within the organization's internal network
  • represent.bank.ch – for the representee system accessed from the internal network
  • secure.bank.ch – for the representee system accessed from the external network
  1. To increase security, it is recommended to have two gateway mappings to access the Representee Loginapp:
  2. Standard end-user login without any representation via virtual host secure.bank.ch in the example above.
    • The mapping on virtual host secure.bank.ch must not allow the use of the SSO Parameter for representation. Therefore, it will not be possible to try a representation login from the external network.
  3. Representation login via represent.bank.ch (internal SSO login from Representer Loginapp to Representee Loginapp).
    • The mapping on virtual host represent.bank.ch allows the use of the SSO Parameter for representation, but it should only be accessible from the internal network.

If - in addition to user representation - end-users from the internet (over secure.bank.ch) do need SSO enabled for a different SSO system, it should be separated from the representation SSO by using a different SSO parameter name.

Although it is mandatory to configure at least two virtual hosts in Airlock Gateway, the user representation feature can be used with only one Airlock IAM instance or with multiple instances (e.g., a different instance that manages authentication of external users). If used with only one instance, both the representer's and the representee's session are created in this instance, and representee authentication and identity propagation work exactly the same way as with multi-instance setups.