How to integrate with additional environments
An integration of a module with additional separate environments can be supported by the module itself explicitly or enabled to some extent by appropriate manual configuration by operators. For this section, the combination of a module, a Portal and a Multitenant Access Control is considered an environment.
This diagram depicts two environments A and B. It shows Multitenant Access Control, Portal and the Apps A and B. It also contains the respective module in Multitenant Access Control and the registrations in Portal that represent the applications.
Communication of App B of environment B with App A of environment A
App B has to request tokens from environment A’s Multitenant Access Control in order to communicate with App A which is protected using environment A’s Multitenant Access Control.
Prerequisites:
-
Representation of environment B’s App B as module in Multitenant Access Control of the environment A.
-
Assignment of sufficient permissions to the module representation to use App A.
-
The module App B must be able to manage client credentials for multiple environments (A and B).
Steps:
-
Obtain token in the environment A using the module’s credentials of its module representation in environment A.
-
Make call to App A of the environment A.
Adding views of App B of environment B to Portal of environment A
There is an option to add arbitrary views using Portal’s user interface. But this option does neither allow the control of visibility, nor sorting into the existing menu structure. For these features an actual module registration is required, which is described in this section.
Prerequisites:
-
Representation of App B as module in the other environment A.
-
Recommended: usage of a common identity provider for single sign-on sessions. If not, log in flows may interrupt or even block the usage of the integrated views in the environment A if users are not logged into the environment B simultaneously.
Steps:
-
Register resources at App B’s module in environment A in order to control access / visibility of the views. Those resource can be registered by operators via API using the module’s credentials or managed by the module itself using the API of environment A’s Multitenant Access Control (if supported by the module).
-
Register module with views in the environment A’s Portal. The registration can be executed by operators via API or managed by the module itself using the API of environment A’s Portal (if supported by the module).
-
The views have to be related to one of the module’s resources available in environment A to control visibility. Permissions inside the view are still managed by resources in environment B to which the view belongs.
-
The navigation paths must be unique, so collisions with navigation paths registered in the environment’s Portal have to be avoided.
-
The module’s view must not be blocked from being integrated in environment A. Security controls like the content security policies'
frame-ancestorsdirective have to be configured accordingly.
-
-
Grant access to users or modules in environment A’s Multitenant Access Control.