The model design of GeneXus Access Manager allows connecting to multiple Repositories to solve many scenarios where only one Repository wouldn't be enough.
This document describes the case of a multiple repository scenario (a company with different branches).
The same application is used by different branches of a company; it may happen that the application is deployed in a different web application for each branch (another possible scenario is that the same executables are used for all branches).
In both cases, the users of the application are the same for all branches of the company, but users may have different privileges depending on the application branch they are connected to.
This is a scenario where multiple Repositories can be used as a solution, taking into account that the company has different branches, and users have different Security Policies, Roles and Permissions depending on the branch where the application runs.
There's no need to define one GAM database for each branch because users would need to be redundant in each GAM database in that case.
By defining a Repository for each branch, users are the same (and defined only once) in the GAM database. Due to the GAM Repository model design, users can be enabled in many Repositories if they have the same Namespace as the Repository Namespace where they are enabled. See Users enabled or disabled in the GAM Repository for details.
All the Repositories will have the same set of WEB Applications defined (or at least share a common set of GAM Applications group permissions).
Besides, the following is fulfilled:
- If the application is deployed in the same web app for all branches, the connection.gam file under the virtual directory (or under the web-inf directory of the webapp in Java) has a connection key associated with N entries in the SysConnectionConfig table, each pointing to a different GAM Repository Connection. Otherwise, each web application of each branch has its connection.gam file with the corresponding GAM Repository Connection.
- The application.gam file under the virtual directory (or under the web-inf directory of the webapp in Java) references the Application Id corresponding to the application's KB.
What to do at deployment time:
1. Create a GAM Repository for each branch; the Repository Namespace should be the same in all of them, so that users are shared in all the Repositories.
Take into account that in order to create a Repository "B" with the same namespace as Repository "A," you need to have a GAM Repository Connection entry in the SysConnectionConfig table pointing to the Repository "A." This is a security requirement.
2. Use the Deploy Tool to export the data of one Repository application and import it into another one (in particular, GAM Applications and Roles).
3. Create the connection.gam file for each application, using GAMDeployTool; see GAMDeployTool:Creating connection.gam file.
If a web application is deployed for each branch, each web application will have its own connection.gam file including the connection key associated with the GAM Repository Connection to the corresponding Repository. In this case, there's no need to do any special programming in order to connect to the GAM Repository.
If the executables are shared by all the branches, the connection.gam file includes the connection key associated with all the GAM Repository Connections. In this case, you need to set programmatically the corresponding GAM Repository Connection. See HowTo: Get and Set GAM Repository Connections.
HowTo: Manage repositories using an admin user
Changes in connection gam: SAC #49792