What Are Roles Classes?

It is often necessary to group roles into categories that control their access to resources. One way to accomplish this is with hierarchical roles, using parent and child relationships; however, non-hierarchical arrangements are often preferable for various reasons. To facilitate this, Devii has role classes. These are non-hierarchical "mixins" that can be added to roles, to modify their access. Specifically, a role class will (via the policy rules) add access to tables, views, or individual records. The class acts as a means of scoping policy rules.

The use case for classes is to subdivide roles within a hierarchy more finely than simple hierarchical structure can define, or to create non-hierarchical relationships between roles, if desired. For instance, role classes could be created that apply to all "top-level" roles in a tenant schema, unifying what they can see and operate on, in order to create a "snowflake" arrangement, in which the central roles could all share information and work with each other's data and child roles. Or, role classes could be the primary means of grouping roles, and define different access levels without regards to any hierarchy.

Inheritance

Role classes can be defined so that they inherit according to the role hierarchy, either on creation only, or fully, applying to existing child roles as well. If a role class inherits only on creation, then it applies only when members of the class create new child roles; parents or admins can create children outside of the class for members. Full inheritance applies regardless of who creates the new roles. If a tenant is not using role hierarchies, none of this matters, and the value of the 'inherit' flag is ignored.

Exclusivity

It is up to the policy designer to determine whether role classes are exclusive, i.e., a given role must only exist in one class, or not. For instance, if role classes are used to represent distinct categories of users that have different levels of access (specifically, different filters) to the same resources, such as "store manager" vs "employee" in a point-of-sale and inventory database, then the classes are exclusive, and policy will be written to reflect this.

On the other hand, non-exclusive classes may be used to represent groups in which there is an overlap in access rights to various resources; for instance, in a system serving up content, where all users have the ability to consume content but not all have the ability to create it, everyone might have the "customer" class, giving them consumption rights, but only creators would have the "provider" class, which also gives them creation rights. In this case, policy would be written to give the "customer" class read access to the content tables, and the "provider" class would have write access to those tables. Roles with the "provider" class would still have the "customer" class, as their read access is governed by policy scoped to that class.

If policy is written with exclusive classes in mind, then apps must enforce this by not allowing roles to be set to have more than one class; there is no mechanism in Devii's class system to enforce exclusivity.

Role Class Attributes

classid: Class id. Integer. Unique within schema.

name: Class name. Freeform.

creatorid: Class creator ID.

createtime: Timestamp for class creation.

inherit: String. Can be "none", "create", or "full". The value "full" means that child roles of class members are automatically members of this class, regardless of whether the class members created those child roles; "create" means that child roles created by members are given membership automatically, but child roles created by others (or created before this class was applied to the members) do not; "none" means no automatic inheritance.