HowTo: Managing repositories using an admin user

Official Content

In a multi-company environment working with n repositories, for some cases, a user who is administrator of a repository requires to be allowed to create new repositories based on that repository (despite not being the user gamadmin).

For such case, the children repositories from the base repository may have the same namespace as the parent repository. Basically, this case covers the scenario of Multiple Repositories Scenario: A company with different branches

The user is an administrator user who is granted the privilege of creating new repositories from the base repository.
This user may also change the connection from one repository to another child repository (in order to administer them), without the need to log in again.  

Summary

Scenario 

A repository is created for a company with branches. The repository's admin will create the repositories for the company branches. All branches have the same Repository namespace.

The company's repository is created using the gamadmin user and with a connection to GAM Manager Repository. However, in order to create new repositories for the branches (based on the company's repository - which we will call "master" repository) without the need for the user to be gamadmin, and without his connection to the GAM Manager, the company's repository must be created by setting the "Enable working as GAMManager Repository" property at the Repository level, as detailed below.

Additionally, in this scenario, since all repositories share the same namespace, the authentication will be centralized in the master repository. This is done by setting up "Use the current repository as the authentication master repository" as explained below.
This configuration implies that this will be the repository where the authentication types for all the children repositories will be defined. Despite this, as usual, users will connect (HowTo: Get and Set GAM Repository Connections) to the repository of the corresponding branch, in order to have the privileges of the applications defined in that repository.

Steps to achieve this scenario

Step 1. Create the master repository from which new repositories will be created.

To understand how repositories are created, read HowTo: Creating New Repositories.

In this particular scenario, the following must be borne in mind:

RepositoryConfigurationEnableWorkingAsGAMManagerRepository_png
 

As from this point, it is already possible to create repositories while connected to this repository, as if it were the GAM Manager repository.

Step 2. Make the repository the authentication master.

Upon creating the new branch repository, in order to fulfill the requirements of the scenario described above, you must check "Use the current repository as the authentication master repository". This will cause the new repository to take the namespace of the company's repository. Once created, users will always be authenticated against the company's repository, and upon logging out from one repository, the logout will include all repositories, as explained above.

The master repository must include all the authentication types required by the branch repositories, because they inherit the master repository's authentication types. The local authentication type will be created in each branch repository, though disabled. It is not possible to create new GAM Authentication Types in branch repositores.

The fact that authentication is centralized in the master repository implies that users will be registered and authenticated in this repository only.

In general, when a user is enabled to be connected to more than one branch, the user uses the token for the master repository in order to generate tokens in each child repository to which a connection is required. This happens internally, and the user of the app will not notice any specific behavior (each branch repository has its own access token). Upon logging out of one repository, the logout will cover all repositories.

Syntax of the related property:

&RepositoryCreate.AuthenticationMasterRepositoryId    = &GAMRepositoryId  //&RepositoryCreate is of the GAMRepositoryCreate type.

Step 3. Define the repository's administrator user.

In this scenario, the administrator user must exist in the master repository.

The "Authentication type name in current repository" property defines the authentication type for the administrator of the new repository (for example: local), and the username must also be entered. If the user is not found in the authentication type defined, the "User not found. (GAM7)" message will be shown.

Syntax:

&RepositoryCreate.AuthenticationMasterAuthTypeName    = &AuthenticationMasterAuthTypeName //&RepositoryCreate is type GAMRepositoryCreate. Something of the type GAMAuthenticationTypeName, GeneXusSecurityCommon is assigned.

Step 4. Allow the user that creates the new repositories the possibility of administering them as if the user was the administrator for those repositories.

The check of "Is the current user an administrator of the new repository" means that the user logged in at the time, who creates the repository, may administer it as well.
In other words, it will be possible to change the repository connection, without the need to log in again.

Syntax of the related property:

&isOK = GeneXusSecurity.GAM.RepositoryUserEnable(&RepositoryId, &GAMUser, &AdministratorRoleId, &GAMErrors)

Note

The properties are explained in detail in HowTo: Creating New Repositories. See the objects of GAM Examples: GAMRepositoryConfiguration and GAMExampleRepositoryEntry regarding the use of these properties.

Availability

As of GeneXus 16 upgrade 7