Users (authentication and authorization via Database)

This page describes how Anjana Data Platform manages user authentication and authorization through the Users table in the Configuration Panel, with particular focus on the internal Database provider.

• Authentication (who are you?): verifies the user's identity when they log in.

• Authorization (what can you do?): determines the user's permissions based on the roles assigned to them. Authorization management (assigning roles to users in organizational units) is described on the page https://wiki.anjanadata.com/es/configuracion/26.1/autorizacion .

Structure of the Users table

The Users table stores the information of each user who can authenticate and be authorized on the platform.

Each user is defined by the following fields:

• id: unique identifier of the user in the table.

• userName: login identifier of the user in the application or in the integrated identity provider. It is a unique-value field in the table (see User identification and authorization). The userName is also the identifier with which Anjana Data Platform records the audit trail: when the platform indicates, for example, that the user who modified a business term is lucia.gomez, that value is the userName.

• firstName: user's first name.

• lastName: user's last name.

• email: user's email address. It can also be used as an access identifier (see User identification and authorization).

• phone: user's phone number.

• title: user's job title (informational field, not mandatory).

• Password: hash of the user's password in BCrypt format. The hash is unique per user, even for identical passwords, and can be generated with any standard BCrypt tool (see Behavior of the Password field).

• isServiceUser: boolean indicating whether it is a service user (true) or a named user (false).

User identification and authorization

A user's access to the platform is resolved in two phases:

• Identification (authentication): the identifier returned by the authentication mechanism is compared indistinctly against the userName and email values in the Users table. The comparison is case-insensitive: for example, JGarcia and jgarcia are considered the same value. Therefore, a user can be identified either by their userName or by their email.

• Authorization: once identified, the user obtains the permissions of the roles assigned to them. These roles are resolved based on the user's record in the Users table (by their Id), not by their userName or email.

Behavior of the Password field

The Password field stores the BCrypt hash of the password and behaves as follows in the Configuration Panel:

• On creation and modification, the value entered by the user in the Password field (the hash) is shown in plain text, unmasked.

• On query, the hash value is not shown: it appears masked for security.

• Modification does not allow clearing the password content, only modifying it.

• It is not populated during user synchronization.

User creation

Users can be added to the Users table through three mechanisms:

Manual creation from the Configuration Panel

Recommended method for creating users individually (path Schemas → Users → New):

1. Click New.

2. Fill in the fields described in Structure of the Users table in the creation wizard.

3. Click Save to save the user or Cancel to discard it.

Creation via API

Allows automating user provisioning from external processes. See the Zeus users API documentation for more detail.

User synchronization

Retrieves and updates user information from the corporate directory. It is run from Home > Actions > Synchronize users in the Configuration Panel and is detailed on the page https://wiki.anjanadata.com/es/integraciones/26.1/aprovisionamiento-de-usuarios .

Modifying users

Modifying a user's attributes should be done with caution.

1. Go to Schemas → Users in the Configuration Panel; the list of existing users will be displayed.

2. Locate the user you want to modify; you can filter by userName, email, or other fields in the table.

3. Click the pencil icon to open the edit panel.

4. Modify the necessary fields: firstName, lastName, email, phone, title, and Password (only if you want to change the password). Keep in mind the behavior of the Password field described in previous sections.

5. Save the changes with Save.

Important considerations

• userName: this is a unique-value field (uniqueness constraint, even case-insensitive) and is used as the login identifier. It is not recommended to modify it unless exceptionally necessary, since it may be referenced in permissions/roles or in user-type attributes of templates. If modified: perform a bulk edit to remove the references in user-type attributes; comply with all field constraints (uniqueness, length, valid characters); the user will need to log in with the new value. Remember that identification also accepts the email (see User identification and authorization).

• Password change: modify the Password field with a valid BCrypt hash; the user will use the plain-text password corresponding to that hash at login. On modification, the hash value appears masked. It is not possible to delete a password once created, only to modify it.

• isServiceUser: informational field. It should not be modified manually unless the platform team indicates so.

Database query and exploitation — Developer view

In addition to being managed from the Configuration Panel, the information of internal users (authentication via Database) is stored in the zeus.users table and can be queried in read-only mode for analytical purposes. For example, it allows the client to build their own data mart, dashboards, or reports on the users of their platform (registrations, service users versus named users, users by domain and role, etc.).

The zeus.users table

The information of internal users is stored in the zeus.users table. Its columns, available for querying, are:

Relevant constraints and indexes

• Primary key: users_pkey (id_user)

• Email uniqueness: UNIQUE (email)

• Username uniqueness: UNIQUE (user_name)

• Case-insensitive username uniqueness:
  CREATE UNIQUE INDEX unique_lower_username ON zeus.users (lower(user_name::text));
  This prevents duplicates due to case differences (for example, jgarcia and JGarcia).

Related tables for enriching queries

For a more complete view, the users table can be joined with other tables in the model:

• zeus.user_ou_role: role assignments to users by organizational unit; allows knowing the authorization of each user (linking id_user with user_id).

• Through user_ou_role, the tables zeus."role" (role) and zeus.organizational_unit (data domain) complete the view of who can do what and where.

Query examples

List of users without the credential (password_hash):

SELECT id_user,
       user_name,
       first_name,
       last_name,
       email,
       title,
       is_service_user
FROM zeus.users
ORDER BY user_name;

Count of service users versus named users (useful as a metric for a data mart):

SELECT is_service_user,
       COUNT(*) AS total
FROM zeus.users
GROUP BY is_service_user;

Users with their roles and data domains (effective authorization):

SELECT u.user_name,
       ou.alias    AS unidad_organizativa,
       r.role_name AS rol
FROM zeus.users u
JOIN zeus.user_ou_role uor        ON u.id_user = uor.user_id
JOIN zeus.organizational_unit ou  ON uor.ou_id = ou.id_organizational_unit
JOIN zeus."role" r               ON uor.rol_id = r.id_role
ORDER BY u.user_name;