Skip to main content
Version: 2.4

User Management Overview

This document provides an overview of how user management is handled within the tSM 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 Concepts​

Authentication vs Authorization​

  • Authentication determines who you are (login process)
  • Authorization determines what you can do (permissions and access control)

tSM supports multiple authentication methods (SSO, LDAP/AD, internal passwords) and provides flexible authorization through roles, privileges, and access rules.

Key Entities​

1. Users​

Individual entries that represent people or system/service accounts. Users are the foundation of the system and are used for:

  • Task assignments
  • Reporting and auditing
  • Logging actions in the application

→ See detailed Users documentation

2. Roles and Privileges​

  • Privileges — The smallest atomic access rights (e.g., Um.User.View, Um.User.Edit)
  • Roles — Collections of privileges that define what operations a user can perform
  • Composite Roles — Roles that include other roles for modular permission management
  • Global Priority — Determines which role dominates when conflicts occur

Each role can grant (+) or deny (-) specific privileges, allowing for fine-grained access control.

→ See detailed Roles and Privileges documentation

3. User Groups​

Organizational or logical groupings of users (e.g., teams, departments). Groups provide:

  • Simplified task assignment to multiple users
  • Organizational structure representation

A user can belong to multiple groups simultaneously.

→ See detailed User Groups documentation

4. Access Rules​

Optional filters that provide an additional layer of data-level security beyond base privileges. Access Rules can:

  • Restrict which specific records a user can see or edit
  • Apply conditions based on user attributes, record properties, or business logic
  • Support both READ and READ_WRITE access levels

→ See detailed Access Rules documentation

Architecture Overview​

Implementation Workflow​

1. Set Up Authentication​

Configure how users will log in:

  • Enable SSO integration (SAML, OAuth2/OIDC)
  • Configure LDAP/AD synchronization
  • Set up internal password authentication

→ See Configuration documentation

2. Create or Import Users​

  • Sync from external identity sources (LDAP/AD, IAM)
  • Create users manually via UI or API
  • Set authentication method for each user

→ See Users documentation

3. Define Roles and Privileges​

  • Create base roles with required privileges
  • Use composite roles for modular permission sets
  • Set global priorities for conflict resolution
  • Apply + (grant) and - (deny) prefixes

→ See Roles and Privileges documentation

4. Assign Users to Roles​

  • Each user must have at least one role to log in
  • Users can have multiple roles
  • Higher priority roles override lower priority ones

5. Organize into Groups (Optional)​

  • Create user groups for teams or departments
  • Assign users to relevant groups
  • Use groups for task assignment

6. Configure Access Rules (Optional)​

  • Define data-level restrictions
  • Set up entity-specific access filters
  • Configure read vs read-write access

→ See Access Rules documentation

7. Test and Validate​

  • Test with different user accounts
  • Verify privilege resolution
  • Validate access to records and features

Deployment Scenarios​

Scenario 1: Standalone (Small Organization)​

  • Authentication: Internal passwords stored in tSM database
  • User Management: Manual creation via UI
  • Roles: Predefined set of basic roles
  • Groups: Simple departmental grouping

Scenario 2: Enterprise with LDAP/AD​

  • Authentication: LDAP/AD for login
  • User Management: Automated synchronization from directory
  • Roles: Mapped from LDAP groups or managed separately
  • Groups: Synced from organizational units

Scenario 3: Enterprise with SSO​

  • Authentication: SAML or OAuth2/OIDC SSO
  • User Management: Just-in-time provisioning or pre-sync
  • Roles: Managed in external IAM, synced to tSM
  • Groups: Dynamically assigned based on SSO claims

Key Takeaways​

  • Authentication can be local or external (SSO, LDAP/AD)
  • Authorization is controlled via Roles, which bundle specific Privileges
  • Composite Roles with Global Priority enable sophisticated permission hierarchies
  • User Groups simplify administration by grouping users with similar duties
  • Access Rules provide additional data-level constraints
  • Prefixes (+ to grant, − to deny) allow fine-grained privilege control
  • Public API entities enable integration with external systems

See Also​