User representation use cases

Following our bank example for user representation, a customer service consultant may have to request a list of representable users from the system to choose the user he needs to represent.

Providing such a list is the responsibility of the representer application and not the IAM Adminapp. The list of representable users is also a good point to start user representation for the selected user.

The representer application may use the Adminapp REST API to access user information.

1. The representer application displays a list of representable end-users. The user of the representer application (here, our customer service consultant) selects one of these end-users and requests to start representation that user.
2. The system checks whether the consultant is authorized to represent the selected end-user.
• If not, the request is rejected, and a page indicating that the access was denied is shown to the consultant.
3. The consultant cannot represent more than one end-user at a time, the system checks for other active representation sessions of the consultant.
• If this is the case, starting the representation fails and the consultant is informed that the active representation session has to be stopped before starting a new one.
• A new representation always starts within a new session. This allows the consultant to stay logged in at the representer application while switching to a new end-user representation session.
4. Although the identity (that gets propagated into the representer application) is that of the end-user, it includes the information that this end-user is currently being represented by another user (our consultant).
• This allows the representer application to perform special authorization checks, create special log statements, or even highlight the representation state graphically on the end-user's interface.

Depending on the Loginapp's configuration, an end-user may have one or more sessions at a time. Depending on this setting, the end-user will automatically be logged out if a representer starts a representational session.

If multiple parallel sessions are allowed (the default) the target applications must also support multiple sessions. If it does not, it will reject the second session created by the representer. If that happens in a customer service scenario, the customer service consultant would have to ask the customer to log out before starting to represent the customer and stay logged out as long as the representation takes.

The representer application offers a command that the representer can use to stop the currently active representation.

If the representer logs out while an active representation exists, the corresponding representee is logged out as well.