Data room authorization
In addition to the previously described functional authorization, there is a second type of authorization, the "data room authorization".
Data access authorization checks access to objects. You have a functional authorization when a role is assigned to your profile. This assignment can include additional restrictions for data room authorization. Data room authorization is part of the assignment of a role.
There are four different data rooms that can be visualized as being a three-dimensional authorization space:
- client data room: the client data room is superior to the other two data rooms because units always belong to exactly one client, and applications are explicitly assigned to clients. As clients are used for the separation of user populations, the common case is that a user is only authorized for exactly one client. There should only be very few users that have authorizations across several clients.
- unit data room: data room authorization in nevisIDM is based on clients and units. Units, in turn, may be structured in a hierarchical way. The authorization for a certain unit always includes the authorization for its subunits, whereas authorization for a unit does not include the parent unit. Note that authorizations are not directly attached to users but to their profiles.
- application data room: administrating a single sign-on solution means to administer various applications, each with separate lifecycles, roles, etc. For this reason, nevisIDM also provides an application data room. It allows to assign the responsibility for applications to specific users, e.g., application owners and administrators.
- enterprise role data room: nevisIDM also provides an enterprise role data room. It allows to assign the responsibility for enterprise role to specific users, e.g., enterprise role owners.
All nevisIDM roles have default flags determining whether initial authorization for a certain data room is set to global, i.e., authorized for all clients, units, or applications, and whether the data room can be modified afterwards, i.e., via GUI or SOAP. The flags as set with the nevisIDM reference data are shown in the [table] below.
| role name | DR client modifiable | DR client initial global | DR unit modifiable | DR unit initial global | DR application modifiable | DR application initial global | DR enterprise role modifiable | DR enterprise role initial global |
|---|---|---|---|---|---|---|---|---|
| Root | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 |
| ClientRoot | 1 | 0 | 0 | 1 | 0 | 1 | 0 | 1 |
| UserAdmin | 1 | 0 | 1 | 0 | 0 | 0 | 0 | 0 |
| UserAndUnitAdmin | 1 | 0 | 1 | 0 | 0 | 0 | 0 | 0 |
| AppAdmin | 1 | 0 | 0 | 1 | 0 | 1 | 0 | 0 |
| AppOwner | 1 | 0 | 1 | 0 | 1 | 0 | 0 | 0 |
| MainAppOwner | 1 | 0 | 1 | 0 | 1 | 0 | 0 | 0 |
| Helpdesk | 1 | 0 | 1 | 0 | 0 | 1 | 0 | 1 |
| TemplateAdmin | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| SelfAdmin | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| SoapTechAccess | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 1 |
| SoapTechAccessReadOnly | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 |
| TechUser | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| Impersonator | 1 | 0 | 1 | 0 | 1 | 0 | 0 | 0 |
| EnterpriseRoleAdmin | 1 | 0 | 0 | 1 | 0 | 1 | 0 | 1 |
| EnterpriseRoleOwner | 1 | 0 | 1 | 0 | 0 | 1 | 1 | 0 |
Assignment of nevisIDM roles
For an administrator to be authorized to assign a certain role to a user, the administrator first needs to be authorized for the application, the client, and the unit data room. However, the preconditions for assigning nevisIDM roles differ from those for non-nevisIDM roles.
In case of nevisIDM roles, there is no application data room for the application "nevisIDM". The configuration file rolesAssignment.properties defines which nevisIDM role is allowed to assign which other nevisIDM role. The preconditions for an authorization to assign a nevisIDM role to another user are:
- The assignment has been enabled in rolesAssignment.properties.
- The administrator user has the elementary permission AccessControl.AuthorizationCreate, that is, a nevisIDM role containing this permission. See also the chapter Elementary rights]" of nevisIDM roles.
- The administrator user is authorized for the client and unit data room of the target user.
Unassigning is equivalent to assigning in terms of the authorization. The required elementary permission is AccessControl.AuthorizationDelete.
Example
The default configuration of rolesAssignment.properties includes the following line:
nevisIdm.SelfAdmin=nevisIdm.Root,nevisIdm.ClientRoot,nevisIdm.AppAdmin,nevisIdm.UserAndUnitAdmin,nevisIdm.UserAdmin,nevisIdm.SoapTechAccess
This expression means that all "value" roles (on the right of the equal sign) are authorized to assign the "key" role, that is, the SelfAdmin role.
Unit constraints and their impact on operations
If there is a unit constraint, we call the unit in it the "authorized unit". The constraint applies to the operations listed below.
- Unit create: The parent unit of the new unit must be in the authorized unit's tree.
- Unit delete: The unit to be deleted must be in the authorized unit's tree (you do not need rights on the parent unit).
- Profile (any operation): The profile must be part of the authorized unit's tree. There may be additional constraints on the Authorization, UnitAuthorization and ApplAuthorization when the role is assigned to the profile.
- User without any profiles (any operation): Users without profiles can only be assigned rights that are not subject to unit constraints.
- User with at least one profile, reading operation: Access to at least one of the profiles must be allowed.
- User with at least one profile, writing operation, delete/archive: Access to all profiles must be allowed.
- Creating a user: A user is usually created together with a profile. In that case, access to the unit of that profile must be allowed.
- Credentials: Access to the user must be allowed.
- Assigning roles in general: The administrator needs to be authorized for the role being assigned and for the profile that gets the new role.
- Assigning/Removing IDM roles: This creates/deletes additional objects that define the data room authorization for the assigned role. The unit data room of the assigned role must be a subset of the data room the administrator has for assigning the role.
The handling of restrictions for applications is somewhat simpler because there is no hierarchy and there is always just one related application object in any operation. The application that is handled must match the authorized application for operations on these objects:
- Application
- Role (There will be additional constraints on the Authorization when assigning the role)
- Authorization (when assigning/revoking roles)
- Application authorization (setting the application data room when assigning an IDM role)
Performance
The performance of nevisIDM may be decreased when you add large numbers of entities (>1000) as data room to the authorization of a nevisIDM role. In such a case, consider to add a global data room authorization instead.
Enforcing single-client operation: restriction of client creation
If the single-client operation needs to be enforced as a business rule, it is possible to do so by removing the elementary permission AccessControl.ClientCreate.