User representation

User Representation allows a logged-in user to represent another user. The term to represent means that a logged-in user can gain access to another user's application as his/her representative. The representee does not have to be logged in explicitly, and the representer may act on his/her behalf.

It is critical that this feature is configured correctly, as otherwise, it could cause serious security flaws.

In particular, it is highly recommended to restrict usage of the feature to a trusted internal network as shown on User representation system design.

A typical example scenario is a bank that runs an e-banking application, whose accessibility is secured by an Airlock Gateway (WAF) and Airlock IAM.

• When an e-banking end-user faces a problem while using the e-banking application, the user may call a customer service consultant of the bank.
• In order to reproduce the customer's problem and to give useful support, the consultant needs to see what the end-user sees. In other words, the consultant needs to access the e-banking application as a representative of the end-user (the customer).

As a representative of the (already) logged-in end-user, the service consultant does not have to use any of the customer's login data. The customer's credentials are - and must always - remain secret.

• Configuration in the Loginapp REST API:
• Representer side: User representation: representer configuration in the Loginapp REST API
• Representee side: User representation – representee configuration in the Loginapp REST API
• Configuration in the Loginapp REST UI:
• Representer side: User representation: representer configuration in the Loginapp REST UI
• Representee side: User representation: representee configuration in the Loginapp REST UI
• Configuration in the JSP-Loginapp: User representation configuration in the JSP-Loginapp