Import Users - GAM Deploy Tool

Official Content

Purpose

This document explains the criteria used when importing GAM Users with the GAM Deploy Tool.
All GeneXus Access Manager entities are identified with a GUID or an ID, which in turn is used when making an import to consider whether to add a new entity or update an existing one.
In particular, the user entity has a namespace that helps determine whether or not it is the same user record.
For this reason, when importing a package into the GAM, all users are checked for existence in the GAM with their GUID and namespace, so as to know whether to update each user or enter a new one.
As a consequence, this creates logic to be taken into account regarding user imports aimed at solving common use scenarios.

Rationale

The GAM database supports n repositories (read GAM Multiple Repositories Scenarios) where each GAM Repository has a Repository Namespace.
Users within the GAM are a strong entity that doesn’t depend on the repository. A user is identified with a GUID, and the default value of the user’s namespace is the Repository Namespace where the user is created.
A user can be enabled in more than one repository as long as the repository namespace matches that of the user. Read Users enabled or disabled in the GAM Repository for more information.
When a repository is created or updated using the GAM Deploy Tool, and the users in the package are to be imported, the package users will be linked to this repository. Therefore, the package users’ relationships are going to be updated with that repository only.
The users’ GUID is the only information considered about the users in the package; the namespace of the repository from where the export is made is not considered.
A user cannot be related with a repository that has a namespace different than its namespace. Therefore, if a new repository is created or an existing repository is updated when making an import, the users in the package will be incorporated into the GAM with the same namespace as that of the new repository or with the namespace of the repository being updated.
In sum, the way in which a user import behaves depends on whether or not the user GUID exists in the GAM where we are making an import. If it exists, it also depends on whether the user has the same namespace as that of the repository being created or updated.

Possible scenarios

The scenarios to be considered are as follows:

1. Import into an empty GAM that doesn’t have any other users

The package users are created with the same GUID they bring in it. In addition, the namespace given to the repository being created or updated is assigned to them.
A real-life example is when users in pre-deployment phase are moved to deployment. The namespace of the pre-deployment repository is different than the deployment one; users are incorporated into the deployment environment with the namespace of the deployment repository.

2. Import into a GAM that has existing users

2.1. When the GAM doesn’t have any users with the same GUID of a user in the package.

The package users are created with the same GUID they bring in it. In addition, the namespace given to the repository being created or updated is assigned to them. Users are enabled in this repository.
This can happen in a multi-tenant environment, where each company has its repository with a different namespace.

2.2. When there is a user in the GAM with the same GUID of a user in the package

There are two possibilities:

  • The GAM user has the same namespace as that of the repository being created or updated. In this case, it is considered that the user exists and it is updated. It is enabled in the new repository.
  • If a repository is created or updated with a namespace different than that of the GAM user, they are considered as different users (because they will be related to repositories with different namespaces); a new user is created and it is assigned another GUID. It is assigned the namespace of the repository being created and it is enabled in this repository. The keys of these users are disabled so they must be changed.
    This would be the scenario of a SAS environment, for example, where the company can create a new repository within the GAM from an initial package to start the repository.
    If this initial package contains users, they will have a GUID that exists for a repository of the GAM where the import will take place, but these users should be considered as different users in the new repository being created.