Roles are for entitlements and user classes are for people, and never the twain shall meet
I keep running into bad terminology when talking to new and prospective customers about organization structure and roles. People frequently confound t
wo quite unrelated concepts, calling both “roles.” This leads to confusion and much wasted effort trying to design unworkable systems, as I’ll explain below.
First, what are the concepts? In identity and access management (IAM) systems, we’re mainly interested in managing the lifecycles of people — identities, and their entitlements — typically login accounts and group memberships on end systems. Confusingly, some systems use the term ‘role’ to mean ‘security group, assignable to users within this system or application.’ I can’t make vendors like Oracle change their terminology, but I’ll take it as a given that anything assignable to a user within a single system or application is either a login account or group — even if that system thinks its called a role.
- Role. Roles are named collections of entitlements, that the IAM system can assign to users. They might be assigned automatically, because of some policy, or because of an (approved) request.
- User class. A user class is a set of users (i.e., identities or people). Users might be included in the user class individually, but the more common scenario is to collect users into a set by some rule — say based on their department, location, business unit, etc.
- Organizational hierarchy. This just means that every user should, ideally have (at least one) manager. We like to know the manager/subordinate relationship for all users because this relationship feeds into many useful processes: change authorization, access certification and more.
Nesting is implied in both user classes and roles. When roles are nested, it means that parent roles also include the entitlements of their child roles. This is represented by attaching one or more roles as entitlements in a parent role. There should be no technical restriction on how many roles a role may contain, or how deeply nested roles can be. In practice, most implementations use this sparingly, but in theory, at least, nesting can be both broad and deep.
As for user classes, we can think of “all people sharing a given manager” as a user class. This specific type of user class represents a hierarchy, so can be thought of as being nested. We could ask the system to show us a list of people who report both directly and indirectly to a given person — as one way to exploit this hierarchy. The organizational hierarchy is just a (possibly visual) representation of this nesting of the manager/subordinate user class.
So what’s the problem?
Many people use the term ‘role’ to mean two totally unrelated things:
- The set of people who fit into a particular part of the organizational hierarchy — say all reporting to some manager, or all working in some department. THIS IS NOT A ROLE!
- A set of entitlements (i.e., really a role this time).
- Some combination of these two incompatible ideas — i.e., both a set of people and a set of entitlements, mixed up together.
I think people do this because they haven’t thought about clear definitions for roles or user classes. Quite often, they haven’t thought about user classes at all, but instead have only a very ambiguous idea of “some hierarchy of people and entitlements.”
People then make it worse by talking about ‘role nesting’ but actually meaning the nesting of these imaginary, hybrid role/user class things (that should not exist in any well designed IAM system). What does nesting mean when we’re talking about users and entitlements at the same time?
My advice is for everyone to just stop doing that. Roles are one kind of thing — collections of entitlements. User classes are another kind of thing — collections of people. Each of them can have its own hierarchy. You cannot include a role as a member in a user class. You cannot include a user class (or even a single user) as a member of a role.
By keeping the language clear, we can design much simpler, cleaner systems. For example, automatically assign some role to all members of some user class. That’s a nice way to automate access in many cases. Or ask the members of a user class to approve the manual assignment of a role to users. Or ask the members of a user class to recertify the list of people who were (manually) assigned a role. All these things are simple, clear and useful. What someone would do with weird, hybrid, role/user class things is beyond me.