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, for example, 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, for example, enterprise role owners.
All nevisIDM roles have default flags determining whether initial authorization for a certain data room is set to global, that is, authorized for all clients, units, or applications, and whether the data room can be modified afterwards, that is, via GUI or SOAP. The flags as set with the nevisIDM reference data are shown in the table.
| 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 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.
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, you can do so by removing the elementary permission AccessControl.ClientCreate.
Relaxing the check
With the configuration parameter application.dataroom.relaxed.permissions, you can set the data room check to be less strict. A strict data room check means, that for the check to pass, the calling user needs to have the access rights to all the clients, units, and so on, of the target user. A relaxed data room check means, that for the check to pass, the calling user needs to have the access rights to at least one of the clients, units, and so on, of the target user.
For example, if a helpdesk user needs to archive a user, they need the permission AccessControl.UserArchive in all of the units to which the target user belongs, to pass the unit data room check. However if AccessControl.UserArchive is defined in this parameter, then the unit data room check passes for every user in any of the units where this helpdesk user has the AccessControl.UserArchive permission.
Default behavior
During the unit dataroom check, by default AccessControl.UserView is relaxed. Defining application.dataroom.relaxed.permissions in the configuration overwrites this.
Make sure to add AccessControl.UserView to the configuration if you want it to keep having a relaxed unit dataroom check.
Missing this could lead to unexpected permission denials, especially on the UI. For example, to modify a user, it is necessary to show the data of that user first. Therefore, the permission to view the user is also needed to modify the user. Enabling relaxed dataroom check for AccessControl.UserModify alone is not enough.
The considerations apply to other scenarios as well. For example, to be able to create a credential, most of the credentials need not only AccessControl.CredentialCreate but also AccessControl.CredentialModify on the UI. Some of the credentials also need AccessControl.CredentialView permission.
The REST interface is less restrictive.
Example configuration for user modification:
application.dataroom.relaxed.permissions=AccessControl.UserModify;AccessControl.UserView
Example configuration for user modification with credential creation:
application.dataroom.relaxed.permissions=AccessControl.UserModify;AccessControl.UserView;AccessControl.CredentialCreate;AccessControl.CredentialView;AccessControl.CredentialModify