Relay Communication Scenario

This scenario describes a relay connection between two grids, where there are also external systems connected.

There are two grids in this scenario. One is called Cloud and the other grid is called Corp. Corp is the grid initiating the relay connection. This makes Corp the relay child and Cloud the relay parent.

In the Cloud grid there is an application called AppClient. AppClient makes proxy calls to the application AppServer, which runs in the Corp grid.

Note that before it is possible for users to make calls over a relay channel, configuration and relay adaptation must be performed in several places:

  • The AppClient application must be adapted to support relay. It needs to support configuration of proxy ID to user mapping, so that different users can be mapped to different answering grids.

  • The AppServer application must be adapted to support relay. It must be possible to register proxy IDs under different names for different answering grids.

  • The relay connection itself must be set up in the Configuration Manager. See Relay Communication Configuration.

  • A relay user must be set up in the Corp grid. See section "Relay User Configuration" in the Infor ION Grid Security Administration Guide.

  • If the proxy method offered by AppServer requires a specific role, the relay user in the Corp grid must be given a raw role for this access. See section "Relay User Configuration" in the Infor ION Grid Security Administration Guide.

  • In order for the raw role to take effect in the Corp grid, a role mapping must be set up from the raw role to the proxy method’s required role. This is done using the standard grid role mapping functionality.

  • An external systems user must be configured for the (relay) user. External credentials must be set up for this user. See section "External Systems Management Guide" in the Infor ION Grid Security Administration Guide.

  1. A user (Bob) tries to access the AppClient application in the Cloud grid. Bob is required to log on to the Cloud grid since the AppClient application is session-annotated.
  2. The authentication is handled by the session provider in the Cloud grid. Bob now has a session for the Cloud grid and his local user ID is
  3. Bob is redirected back to the AppClient application and gets access. AppClient has a component which requires data from a system on the corporate network.
  4. AppClient calls the proxy for the correct relay channel for Bob. The application itself keeps track of which proxy to call for which user, e.g. based on a user property such as tenant information. The AppClient application must be configured with the specific proxy IDs for the registered child grids – note that this configuration is not handled centrally by the grid itself.
  5. The relay channel manager in the Cloud grid checks the local user ID and queries the ESSM in the Cloud grid if there is a session id for this relay channel cached.
  6. The relay channel manager in the Cloud grid communicates with the relay channel manager in the Corp grid, attaching the local user ID and the cached session ID if found.
  7. The relay channel manager of the Corp grid calls the ESSM for validation of the data supplied in step 6.
  8. The ESSM validates the cached session ID (if present), checking if it is still active and that the relay user account has not expired.

    If no valid cached session is found, the ESSM looks up the relay user ID in the ESSM database. If it finds a valid and active relay user, it also retrieves any raw roles defined for this relay user and any stored external credentials. The ESSM creates a new grid principal for Bob in the Corp grid. The local user ID is "billybob" since that is the name that Bob gets when logging on locally using the session provider in the Corp grid. Any assigned raw roles are mapped using the user role mapping functionality in the grid. In this case, Bob has the raw role AppServerUser which maps to the AppServer/app-user role in the Corp grid. This role allows Bob to access AppServer. Any assigned external credentials are stored encrypted in the grid principal.

  9. The session is created and the session ID is returned to the relay channel manager if authentication was successful.
  10. The relay channel manager attaches the local session ID to the proxy call going to AppServer.
  11. The call ends up at AppServer which handles the request. In this case it has to make a call to an external system. AppServer requests the ESSM to decrypt the credentials for the correct configuration. The ESSM will validate that this application is permitted to get the credentials for the requested configuration.
  12. Bob’s credentials for accessing the external system are returned to AppServer which performs a logon to the external system using the provided credentials.
  13. AppServer handles the response from the external system and responds to the grid proxy call from the relay channel.
  14. The response data is transmitted back through the relay channel manager. The relay channel manager attaches the session ID of Bob in the Corp grid (for the "billybob" name).
  15. The relay channel manager in the Cloud grid takes the provided session ID for Corp and sends it to the ESSM in Cloud together with the name of the user and the relay channel ID.
  16. The response is provided to the AppClient application.
  17. The response reaches the user.