On the implementation of RBAC for Workflow and Authorization

RBAC stands for ‘Role Based Access Control’ and is an approach to restrict system access to authorized users based on linking roles to permissions. Many RBAC models exist, but GX WebManager 9 uses the Core RBAC and H ierarchical RBAC models. These models conform to the standard RBAC specification developed by AN SI/INCITS. RBAC concepts and terminology used in this section is based on this standard. In this article, we will elaborate on the key principles of RBAC and their implementation in GX WebManager.

Core RBAC

Core RBAC

Core RBAC is the easiest RBAC model. In Core RBAC, users are assigned to one or more roles. A role is a functional or organizational job description. U sers sharing the same role share the same tasks. A role is assigned to a perm ission. The permission defines one or more operations that may be performed on one or more application com ponents. But each operation is associated with one particular object. Such an operation might be an ‘insert’ or ‘change title’. An application component may be a discussion object or a Media Repository.

A Core RBAC model:

In WebManager 9, RBAC permissions are defined as:

A specific operation on one or m ore WebManager com ponents.

An example of such a permission is ‘Modify page version’ which grants the permission to modify a
page version. In the Core RBAC model the operation is ‘modify’, while the application component
is ‘page version’.In Core RBAC, permissions are not directly assigned to users but to roles. Therefore, roles are introduced in GX WebManager 9 and permissions can only be assigned to roles. Roles are
subsequently assigned to users.

Hierarchical RBAC

Hierarchical RBAC

Hierarchical RBAC is Core RBAC with hierarchy in roles. Role hierarchies define inheritance relations among the roles in terms of permissions and user assignments. If role r1 inherits role r2, then all permissions of r2 are also permissions of r1 and all users of r1 are also users of r2.

A Hierarchical RBAC model:

In GX WebManager 9 this hierarchy of roles is introduced. Each role may have at most one superrole from which all permissions are inherited.

RBAC permission handling

The exact consequence of not having a particular permission is always hard coded; the software itself determined how to react when a user doesn’t have a particular permission. For example, a button may be disabled, an option is not visualized, an access denied exception is thrown, or a particular content update is not performed. The developer therefore determines the security model and authorization granularity of the component being developed. An authorization service is available in GX WebManager 9 which handles all authorization. Basically, the authorization service is called with only the permission as parameter. The service determines the current user and calculates if that user has that particular permission or not.

Permission Groups

The amount of permissions will grow rapidly the finer the authorization granularity will be. Therefore, the concept of a permission category is introduced. A permission category is a collection of permissions that belong to the same software and/or license component. The permission category is used to visually categorize permissions but is also used to enable or disable software or license component in the Configure > Web initiative configuration > Functionalities > Components panel. Disabling such a component ensures that no user will be granted any permission within this permission category at runtime. As a consequence, menu items and GUI options are hidden, and the component will be inaccessible.

Permission groups

Nevertheless, defining proper permissions for each role may be a quite laborious operation. For this reason permission groups are introduced. A permission group is a default set of permissions which can be assigned to a role at once. A permission group assigned to a role will implicitly assign all permissions contained by that permission group to that role.
GX WebManager 9 offers the following permission groups:

• Editor permissions
• Main editor permissions
• Administrator permissions
• Developer permissions

Initially GX WebManager 9 contains corresponding users and roles.

Note: The developer permission group is a ‘special’ permission group. U sers and roles to which this permission group is assigned are hidden from all users except from other developers. The ‘Developer permissions’ permission group is the only group that grants all permissions to the user.