Skip to main content

User Management

This document provides an overview of how user management is handled within the tSM (Ticket & Service Management) application. The concepts described here are general and can be adapted to various environments—whether you use Single Sign-On (SSO), LDAP/AD synchronization, or a purely internal tSM user database.

Overview

tSM contains an internal database of users, which can be populated in several ways:

  • Automatic Synchronization from an external source (e.g., LDAP/Active Directory, external IAM tools).
  • SSO Integration using industry-standard protocols (e.g., OAuth2/OpenID Connect, SAML) or another corporate SSO solution.
  • Manual Creation in the tSM application for standalone deployments or for specialized “technical” (API) accounts.

Key Entities

  1. Users

    • Individual entries that represent people or system/service accounts.
    • Used for task assignments, reporting, or logging actions in the application.

  2. User Roles

    • Define a set of privileges in tSM.
    • Each role is composed of one or more atomic privileges (e.g., Um.User.View, Um.User.Edit).

  3. User Groups

    • Organizational or logical groupings of users (e.g., teams, departments).
    • Tasks are often assigned to a group; a user can belong to multiple groups.

  4. Access Rules

    • Optional filters or rules that further restrict which records (tickets, forms, etc.) a user can see or edit, beyond the base privileges.

  5. Privileges

    • The most granular level of permission; everything from the ability to view user records to the ability to delete them.
    • Privileges are typically grouped into roles.

1. Users

1.1 Creation and Synchronization

tSM supports several methods for user creation:

  • Internal Database (manual): You can create and manage users directly via the tSM interface or API. This is useful for smaller setups or for “technical” (API) accounts.

  • Synchronization with External Directories: Typically, users are synced from an LDAP/AD or other directory services on a scheduled job.

    • During synchronization, new users found in the directory are automatically created in tSM with an authentication method set to “LDAP” (or “AD”).
    • If a user no longer exists in the external directory, it can be deactivated in tSM (this behavior is configurable).

For a purely standalone mode (no external directory), you can disable synchronization completely. Users would then be created and managed only within tSM.

1.2 Authentication (Login)

tSM supports multiple authentication methods:

  1. SSO / Federated Login

    • Commonly SAML, OpenID Connect, or custom single sign-on solutions.
    • If using an external SSO, you typically configure tSM to redirect to the SSO login page.
    • A public key or certificate is required in tSM configuration to validate received tokens or assertions.

  2. LDAP/AD-based Login

    • If integrated with an Active Directory or LDAP, users can log in with their domain username and password.
    • Requires setting LDAP connection parameters in tsm-user-management.yml (or the relevant microservice configuration).

  3. Internal Passwords

    • A purely local method.
    • Passwords (hashed) are stored in the tSM database.
    • Often used for “technical” or “API” accounts or in small-scale or offline installations.

The application can be configured to display a standard login screen with either local credentials or an SSO button—or can be set to skip the local login screen entirely and redirect directly to the SSO provider.

1.3 API Authentication

For API (machine-to-machine) scenarios, a user (or service account) can authenticate by:

  • Basic Auth (username + password, base64-encoded in an Authorization header).
  • Bearer Tokens (if an SSO or IAM solution issues tokens recognized by tSM).

Example using Basic Auth:

curl -X 'GET' \
  'https://your-tsm.com/api/tsm-bpmn/tsm-config-form/api/v1/registers/all' \
  -H 'accept: application/json' \
  -H 'Authorization: Basic base64encoded(username:password)'

2. Authorization (Roles and Privileges)

2.1 Roles

  • Each User must have at least one Role to be allowed to log in.
  • Roles are a collection of Privileges that define what operations a user can perform.
  • Roles can be:
    • Synced from an external system (e.g., IAM or LDAP groups).
    • Managed manually in tSM (especially in smaller deployments or specialized cases).

2.2 Privileges

Privileges represent the smallest unit of access control. Example privilege patterns might look like:

  • Um.User.View – Allows viewing of user records.
  • Um.User.Edit – Allows editing user details.
  • Um.User.Delete – Allows deactivating or deleting user records.
  • Um.User.Roles.Add – Allows adding roles to a user.
  • Um.User.Attachments.View – Allows viewing attachments on a user record.

Privileges are grouped by functionality:

  • Um.User.Comments.* for managing comments
  • Um.User.Attachments.* for managing attachments
  • Um.User.Roles.* for role assignments

You can assign or revoke privileges via prefix (see below).

2.3 Prefixes: “Plus” (+) and “Minus” (-)

tSM supports a pattern where roles can specify privileges with a “plus” (+) sign or “minus” (-) sign:

  • “+” grants the privilege. For example, +Um.User.Edit means “allow editing user details.”
  • “–” removes (or negates) the privilege. For example, -Um.User.Comments.Edit would remove the ability to edit comments.

Using these prefixes, you can configure more nuanced role definitions. For instance, you might have one role that grants broad access (e.g., +Um.User), and another role that specifically denies one sub-privilege (e.g., -Um.User.Delete). The system then calculates the effective privileges by combining all pluses and subtracting any minuses.

Note: Configurations interpret partial prefixes like +Um.User to grant all sub-privileges in the Um.User “namespace.” Similarly, -Um.User.Comments removes any comment-related privileges within that namespace.

2.4 Example Privilege Hierarchies

Here is an illustrative subset of privileges in the User Management (Um) module:

CodeDescription
Um.UserAllows all basic operations on users.
!Um.UserAllows advanced/administrative operations on users (often a superset).
Um.User.ViewView list and detail of users (read-only).
Um.User.AddCreate new users.
Um.User.EditBasic editing of user details.
Um.User.DeleteDelete/deactivate users.
Um.User.ExportExport listing of users (Excel, CSV, etc.).
Um.User.Edit#DataTagsEdit or add a new/existing user data tag.
!Um.User.EditPasswordChange another user’s password (administrative privilege).
Um.User.Roles.ViewView the Roles tab for the user.
Um.User.Roles.AddAdd a role to the user.
Um.User.Roles.DeleteRemove a role from the user.
...... (other privileges for Comments, Attachments, Skills, Regions, etc.)

3. User Groups

  • User Groups provide a way to assign tasks, responsibilities, or organizational membership to multiple users simultaneously.
  • A user can belong to multiple groups.
  • Groups often have their own “type” (e.g., functional teams, security groups, departments).
  • Assigning a User Group to a task automatically makes that task visible to all users within the group.

Groups can also be:

  • Synced from an external directory or IAM system,
  • Managed within tSM for more dynamic or specialized grouping.

Depending on configuration, you can toggle synchronization on or off.

4. Access Rules

Access Rules introduce an additional layer of filtering or restriction on data (tickets, forms, or user records) based on certain conditions. For example, an Access Rule can specify:

  • A user can only view or edit records belonging to their department or region.
  • A user can see only “open” tickets assigned to them, but not tickets assigned to other groups.

Properties of an Access Rule include:

  • Entity Name: Defines which entity (e.g., Ticket, User, Asset) the rule applies to.
  • Access: READ or READ_WRITE.
  • Expression: A where condition (e.g., in TQL) that determines whether a record is visible/editable.
  • Validity: Time-bound or permanent.
  • Priority: If multiple rules exist, the order of evaluation can matter.

5. Implementation Steps

  1. Create or Import Users

    • If syncing from external identity sources, configure the relevant connectors.
    • Otherwise, create users in tSM, set their authentication method (password, SSO, etc.).

  2. Assign Roles

    • Each user needs at least one role to log in.
    • Roles define the privileges a user has, using “+” or “-” prefixes where appropriate.

  3. Set Up Groups (Optional)

    • Organize users into groups for simplified task assignments or departmental categorization.

  4. Configure Access Rules (Optional)

    • If your business requires finer-grained constraints on data, define and enable relevant access rules.

  5. Test

    • Use different test accounts or roles to ensure correct privileges and data visibility.

Conclusion

The User Management in tSM is flexible and can operate in a variety of setups—from a simple standalone database of users and passwords to advanced enterprise environments with multiple SSO/SSO providers, IAM integration, or organizational unit synchronization from LDAP/AD.

Key Takeaways:

  • Authentication can be local or external (SSO, LDAP/AD).
  • Authorization is controlled via Roles, which bundle specific Privileges.
  • User Groups simplify administration by grouping users with similar duties or organizational ties.
  • Access Rules provide additional data-level constraints.
  • Prefixes (“+” to grant, “–” to remove) allow fine-grained combination of privileges within or across roles.
  • Public API entities let you integrate or automate user, role, and group management from external systems.

By following these guidelines, you can customize tSM’s user management to meet a wide range of business and technical requirements.