Multi-tenancy and Delegated Administration
Nevis ID separates user populations with tenants and models organizations as hierarchical unit trees with no fixed depth limit, so delegation follows your real structure rather than a preset number of levels. Delegated administrators hold predefined roles, from Helpdesk to tenant root, and every right is bounded by a dataroom, Nevis's term for what the industry calls tenant isolation, data segregation, and scoped admin visibility: authorization for a unit always includes its subunits and never the parent unit, so a B2B partner administrator manages exactly their own organization's subtree and nothing beyond it, on the SCIM 2.0 REST API as on every other interface. Authorizations attach to profiles rather than directly to users: one person authenticates with a single set of credentials and acts through multiple profiles, for example a scoped administrator profile in one unit and an end-user profile in another, so even the most far-reaching delegated rights remain traceable to one accountable individual. Each tenant carries its own policies, templates, and default unit, every customer additionally runs on a dedicated, isolated instance, and tenants, units, profiles, roles, and authorizations are fully administrable over the REST APIs, with an administrator's effective permissions queryable at any time.
Also known as
delegated administration, tenant isolation, data segregation, scoped admin visibility, data rooms.
At a glance
| Capability | Details |
|---|---|
| Tenants | Tenants (called clients in the Nevis data model and APIs) separate user populations inside an instance, each with its own policies, templates, and default unit; user identifiers are scoped per tenant |
| Tenant isolation | Two layers: a dedicated, isolated instance per customer, and tenants segregating populations inside the instance; see also Deployment, Architecture, and Data Residency |
| Organizational hierarchy | Units form hierarchical trees with no fixed depth limit; moving a unit moves its entire subtree and creating top-level units requires a separate permission |
| Delegated administration | Predefined administrator roles from tenant root (ClientRoot) and user administration (UserAdmin) to Helpdesk and SelfAdmin; which roles an administrator may access and assign is itself configuration |
| Scoped admin visibility | A dataroom bounds an administrator's reach across tenants, units, and applications, on every interface including the SCIM 2.0 REST API: a partner organization's administrator reaches only the users of their own organization; authorization for a unit includes all its subunits and never the parent unit |
| Multiple profiles per user | A user can hold several profiles, each belonging to one unit and carrying its own authorizations, under a single set of credentials; effective permissions derive from the login profile, and every action stays traceable to the individual |
| Permission model | Roles bundle elementary permissions (AccessControl.*); every management endpoint documents the permission it requires; callers can query their own effective permissions |
| Enterprise roles | Tenant-specific bundles of application roles for organization-wide entitlements, assigned per profile |
| Self-service administration | End users manage profile, devices, sessions, and login methods in the self-service app; administrators manage any user's sessions and devices with dedicated admin permissions |
| B2B partner administration | Delegation scopes a partner administrator to their organization's unit subtree; organization lifecycle and onboarding are covered under B2B and Organization Management |
| Provisioning and onboarding | SCIM 2.0, just-in-time creation, bulk import, and invitation onboarding; see Integration, APIs, and Provisioning and Registration, Onboarding, and Identity Verification |
| Audit of administrative changes | Every administrative change is recorded with actor and timestamp in a history-enabled data model, with append-only audit logs; see Reporting, Analytics, and Audit |
Concepts
- Client and tenant management APIs: what tenants, units, roles, and authorizations are and how they relate
- User management APIs: users, their profiles and credentials, and the principal endpoints for the caller's own identity and permissions
- System overview: the dedicated instance that the logical tenancy lives in
How-to Guides
- Identities: managing end users in the management console
- API usage: creating technical users and restricting their role to a single tenant
- Self-service profile management: the end-user self-administration app
- Console overview
References
- Tenancy and delegation APIs: Create a client, Move a unit, Profiles, Create an authorization, Get caller permissions
- Delegated administration patterns: nevisIDM Authorizations, nevisIDM Administration GUI, nevisIDM Client, nevisIDM Manage Roles, and profile selection at login in nevisIDM User Lookup
- Data model: the tenant entity as the data partitioning boundary, and the preconfigured tenants of an instance