Virtual hosts (session domains)
User representation demands 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 Airlock Gateway, one for the representer's login and the other for the representee's login. Best practices are to add a third virtual host for administrative work, such as user and token management.
The system diagram above shows these three virtual hosts:
- admin.bank.ch, which is accessible only from 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
To increase security, we recommend configuring two Gateway mappings to access the Representee Loginapp.
- Mappings to access the Representee Loginapp:
- One mapping for the standard end user login without any representation, via the virtual host secure.bank.ch in the diagram above.
- The mapping on virtual host secure.bank.ch must not allow the use of the SSO parameter for representation, to prevent a representation login from the external network.
- One mapping for the representation login, via represent.bank.ch. This mapping enables the internal SSO login from the Representer Loginapp to the Representee Loginapp.
- The mapping on virtual host represent.bank.ch allows the use of the SSO parameter for representation. However, 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 either 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.