User, Company and Access Management (UserCompanyManagement)
User profiles, companies, branches, memberships and roles. Each tenant has multiple companies, and each company's access is kept separate from every other company's.
- Domain
- Platform infrastructure / RBAC and multi-tenancy
- Target customers
- Financial groups with several subsidiary companies or several independent tenants; IT managers who separate employee access between companies
- Main capabilities
- Tenant/Company/Branch management, two-level RBAC (Controls+UIPermissions), ResolveUserContext, automatic per-service permission catalog, TenantDatabaseMap, Redis permission cache
UserCompanyManagement owns the platform's business identity: user profiles, companies, branches, a user's membership in a company, and the entire role and permission system (RBAC). The service is designed as multi-tenant. Each tenant can have several companies, and each company independently holds its own users, branches and permissions.
The key architectural point is an API called ResolveUserContext. When a user signs in, Identity calls this service to build the token claims (roles, permissions, companies). In the same way, TenantDatabaseMap determines which database each company uses in every other service, which is the foundation of the platform's multi-tenant architecture.
The permission system is built on a Permission-per-UserCompany model: each permission belongs to the relationship of a user within a specific company, and not to the user alone. A single user can therefore be a manager in Company A and an ordinary employee in Company B. Two kinds of permission are kept apart: Controls for API operations (each endpoint is one permission) and UIPermissions for controlling which menus and pages appear in the panel. An important architectural point is that ownership of each service's permissions is defined inside that service itself, and not in UserCompanyManagement. At startup, every microservice announces its own permission list to this service through sync-service, and UserCompanyManagement keeps that list as a central catalog and caches it.
For an enterprise buyer, this means a system that holds several subsidiary companies or several customers (tenants) at the same time, with precise and separable access boundaries. Adding a new service or module does not require defining permissions by hand in a central file.
Key capabilities
Multi-tenant Tenant/Company/Branch management
Each Tenant has several companies and each company has several branches. A user can be a member of several companies, with a different role in each.
RBAC with Controls and UIPermissions layers
Controls govern each API operation, and UIPermissions govern whether a menu or page is shown. Assignment works both at the role level and directly at the user-company level.
ResolveUserContext for Identity
At sign-in, the user's roles, permissions and list of companies are read from this service to build the token.
Self-updating permission catalog (Permission Sync)
Every new service or module announces its own permissions at startup (sync-service). Creation, update and deletion happen automatically, and a new permission is also granted automatically to all SuperAdmin users.
Public registration and user management
A public mobile registration route that needs no JWT, together with OTP verification.
TenantDatabaseMap
Maps each company to its dedicated database in each service, with a 5-minute cache. It is the basis of data isolation in the multi-tenant architecture.
Permission cache in Redis
Each user's permissions in each company are cached under the key {service}:permissions:{userId}:{companyId} and are invalidated with every role or permission change.
Bulk permission assignment
Grants a role's permissions to several user-company pairs at once, additively (without removing earlier permissions).
Business value
Moving permission ownership to each service itself, instead of defining it by hand in a central file, means that adding a module or service to the platform brings its own required menus and permissions with it, with no manual editing of UserCompanyManagement. This substantially reduces the risk of forgotten or inconsistent permissions on a platform with dozens of services. A “user in a company” access model, rather than an “absolute user” model, is essential for organizations with several subsidiaries or independent customers, because one employee can have administrative access in one company and view-only access in another without needing a separate user account.
Use cases
- A financial group with several subsidiary companies, where some employees work across several of them in different roles.
- Fast setup of a new tenant with its company, branch and initial admin user, without touching code.
- Adding a new microservice to the platform so that, on its first day, its API permissions and UI pages are already in the admin panel and the permission catalog.
- Closing or restricting a user's access to one specific company without affecting their membership in other companies.
See this module on demo data
In a demo session we walk through your organization's scenarios on Dara's demo environment and answer your technical and finance teams' questions.