Enterprise roles
The figure below shows an excerpt of the nevisIDM data model. For the sake of clearness, not all classes are displayed here.
The EnterpriseRole class is defined as a set of application roles. Each application role can be member of 0 to n enterprise roles. Basic attributes of EnterpriseRole include extid, name, description, and a language-specific displayName.
Any user's profile may contain 0 to n enterprise roles linked via the EnterpriseAuthorization class. Adding an enterprise role to a profile gives the user the authorization to use all application roles which are members of the enterprise role. The definition of the enterprise role is evaluated dynamically. Thus changing the definition of an enterprise role will have a direct impact on all users with this enterprise role.
Besides assigning an enterprise role, it is still possible to directly add a single application role to a profile via the standard "Authorization" class.
To calculate the set of current authorizations of the selected profile at runtime, the member application roles of all assigned enterprise roles will be resolved dynamically and added to the computed set of authorizations. The directly assigned application roles are added to this set too. Duplicates will be filtered out automatically and have no impact.
Remark 1: It is not possible to remove a role from the computed authorization set which has been added via an enterprise role. This fact has to be kept in mind when defining the member roles of enterprise roles.
Remark 2: Roles of the nevisIDM application itself cannot be members of any enterprise role. Therefore, authorizations for enterprise roles (EnterpriseAuthorization) are considered to be absolute, i.e., it is neither needed nor possible to restrict an EnterpriseAuthorization to any data room.
External visibility of enterprise roles at runtime
At runtime of nevisIDM as an authentication back end, the enterprise role information will be kept internal per default, i.e., the information about whether a role in the propagated security token origins from a specific enterprise role or was assigned directly is not part of the security token.
For the sake of simplicity and manageability, the present data model holds only two levels, i.e., we do not support hierarchies of enterprise roles, but only flat enterprise roles. This will not reduce flexibility since it is possible to assign multiple enterprise roles to the same user profile. Furthermore, Nevis' experience from past projects shows that a flat enterprise role hierarchy combined with the rule-based assignment of enterprise roles (see the chapter: Data model) is a powerful and flexible combination which is able to handle the usual business use cases.
Client membership of enterprise roles
In multi-client environments the visibility of each enterprise role is restricted to a single client. Obviously, clients can use cloned enterprise roles with identical definitions. The figure below shows the situation with a UML class diagram.
Note that the relationship between Client and Application is m:n, i.e., Applications (as a resource) can be visible within multiple clients, while each enterprise role belongs to exactly one client. Therefore, it has to be enforced that enterprise role X belonging to Client Y contains only application roles which are visible within Client Y. This consistency rule will be enforced on both the persistence tier and the web/business tier to provide improved error handling and usability.
Note that enterprise roles are visible within a client for administrators with appropriate privileges, they are not restricted to the user (or its unit) who created them.
Administration of the enterprise role data room
To grant somebody an authorization restricted to certain enterprise roles, i.e., not for all enterprise roles, we introduce an additional data room, the "enterprise role data room". The figure below shows the situation as a UML class diagram. Note that only authorizations for nevisIDM roles are associated with a data room, while roles of target applications are always assigned without data room restriction.
The new data model entities are the two classes AuthorizationEnterpriseRole and EnterpriseRole. Note that there is a logical m:n relation between Authorization and EnterpriseRole which is implemented with the association class AuthorizationEnterpriseRole. If an authorization should apply to all enterprise roles, we can set the enterpriserole-global flag of the Authorization class instead of enumerating all enterprise roles explicitly.
Database tables
Core enterprise role table (TIDMA_ENTERPRISE_ROLE)
| DB attribute | Java data type (max. size), defaults | Description |
|---|---|---|
| client_id | Long, not NULL | The client the enterprise role belongs to. Foreign key that links to information in the table TIDMA_CLIENT. |
| description | String(1000), nullable | |
| displayname_dict_entry_id | Long, nullable | The enterprise role's display name in various languages. Foreign key that links to information in the table TIDMA_DICT_ENTRY. |
| enterprise_role_id | Long, not NULL | Primary key (uniquely identifies each individual DB entry) |
| extid | String(50), not NULL | External identifier |
| name | String(100), not NULL |
Member roles of enterprise role (TIDMA_EROLE_MEMBER)
| DB attribute | Java data type (max. size), defaults | Description |
|---|---|---|
| enterprise_role_id | Long, not NULL | The enterprise role which the application role belongs to. Foreign key that links to information in the table TIDMA_ENTERPRISE_ROLE. |
| erole_member_id | Long, not NULL | Primary key (uniquely identifies each individual DB entry) |
| role_id | Long, not NULL | The application role which belongs to the selected enterprise role. Foreign key that links to information in the table TIDMA_ROLE. |
Enterprise authorization (TIDMA_ENTERPRISE_AUTH)
| DB attribute | Java data type (max. size), defaults | Description |
|---|---|---|
| enterprise_auth _id | Long, not NULL | Primary key (uniquely identifies each individual DB entry) |
| enterprise_role_id | Long, not NULL | Foreign key that links to information in the table TIDMA_ENTERPRISE_ROLE. The enterprise role which is assigned to the profile. |
| profile_id | Long, not NULL | The profile which the selected enterprise role is assigned to. Foreign key that links to information in the table TIDMA_PROFILE. |
Some examples
The figure 10 shows a virtual situation to illustrate several examples. Further assume that
- EOwner1
- enterprise role data room restricted to ER1, ER2
- application data room restricted to App2, App3 (e.g., with role AppOwner)
- is authorized for unit 1 and unit 2
- EOwner2
- enterprise role data room restricted to ER2, ER3
- application data room restricted to App2, App3
- is authorized for unit 2
- EAdmin1
- has an application data room restricted to App 1 and App 2
- is authorized for unit 1 and unit 2
- EAdmin2
- has an application data room restricted to App 3 and App 4
- is authorized for unit 2
Per default, EnterpriseRoleAdmin will not be restricted to applications, but assigned application-globally (analog to AppAdmin). But customization would allow this scenario anyway.
EnterpriseRoleOwner
An EnterpriseRoleOwner can assign whatever enterprise role to the users he is privileged for. Therefore, he is only constrained by his unit data room and enterprise role data room:
- EOwner2 can assign ER3 to User2
- EOwner2 cannot assign ER2 to User1 (unit data room restriction)
- EOwner2 cannot assign ER1 to User2 (enterprise role data room restriction)
EnterpriseRoleAdmin
An EnterpriseRoleAdmin can create/modify/delete enterprise roles without any restrictions. On modifications/deletions, a confirmation dialog will show up with the number of users that are affected by the change (Warning: Your modification/deletion of this enterprise role will affect XX users, are you sure you want to continue?).