Simplicity is the most complex of all concepts.
Dune: House Corrino by Brian Herbert and Kevin J. Anderson
Basic idea of role-based access control (RBAC) is very simple: instead of assigning the same privileges to users over and over again, let’s group such privileges into roles. Then assign roles to users. Such RBAC roles often align with organizational roles such as manager, assistant or analyst. Therefore, roles are quite easy to understand even on an intuitive level. RBAC should make your life easier - at least in theory.
Role-based access control principles are present in almost all identity management systems. Therefore, it is no surprise that RBAC is one of the basic midPoint access control mechanisms. MidPoint supports all the usual RBAC features, such as role hierarchies, an automatic assignment of roles and entitlement definition. However, midPoint goes beyond traditional RBAC. MidPoint roles can be smart. There may be dynamic expressions inside midPoint roles, such as attribute mappings. The roles may be conditional: one role is included in another role, but only in case that a specific condition is satisfied. The roles may be parametric: the role can determine the specific set of entitlements based on the user data or a parameter of a role assignment. Traditional concept of roles is enhanced with policy: rules, expressions and constraints applied to roles. MidPoint advanced RBAC mechanism, together with role auto-assignment capabilities and other policy mechanisms create a very powerful combination to express complex policies. This creates policy-driven RBAC, a mechanism that is quite unique to midPoint. Although midPoint policy mechanisms are based on RBAC principles, its capabilities are similar to other popular access control models, such as attribute-based access control (ABAC) or policy-based access control (PBAC). For the curious, there is a discussion of midPoint approach in light of other access control models at the end of this chapter.
Role dynamics in midPoint goes even one step further. The RBAC system can be applied to the roles themselves, thus creating meta-roles. It is quite common that the roles are divided into several types: application roles, business roles, technical roles and so on. However, all the business roles have common characteristics such as common approval processes, common life-cycle policies etc. Instead of copying the common parts into each and every business role, the business roles may be assigned a common archetype which acts as a meta-role. Archetype defines all the common characteristics of all business roles, therefore the RBAC system is much easier to maintain. More on that later.
Powerful RBAC mechanisms in midPoint are flexible enough to handle very complex scenarios. However, we will start small. We begin with simple scenarios, building our way up. This chapter describes basic midPoint RBAC mechanism. It provides enough information to start with the usual role-based approach. Following chapters will build on that, describing more and more advanced use of the RBAC mechanism.
|
Note
|
Terminology
The term RBAC is many things to many people.
We use the term RBAC in quite a broad sense.
We do not strictly mean NIST RBAC model.
What me mean by RBAC is a generic mechanism that is based on the concept of roles.
Although the basic principles of midPoint RBAC are very similar to NIST RBAC model, we take the liberty to deviate from NIST model when needed.
As you will see later, such deviation is really necessary.
|
Previous chapters were focused on account provisioning and synchronization. Their primary focus was an account (or a similar resource object). This is what we call reality in midPoint way of thinking. Accounts are objects that exist in the databases and files on the resources. In that aspect they are almost tangible things. Existence of an account allows user to access a particular system, to execute operations and so on. Therefore, we consider an account to be something real.
However, how do we know whether an account should exist or it should not exist? The situation would be quite clear if midPoint is the only source of truth. In that case, if there is a linked shadow, then account should exist, if there is no shadow, then account is illegal. However, reality is almost never that simple. In real deployments, MidPoint is not the only source of truth. It is usually human resource (HR) system that is the source of the truth – but only for some types of users, usually employees. Then there are external users, temporary workers, special personas for user administrators, services, devices and so on. Some of them may have their own authoritative source systems similar to HR database. However, for some users it may still be midPoint which is the ultimate source of truth. Moreover, that "truth" may be in fact only partial information, or it may be compiled from several sources. To keep long story short: reality is messy and complicated. It is often quite difficult to figure out which accounts particular user should have and which he should not have. Yet, this distinction is absolutely crucial for cybersecurity. Various identity management systems came with broad range of mechanisms to handle this problem, and sadly, those mechanisms are often not very good. Fortunately, midPoint was designed from the beginning with a full awareness of this problem. Therefore, there is a clean distinction between reality and policy in midPoint.
Accounts, shadows and links are what we refer to as reality. Those describe what exists, what is. Then there is a separate mechanism to describe policy. Policy, in midPoint parlance, means definition of what should be. In the ideal world, reality and policy should be in accord. They should describe the same state of things. However, we do not live in ideal world. Perfectly good accounts may be deleted by mistake, illegal accounts may be created, entitlements may get mixed up, attribute values may get destroyed – there are many dangers in the big wild world out there. Then there are scenarios when we actually want reality to be different from policy for a given period of time. Those may be migration scenarios when a new system is being connected to midPoint and the data needs to be cleaned up. Reality and policy do not match exactly in practice. We all know that only too well. Therefore, midPoint is designed in such a way that it can graciously handle the differences between reality and policy.
When it comes to policy, the most important concept is an assignment. Simply speaking, assignment is a data structure which specifies that a particular user should have something. The simplest case is account assignment. This type of assignment states that the user should have an account on a particular resource.
The mechanism that midPoint uses to define that a particular user needs an account, entitlement or other resource object is called construction. The simplest case is a construction that specifies to create an account (a.k.a. account construction):
<user>
...
<assignment>
<construction>
<resourceRef oid="8a83b1a4-be18-11e6-ae84-7301fdab1d7c"/>
<kind>account</kind>
</construction>
</assignment>
...
</user>The term construction means that object on that particular resource should be constructed. In this case, the object on OpenLDAP resource should be constructed for this particular user. If no construction parameters are specified then a default account will be constructed. Which means that outbound mappings in the OpenLDAP resource definition will be used to set up the account.
Construction can be quite a complex data structure describing object types, object classes, attributes and so on. However, it is unlikely that they will be placed directly in assignment like in the above example. More on that later. What is important for now is that assignments specify policy.
After the assignment is added to a user, and all the processing and provisioning takes place, the situation looks like this:
Assignment is a definition of policy which states that an OpenLDAP account should exist for Alice. When such assignment is added to Alice, there is suddenly a discrepancy between reality and policy. The assignment states that Alice should have an account, but no such account exists on OpenLDAP resource yet. It is a nature of midPoint to align policy and reality as much as possible (unless it is told otherwise). Therefore, midPoint tries to create missing account. Once that account is created, reality and policy are aligned once again.
This may look like a very complicated method to do something simple. However, this kind of thinking is really necessary to handle complex cases. There may be several assignments that mandate the same account. There may be assignments for the same accounts, but each assignment mandates different attributes or values. The account that the assignments mandate may exist already, e.g. it may be linked by previous reconciliation with the resource. There may be several accounts for the same user on the same resource (e.g. "ordinary" account and "testing" account). And so on. We will deal with various cases in this book. Yet, the basic principle is always the same: assignments are policy and midPoint is trying to align reality to match the policy.
There is much more in the concept of an assignment than just the very simple account assignment. Assignment is a generic mechanism that is used in midPoint for wide variety of cases, from simple account provisioning to really complex identity governance policies. One specific assignment type is particularly interesting with respect to the topic of this chapter: role assignment.
The basic idea of role-based access control (RBAC) is simple: Instead of assigning account to users directly, let us group all accounts that a particular group of users need into a role. Then assign the role to users. Later on you may add new application to your system, and you probably want existing the users to have account there. In that case all that is needed is to add that account to a role and recompute the users. All the users that should have the account will get the account. This principle is reused for many purposes in midPoint: accounts, privileges, authorizations, policies …
Role is a special type of object in midPoint. Yet, as all midPoint objects, role has a very familiar structure:
<role oid="aaa6cde4-0471-11e9-9b50-c743da469067">
<name>Business analyst</name>
...
</user>Role object has its object identifier (OID) and name. The rest of the role usually specifies the privileges that the role gives to the users. We can assign the role to a user by creating an assignment:
<user>
<name>alice</name>
...
<assignment>
<targetRef oid="aaa6cde4-0471-11e9-9b50-c743da469067" type="RoleType"/>
</assignment>
</user>User alice has role Business Analyst assigned.
The assignment is using the familiar style of object references in midPoint, referring to the role by its object identifier (OID).
This is very useful, as the assignment stays valid in case that the role or the user are renamed - and both of those events are much more frequent that one would think.
Provisioning is the bread and butter of identity management.
Therefore, it is quite understandable that the most natural usage of roles in midPoint is to automate provisioning.
Provisioning roles are usually combining several construction statements.
The idea is that a provisioning role should specify all the privileges that users of that role need.
Therefore, a Business Analyst role may look like this:
<role oid="aaa6cde4-0471-11e9-9b50-c743da469067">
<name>Business analyst</name>
<inducement>
<construction>
<!-- OpenLDAP resource -->
<resourceRef oid="8a83b1a4-be18-11e6-ae84-7301fdab1d7c"/>
<kind>account</kind>
</construction>
</inducement>
<inducement>
<construction>
<!-- CRM resource -->
<resourceRef oid="04afeda6-394b-11e6-8cbe-abf7ff430056"/>
<kind>account</kind>
</construction>
</inducement>
</user>The usual case is that every employee need to have basic access to company functionality. In our case, that access is granted by an account in central OpenLDAP directory. In addition to the basic LDAP account, business analysts need access to the CRM system. The role combines all the accounts that a business analyst needs. Assign that one role, and the user has all that is needed to do the job.
The key to the functionality of roles is inducement. Think of inducement as indirect assignment. Assignments give privileges directly to the object in which they are placed. The assignment in the previous section gave account to the user, because it was placed in the user object. However, here we do not want the accounts to be created for a role. We want accounts to be created for all the users that have the role. That is one order of indirection down the line. Therefore, we (usually) do not want to use assignments in roles. We want to use something that reflects this indirect relation. That is exactly what inducement is. Inducement is very similar to assignment - in fact it has exactly the same structure. However, while assignment is direct, inducement is indirect.
MidPoint user interface can show a nice summary of the inducements:
It is perhaps worth explaining what happens if this Business analyst role is assigned to a user.
When Business analyst role is assigned to a user, midPoint processes all the parts of role definition.
MidPoint takes the inducements from the role, and applies them to the user.
In fact, midPoint behaves in almost the same way as if those construction statements were specified directly in user’s assignment.
This results in a familiar situation: policy mandates that two accounts should exit, but in reality there are no such accounts.
Therefore midPoint creates the accounts.
Of course, midPoint also creates appropriate shadow objects and links them to the user.
This is how midPoint implements role-based access control (RBAC) for provisioning purposes.
We have already seen how outbound mappings can be used in resource to set up account attributes. Roles can also contain outbound mappings, therefore they can be used for a similar purpose:
<role oid="aaa6cde4-0471-11e9-9b50-c743da469067">
<name>Business analyst</name>
<inducement>
<construction>
<!-- OpenLDAP resource -->
<resourceRef oid="8a83b1a4-be18-11e6-ae84-7301fdab1d7c"/>
<kind>account</kind>
<attribute>
<ref>ri:title</ref>
<outbound>
<expression>
<value>Business Analyst</value>
</expression>
</outbound>
</attribute>
</construction>
</inducement>
...
</role>When the above role is assigned to a user, an account on OpenLDAP server is created.
The account is provisioned in a usual way - all the outbound mappings from resource definition are applied to set up the account.
However, there is one difference.
The role specifies one additional outbound mapping for the account.
This mapping is included in the set of usual account mappings when the account is provisioned.
Therefore, the account has attribute title set to Business Analyst.
This is a very typical pattern used by many midPoint deployments:
-
Common and usual attribute values are specified by outbound mappings in the resource definition (in
schemaHandling). Usually, those mappings that take user properties as their source, producing values for account attributes. Many of those mappings do not even transform the value at all (asIsmappings). Common identity attributes such as username and full name are provisioned this way. -
Attributes that are specific to roles are defined in the roles themselves. Those mappings often do not have any source at all. They just set a static value (literal
valuemappings). Entitlement associations such as group membership are also provisioned this way. More on that later.
At the time when midPoint is about to provision an account, all the mappings are merged and processed together. It is quite common that more than one role has a construction for the same account. All those constructions from all such roles are merged together, and they are added to the mappings specified in resource definition. All those mappings are used to compute final values of account attributes.
Most account attributes are single-valued. Attempt to set more than one value for such an attribute ends up with an error. Therefore, it does not make sense to specify more than one mapping for single-valued attribute. The mapping can be specified in a resource definition or in the role, but only one of those should be active at any time. Mapping conditions and strength can be used to selectively deactivate some mappings in more complicated cases. However, it still means that only one mapping is supposed to set the value.
Some account attributes are multi-valued. In that case, midPoint merges the values from all the mappings. Several roles may contribute to the final set of attribute values, as can the mappings in resource definition. This is the usual case of attributes that specify privileges, such as permissions, authorization codes, access control list (ACL) entries and so on.
Merging of multi-valued attributes is an easy way how to manage simple privileges in resources. However, midPoint contains sophisticated mechanism for managing entitlements such as groups. There is an entire chapter in this book dedicated to entitlement management.
|
Note
|
Additive principle.
MidPoint is built on a principle of merging.
Assigned roles are merged together, further merged with outbound mappings, entitlements are merged and so on.
MidPoint always adds, it never subtracts.
E.g. there is no simple way how one role can "eliminate" a value given by another role.
If a role specifies that an account should have value A, that account will have value A.
That’s it.
It can also have values B and C given by other roles.
However, A will always be there, no matter what other roles do (unless those roles are involved in some really dark magic).
This may seem quite limiting.
However, it is sufficient for the vast majority of cases.
It only needs a change in your way of thinking about privileges.
Do not think about removing a privilege.
Think about not adding a privilege.
There are many ways how that can be achieved.
There is a role hierarchy, mappings can be conditional and whole assignments and inducements can be conditional too.
We are trying really hard to avoid concept of "removing" privileges, because that requires ordered processing.
E.g. if role X adds something and role Y removes it, the final result depends on the order in which such roles are processed.
This creates ambiguities, it limits parallelism and overall it is a huge complication.
Therefore, we try to avoid it.
And so far we have been successful.
|
Ability to group privileges into roles is somehow useful. However, it is still not good enough unless your access control policy is extremely simple. Most practical policies require placing roles into roles, thus creating role hierarchy.
Let’s consider two work positions: clerk and supervisor. We are going to create roles for both work positions. Clerk has some basic set of privileges. Supervisor can do everything that a clerk can do, but supervisor has some additional privileges. A naive way would be to simply copy all the clerk’s privileges in supervisor’s role. However, privileges are seldom static. Access control policies tend to change and evolve as much as the environment changes. It is likely that a clerk’s privileges will change in the future. In that case, we would need to update the supervisor’s role as well. This would be a maintenance burden. Now imagine hundreds or thousands of related roles that need constant maintenance. Any person maintaining such a structure would need superhuman precision and patience to do that.
A better idea is to include clerk’s role into a supervisor’s role. If clerk’s privileges change, then also supervisor’s privileges are automatically updated. Maintenance is much easier. This is the basic idea of role hierarchy. Basic privileges are placed into low-level roles. Low-level roles are combined to create a higher-level roles. Then those roles may be combined as well. The process is repeated until there are all the roles that are needed for assignment to users.
Creating role hierarchies in midPoint is quite easy. A clever reader would already expect that this has something to do with inducements - and clever reader would be absolutely right. Role hierarchy is nothing more than a set of inducements between roles:
<role oid="48d4ef98-20e3-46ab-cd78-548d38364a6b">
<name>Clerk</name>
<!-- Privileges needed to do clerk’s work will be here. -->
</role><role oid="86e58643-d5e7-36a8-04f6-38dc3754f04e">
<name>Supervisor</name>
<!-- Privileges that are unique to supervisor’s work will be here. -->
<inducement>
<!-- This "includes" all the clerk’s privileges in this role -->
<targetRef oid="48d4ef98-20e3-46ab-cd78-548d38364a6b" type="RoleType"/>
</inducement>
</role>The inducement includes Clerk role in Supervisor role.
When midPoint evaluates the Supervisor role, it gets all the inducements from both the Supervisor and Clerk roles.
This process is almost transparent, it works almost as if the clerk’s privileges were copied in the supervisor’s role.
All the constructions in all the inducements in both roles are processed.
Therefore, supervisor will get all the accounts that a clerk would get, plus few extra privileges.
Both Clerk and Supervisor roles are likely to have construction for the same account.
This is quite natural, as both clerk and supervisor would probably work with the same applications.
However, their privileges are different.
This is where the merging mechanism becomes very useful.
When a supervisor role is processed, then privileges of clerk are merged with privileges of supervisor:
<role oid="48d4ef98-20e3-46ab-cd78-548d38364a6b">
<name>Clerk</name>
<inducement>
<construction>
<!-- Record management system -->
<resourceRef oid="84de003e-014f-2040-efbc-482e009ed2bcf"/>
<kind>account</kind>
<attribute>
<ref>ri:priv</ref>
<outbound>
<expression>
<value>read</value>
<value>create</value>
</expression>
</outbound>
</attribute>
</construction>
</inducement>
</role><role oid="86e58643-d5e7-36a8-04f6-38dc3754f04e">
<name>Supervisor</name>
<inducement>
<construction>
<!-- Record management system -->
<resourceRef oid="84de003e-014f-2040-efbc-482e009ed2bcf"/>
<kind>account</kind>
<attribute>
<ref>ri:priv</ref>
<outbound>
<expression>
<value>approve</value>
<value>modify</value>
<value>delete</value>
</expression>
</outbound>
</attribute>
</construction>
</inducement>
<inducement>
<targetRef oid="48d4ef98-20e3-46ab-cd78-548d38364a6b" type="RoleType"/>
</inducement>
</role>When supervisor’s role is processed, midPoint figures out that those two construction statements are referring to the same account.
Therefore, they are merged together.
Supervisor gets an account that has priv attribute set to values read, create, approve, modify and delete.
|
Note
|
Assignments in roles.
So far we have seen only inducement in the roles.
But what about assignment?
Assignment is indeed used in the roles, but it has different meaning.
Inducement means that role A has to be included in role B.
However, assignment means that role A has to be applied to role B.
In that case, role A is in fact a meta-role.
More on that later.
For now, it is good to remember a rule of the thumb: role hierarchy is always created by inducements.
|
MidPoint role is a very useful kind of animal, therefore it is used for almost everything in midPoint. MidPoint role can be used as:
-
Provisioning role: The role can include constructions that control provisioning and deprovisioning of accounts.
-
Entitlement management: The constructions can include specification of entitlement associations such as membership in groups, resource-side roles, possession of privileges and so on.
-
Internal authorization: The roles give access to data in midPoint itself. E.g. a role can allow reading selected user properties. Authorizations in a role can also allow access to particular parts of midPoint user interface, remote network services and so on.
-
Policy specifications: Roles (and especially meta-roles) are the places where important parts of policy management is specified. Roles include policy rules that can apply segregation of duties (SoD) policies, approval policies, compliance policies and so on.
All those aspects can be combined into a single role. Therefore, such role can specify everything that is needed for the role holder to live a complete digital life: access to systems (accounts), entitlements, access to midPoint itself (e.g. for self-service), apply policy constraints and so on. Everything in one place.
Role universality may seem mundane and completely natural, but in fact it is quite unique and incredibly powerful idea. As you will see later, roles can be driven through approval process, lifecycle management can be applied to role, roles can be subject to policies, role compliance can be evaluated and so on. All of this applies to ordinary (provisioning) roles. However, the same mechanism can be applied also to roles that govern the administration of midPoint itself - even to meta-roles that specify high-level policies. Which means that in a strange post-modern way, midPoint can be applied to itself. MidPoint can be its own manager.
|
Note
|
Surprisingly, role universality is quite a unique concept in the identity management field. The common approach of traditional identity management systems is to separate provisioning roles, authorization roles, governance roles and so on. Each of them was different, and it was managed in a different way. It was quite difficult to create a unified and consistent policy. This is one of many aspects where midPoint provides a seemingly simple mechanism, but that mechanisms simplifies a lot of things and provides an elegant solution to a difficult problem. |
There are many ways how a role hierarchy can be structured.
One way is to create all roles as "end user" roles that are supposed to be directly assigned to user.
The clerk-supervisor example above is that case.
The low-level roles (e.g. Clerk) should contain all the privileges necessary for that role to function in an organization, such as all the necessary access to all the applications, networks, services and devices.
Then combine the elemental roles into a bigger roles, combining business responsibilities as needed.
Repeat the process until the entire access control landscape is covered with beautiful roles.
That is the theory.
It is perhaps no big surprise that the practice is quite different. There is one big problem with the theoretical approach described above. It assumes that the person who defines roles knows what privileges should be included in that role. I.e. it assumes that business processes and especially business responsibilities are clearly defined. It is a very reasonable assumption. It is also an assumption that is almost always utterly false.
Oh no! How can we proceed if one of our fundamental assumptions is false? Is role-based access control (RBAC) doomed to failure? Certainly, there are people who eagerly proclaim that role-based approach is useless, suggesting many innovative approaches that are usually even more useless in practice. Role-based access control is not dead, not even close. RBAC practice is just much harder than it may seem.
Yes, it is true that nobody knows exactly what privileges a clerk should have. However, it is known what privileges Harry Harris needs to do his day-to-day work. Harry is a clerk. Therefore, it is perhaps fair to assume that the privileges that Harry has are pretty much the same privileges that should be included in clerk role. This bottom-up approach may not be perfect for business analytics puritans, but it is a practical approach, favored by many pragmatic organizations.
However, it is not practical to start with roles that have business meaning.
I.e., it is not practical to start with Clerk role, as we do not yet know what privileges should be in that role - because we do not know what privileges Harry has yet, and we may not even know that Harry is a clerk.
There are too many missing pieces to start solving the business puzzle yet.
We start by creating application roles. Those roles deal with access to a single application. An application role may be quite broad, as giving access to the entire application, or it may be quite narrow giving access to small parts of the application.
The usual starting point is to create an application role for every group in Active Directory or a similar central directory system. Groups are very good starting material. They tend to be the right granularity, not too broad, not too narrow. Users are already assigned to groups, as they need the privileges given by the group membership to carry out their work. Therefore, the groups form some kind of basic vocabulary to start access control conversation among application administrators, business people and role engineers. Starting with groups makes sense from a business continuity perspective as well. Good starting point, indeed.
Let us create application role for every Active Directory group. Such application role grants account in Active Directory, as well as membership in one specific group. MidPoint entitlement mechanism is an ideal tool to do this.
|
Note
|
Entitlements and synchronization of application roles
Indeed, midPoint entitlement mechanism is an ideal tool for building application roles.
Unfortunately, the Entitlements chapter of this book is not written yet.
MidPoint reference documentation can provide the necessary information in the meantime.
Similarly, generic synchronization is an ideal tool to keep groups and application roles consistent.
There are some information about generic synchronization in the Organizational Structure chapter.
|
Strictly speaking, application roles are not meant to be assigned directly to users. They are supposed to be abstract, to be the base "material" used to create higher-level roles. However, we are not at that maturity level yet. We have to accept that application roles are assigned directly to users, at least for now. Although we are not strictly doing any serious role-based access control yet, we can already do some role-based magic with application roles only. Once we have application roles, users can request them, we can review and approve the request, assign some roles automatically and so on. We can keep track of who has what and why, when it was assigned and how (requested, approved) - these are very useful data. Owners can be assigned to application roles, keeping an information who is responsible for each particular group. There is still a lot of value even at this point.
|
Note
|
Misery of application roles
Obviously, there are some downsides to using application roles.
Application roles duplicate the information that is already present in the resource.
E.g. there is one application role for each Active Directory group.
When an information is duplicated, there is potential for the copies to become inconsistent.
As there is usually a huge number of application roles, automatic synchronization is an absolute must to make long-term maintenance of application roles feasible.
Strictly speaking, application roles may not be necessary in midPoint.
MidPoint has a clean concept of construction that can refer to entitlements, which can be directly used in business role.
However, this method is difficult to combine with the bottom-up approach, therefore it is not used often.
During the early years of midPoint we had hope to avoid using application roles at all.
Even earlier versions of this book advocated such approach.
However, the practice of application roles seems to be well established already.
Even though application roles may not be perfect, they are very practical.
We have to admit that.
|
Once we have the application roles, we can start combining them into roles that have a business meaning. Those higher-level roles are called business roles, as they reflect the needs of the business, such as specific job or responsibility in a business process.
Here comes the Clerk role at last.
The Clerk role is created by combing several application roles.
How do we know what roles to combine into Clerk role?
We have a look at Harry Harris, who is a clerk.
Application roles that Harry has are probably the application roles that should be included in Clerk business role.
This is the way we can create our business roles, working from the bottom up.
This sounds easy, yet it never really is that simple.
Harry may have other responsibilities besides being a clerk.
Therefore, the Clerk role is not supposed to contain all the Harry’s application roles.
We may need to have a look at the roles of Violet Vickers who is doing similar job in the same organization unit and compute an intersection of Harry’s and Violet’s application roles.
Even that may not be entirely precise, as both Harry and Violet may have other responsibilities, and they may share a common application role purely by chance.
Also, there may be roles that Harry and Violet have, and they do not actually need them.
It is very difficult to get this exactly right.
However, it is perhaps better to have not entirely precise yet somehow manageable system than to have no system at all.
It may be daunting task to do this analysis for every user (or combination of users), manually, with just a rudimentary tooling. This smells like huge spreadsheets that gets outdated even sooner than the analysis is done. In fact, it is usually feasible to define just a small subset of business roles, leaving many application roles assigned directly to users. This is not entirely right, not right at all. Yet, it is feasible, while complete business role coverage is usually not. Once again, it is better to have working partial solution than to have non-working perfect solution.
Yet, there is some hope. So-called "artificial intelligence" methods have quite improved lately, creating practical tools. Such techniques can be applied to role engineering as well, usually in a form of role mining. Role mining is an automated process that detects similarities in role assignments. It can detect that a specific combination of application roles is assigned to a specific group of users. Such combination could make a good candidate for a business role. Role mining can do this at scale, analyzing many users and roles in one session. This is a great tool to speed up role engineering process. The tooling is quite rudimentary for now, and it may look somehow complex to use. Yet, it is practical, for those that have the courage to try it. MidPoint 4.8 has a role mining capability that is worth trying.
In some deployments, there are more types of roles, not just application and business roles. The other roles are much less common, yet they are used from time to time. The table below summarizes role types:
| Role type | Description | Content | Should be assigned to users? | Example |
|---|---|---|---|---|
Application role |
Role describing access to a single application. Usually represents one specific entitlement in the application, such as application group, privilege or role. It is bound to one specific application (hence the name). Application roles are often created automatically by importing/synchronizing entitlements, e.g. by importing Active Directory groups. |
Access to a single application. MidPoint |
No. Yet, they are quite often assigned to users. |
Active Directory Domain Administrators Company Website Editors Database |
Technical role IT role |
Combines several application roles or low-level privileges into one unit that is easier to manage. Often used for application roles that depend on each other, e.g. when operating system access is needed to perform database administration. They are considered to be somewhere between application roles and business roles. They are not application roles, as they can give access to several applications. They are not business role either, as they do not describe a complete business responsibility, and they often use very technical and non-business-friendly terminology, which makes them a separate species on their own. They are not used very often. |
Access to a couple of application that depend on each other, or make sense together. Several midPoint `construction`s, referencing couple of resources. |
In exceptional cases, e.g. very specific and complex IT responsibility. |
Database Backup/restore management |
Authorization role |
Provides internal authorizations or privileges in the system where it is defined. In midPoint, these are roles that provide access to parts of midPoint itself. Authorization roles do not grant access to any other systems. |
MidPoint |
No. Yet, some roles may be assigned to users in early stages of the deployment when business roles are not fully formed yet.
Especially the |
MidPoint MidPoint |
Business role |
Business role represent a business responsibility, function in a business process, business-related work position or similar business concept. Business roles are supposed to be a combination of smaller "elemental" roles. |
Any other role type, including other business roles. |
Yes |
|
There are pre-defined archetypes for application and business roles in midPoint 4.8. As we will explain later, archetypes give character and behavior to objects. The two pre-defined role archetypes are ready to use in midPoint. Role wizards are prepared to create new application and business roles to match the archetypes.
Overall, role engineering is an art rather than a science. It is not strictly a technological job. Entire identity management and governance is about business-IT cooperation, which is never easy. Role engineering is even harder, as there is even bigger overlap to business. Much more cooperation, patience and persistence is necessary to get practical results. However, the results are well worth the effort. More on that later, in future versions of this book.
At the first sight, the concept of assignment may seem quite mundane, maybe even over-complicated. In fact, it is a very powerful concept, and it has been a crucial part of midPoint design from the very beginning. Assignment is so much more that just a simple user-role connection:
-
Assignments can have validity period. This can be used to assign roles for a temporary period of time. It can also be used to assign roles that will be activated in the future.
-
Assignment have administrative status that can be used to manually disable or enable a particular assignment. This can be used to manage exceptions from the policies or it can be very useful in emergency situations.
-
Assignments can contain parameters that are used to support parametric roles.
-
Assignments are subject to policies, governance and compliance mechanisms. Assignments have their lifecycle, they are subject to re-certification campaigns, there can be policy exception recorded for an assignment and so on. More on that in later chapters of this book.
For example, assignment validity period can be used to assign a role only for a temporary period:
<user>
<name>bob</name>
...
<assignment>
<!-- Deputy Cheerleader role -->
<targetRef oid="0c87d8f8-c9a4-11e9-81b8-e7d43e9f9a2b" type="RoleType"/>
<activation>
<validTo>2019-12-31T23:59:59Z</validTo>
</activation>
</assignment>
</user>As assignment and inducement are in fact the same data structure, similar approach can be used to disable parts of role hierarchy:
<role>
<name>Marketing Research Undersecretary</name>
...
<indudement>...</indudement>
<indudement>...</indudement>
...
<indudement>
<description>
Employee access to the lab is disabled because the lab burned down
during an ugly accident. Will be re-enabled when the lab is rebuilt.
</description>
<!-- Experimental Research Lab Access role -->
<targetRef oid="e8ef819c-c9a4-11e9-80a8-1bddb446391e" type="RoleType"/>
<activation>
<administrativeStatus>disabled</administrativeStatus>
</activation>
</inducement>
</user>Many types and variants of assignments can be combined in a single user. Assignment validity periods may overlap, there may be disabled assignments and enabled assignments for the same role at the same time, there may be several assignments to the same role with various parameters and so on. All reasonable combinations are supported, which allows modeling very complicated schemes such as multi-affiliation, multiple employment contracts and so on. Assignment is a crucial data structure for midPoint platform, and we will be dealing with it in almost every chapter in the book.
RBAC is a nice and elegant method to create and maintain access control policies. However, there is a serious danger: roles can be quite explosive. The role structure can easily get out of control, and the roles may start to multiply. This is known as role explosion, and it is one of the nastiest drawbacks of access control system based on static roles. It is not uncommon for an organization to have much more roles than it has users. This creates a recurring maintenance nightmare. Fortunately, midPoint has a very powerful support for dynamic roles that can significantly reduce or even completely eliminate the impact of role explosion.
To understand dynamic roles, we first need to understand what is the problem with static roles.
Many organizations have jobs that are very similar, they just differ is some small detail.
For example, all bank tellers are similar, the difference is just the branch office where they work.
Similarly, all the assistant jobs are pretty much the same.
The difference is the department or section that they work for.
Therefore, there is Sales Assistant, Engineering Assistant, Logistics Assistant - and a hundred or so similar roles.
Almost all the privileges in those roles are the same.
Of course, we can create an (abstract) role Assistant that will have all the common privileges.
However, we still need those hundreds of specific assistant roles as sub-roles of the common Assistant role.
And then it gets even worse, because there may be Senior Sales Assistant, Trainee Sales Assistant, Senior Engineering Assistant, …
The key to the role explosion is a realization that those "exploded" roles are created in an algorithmic way.
Maybe we do not need Sales Assistant, Engineering Assistant and Logistics Assistant roles at all.
Maybe we need just one Assistant role.
The organizational unit (sales, engineering or logistics) is just a parameter to that role.
Then the number of roles can be significantly reduced.
This is what we call parametric roles.
Parametric roles are not your ordinary garden-variety roles that contain a fixed set of privileges.
Parametric roles need to be much smarter.
E.g. the Assistant role needs an algorithm, that takes the organization unit as an input, and it outputs privileges that are appropriate for that organizational unit.
This may be a simple expression that determines correct group name based on organizational unit name.
Yet, it may be quite a complex code that determines most efficient location of home directories and other resources based on office location.
There is no free lunch.
The algorithm that was used to generate the number of "exploded" roles is not going to magically disappear.
In case of parametric roles, that algorithm needs to be placed in the role itself.
However, it may still be easier to maintain a couple of expressions in few smart roles than to maintain thousands upon thousands of ordinary roles.
The usual problem with parametric roles is, quite obviously, the presence of the parameters. The parameters cannot be stored with the role, as they are different for each assignment of the role. The parameters also cannot be stored directly with the user, as the user may have the same role assigned with a different set of parameters. Fortunately, midPoint was designed with this problem in mind. This was one of the big motivations to create a concept of assignment in the first place. Assignment is the right place to store the parameters, as it is the data structure that associates user with a specific role.
ExAmPLE is a very progressive company.
Similarly to other corporations, they have functional organizational structure.
However, their employees are also organized in teams.
Each team can have a manager and ordinary members.
The team membership is represented by custom attributes in LDAP server.
Each user has two custom multi-value attributes: exampleTeamMember and exampleTeamManager.
Both attributes expect team name as their value.
The naïve way to handle this would be to create two roles for each team.
However, there are hundreds of team, and this approach would create a maintenance nightmare.
A smarter solution is to use parametric roles.
There are only two roles: Team Member and Team Manager.
Those roles take custom property teamName as parameter.
But where does this property comes from?
It comes from assignment extension.
Each time the team role is assigned, there needs to be a parameter in the assignment:
<user>
<name>alice</name>
...
<assignment>
<extension>
<exmpl:teamName>x-force</exmpl:teamName>
</extension>
<!-- Team Manager role -->
<targetRef oid="aaa6cde4-0471-11e9-9b50-c743da469067" type="RoleType"/>
</assignment>
</user>This is the first part of the solution.
The second part are the roles.
The roles need to be a bit smarter to use the teamName parameter:
<role oid="aaa6cde4-0471-11e9-9b50-c743da469067">
<name>Team Manager</name>
...
<inducement>
<construction>
<!-- OpenLDAP resource -->
<resourceRef oid="8a83b1a4-be18-11e6-ae84-7301fdab1d7c"/>
<kind>account</kind>
<attribute>
<ref>ri:exampleTeamManager</ref>
<outbound>
<expression>
<path>$assignment/extension/teamName</path>
</expression>
</outbound>
</attribute>
</construction>
</inducement>
</user>Resulting LDAP account looks like this:
dn: uid=alice,ou=people,dc=example,dc=com
objectclass: inetOrgPerson
...
exampleTeamManager: x-force
...This setup is illustrated in the following diagram:
This is the basic mechanism of parametric roles.
It is incredibly powerful mechanism.
Unfortunately, current implementation of parametric roles in midPoint is quite limited.
While midPoint was designed with parametric roles in mind, the implementation is not yet finished.
MidPoint core engine supports parametric roles quite well.
Assignment parameters and mappings should work perfectly.
However, the support for assignment parameters in midPoint user interface is very limited.
In fact, the production-quality support is limited only to the couple of hardcoded parameters (orgRef and tenantRef) and even that leaves a lot to be desired.
While we would like to improve support for parametric roles in midPoint, we have to listen to what midPoint subscribers are saying.
Our development priorities are influenced by midPoint platform subscribers.
So far platform subscribers prioritized other features and therefore there was not sufficient funding to completely finish user interface support for parametric roles.
|
Note
|
Roles may also explode due to other reasons. Application roles that were mentioned above may significantly contribute to role explosion. Also attempts to "atomize" the low-level roles as an attempt to create enough "material" to compose higher-level roles may lead to explosion. MidPoint has some mechanism that limit those effects. However, perhaps the best approach for those cases could be summarized as "do not overdo it". |
MidPoint roles are usually applied to users. However, midPoint roles are universal. The roles can be applied to almost any midPoint object. Roles can be applied to users, organizations, services and even to roles themselves. Roles applied to other roles (and other objects) are meta-roles.
Meta-roles may seem similar to a role hierarchy. However, meta-role is a completely different animal. The crucial difference is that the meta-role is applied to the role, and not to the user. The inducements in the meta-role often contain policies such as approval policy, or construction clauses that create groups or organizational units. We usually do not want to create a group for each user. Yet, we often want to create a group for application role. That’s what meta-role can do.
Meta-roles can specify behavior and apply policies to broad classes of other objects. This makes meta-role mechanism very flexible and powerful, one of the most important mechanisms in midPoint.
Archetypes are the most common objects that work as meta-roles. Therefore, we will explain the details about meta-roles in Archetypes chapter.
This section is where we will get all thoughtful and philosophical. The people that are bored with philosophical questions should skip the rest of this chapter. We will also throw some dirt on almost every access control model in existence. Therefore, the people that maintain dogmatic beliefs about identity and access management mechanisms should skip this section as well. On the other hand, open-minded people are quite likely to enjoy it.
Role-based access control (RBAC) is just one of many access control models. There are many variants of RBAC, and there are other access control models that are based on a completely different paradigms. One such popular model is attribute-based access control (ABAC). ABAC is based on an idea that access to the systems can be determined dynamically, just based on "attributes". Simply speaking, we can imagine ABAC as a one big algorithm that takes "attributes" as an input and decides whether access should be allowed or denied.
Policy-based access control (PBAC) is similar to ABAC. PBAC extends the notion of attribute-based decisions to an abstract concept of policy. Access decisions are still supposed to be algorithmic, although the algorithm is not limited to attributes.
ABAC is very popular in the access management (AM) community because of its simplicity. PBAC, as an extension of the idea, is also gaining traction. It all makes much sense, as it is much simpler and faster to evaluate one policy expression than to sift through a mountain of roles. The problem with ABAC and PBAC is manageability. ABAC and PBAC assume that all access control decisions could be based on algorithms, that they can be made anytime a decision is needed. However, that is almost never the case in larger practical deployments.
Too many identity professionals dream about complete automation of access control. It would be a marvel if an access control system could automatically determine the privileges of every person simply based on the organizational unit, work responsibilities or any other attributes of that person. It would be perfect to get that information from an HR system, process it through a set of algorithms and automatically provision correct privileges to everybody. That is a very nice dream, indeed. However, reality has a different idea. Such automated approach never really works in practice.
First problem is at the very start: HR data are almost never correct. There is very little motivation for the HR data to be completely correct. It is not a big issues if someone has a wrong job code or organizational unit code in the HR system. The business goes on, the salary is paid, everybody is happy. There is no efficient feedback loop that would force corrections in HR data - until the identity management system is deployed, that is. It takes years or even decades for a typical company to deploy an identity management system. At that point the HR data are beyond repair. The corrections that need to be done in the HR system are substantial. It is very difficult to correct HR data manually, even in small organizations. Bigger deployments absolutely require proper tooling to do that job. However, even with good tooling, it usually takes a lot of time to get the data right. Many identity management deployments were significantly delayed, or even canceled, because of data quality problems. Reliance on correct input data is dangerous. Identity system should be able to handle wrong input data.
The identity management deployment should not be delayed because of wrong input data. That would be like refusing to use your reading glasses because the text you are reading is misspelled. Identity management systems are essential tools that assist you in the process of data clean-up. The identity management system should be deployed using whatever data are available, and it should be used to manage data quality on day-to-day basis. It is naive to think that once the data are cleaned-up they will stay clean. The processes that crated data errors are still there, therefore data errors are going to appear all the time. The crucial insight is to accept that there are (and will be) data errors, and to design the mechanisms to detect and correct them.
There are many manual and ad-hoc decisions that need to be made in practical identity management deployments. This is not limited to identity management deployment project. Many ad-hoc decisions must be made during routine day-to-day operation of deployed system. Privileges need to be assigned manually to compensate for missing input data. Privileges need to be corrected, input data need to be temporarily overridden, policy exceptions has to be made. There are many things that need to be done manually, almost on day-to-day basis. For ABAC, PBAC and similar models this would mean that a policy needs to be updated on a day-to-day basis. However, these systems are not designed for such flexibility.
Then there is another big problem: the data are incomplete. Even if HR are data are correct, the data usually do not provide all the information needed to completely provision the user with privileges. The HR data are often limited to organizational unit and formal code of the work position. However, this is often miles away from the job that user really does. The usual solution to this problem relies on the users to request the privileges that are needed to do their jobs. Such request is routed through appropriate approval process. That request is a big problem for ABAC and PBAC. What exactly should the user request to get the privileges? Should the user request a change in the "policy"? That would not be practical. Should the user request a new value for an attribute? Which attribute? What value that would be? Users will need a way to choose what they are requesting from a list of options. Can we somehow create a catalog of the things that a user can request? Once again, ABAC and PBAC are not designed for this. Yet, all those problems are very easy to solve in RBAC. User is expected to request a role. It is quite easy to create a role catalog. Role is a concept that users are familiar with. However, as ABAC and PBAC do not rely on roles, there is nothing that a user can get a grip on. There is no "handle" that would allow the user to make much sense from the abstract policies.
This is all a consequence of yet another ABAC/PBAC problem. While ABAC/PBAC policy may be easy to set up, it is quite difficult to analyze and maintain. There are simple and obvious questions that are very difficult to answer in ABAC/PBAC world. What are the privileges of this specific user? Which users are entitled to access this particular application? Which users are affected by this particular policy statement? How many users will be affected if I make this change to policy? ABAC/PBAC systems would need a complex simulation algorithms to answer those questions. However, answering such questions is quite easy in RBAC model. In RBAC, policies are encapsulated into roles. Therefore, only the users that have those roles are affected. The roles also divide the policy to a smaller, manageable pieces. Each of the roles can have its own state and lifecycle. Therefore, it is not that difficult to work with two versions of the same role at the same time. Old version is still assigned to some users, but we are deprecating that and slowly migrating to a new version. Such continuous processes are difficult to do in ABAC.
Then there is still one crucial problem when ABAC/PBAC is used in provisioning scenarios. The "policies" often benefit from the fact that complete data about the user accessing the system are available when the access control decision is made. The crucial part of that data is called context. This includes data such as time of day, network location of the user, recent events related to the user, real-time estimate of the risk and so on. However, such data are simply not available in provisioning scenarios. Accounts are usually provisioned long before the first access to the account is made. Therefore, many of the advantages of ABAC/PBAC are useless in identity management scenarios that rely on provisioning.
However, ABAC and PBAC are not complete failures. They are very useful in customer-oriented identity and access management (CIAM). Customer identities are usually "lightweight", and the policies are simple. However, when there is a need to manage employees, teachers, contractors and similar "heavyweight" identities then ABAC/PBAC approach almost always fails.
The fact that ABAC/PBAC fails in complex practical identity management deployments does not mean that RBAC is ideal. Quite the contrary. RBAC has problems of its own, and the applicability of pure RBAC in practical identity management deployments is very limited. Many of the problems of RBAC model motivated engineers to develop ABAC, PBAC and similar models. In fact, the "algorithmic" idea of ABAC/PBAC is not entirely bad. Only if we had a way how to combine ABAC/PBAC and RBAC … oh, but there is a way! We did it already.
MidPoint combines RBAC and ABAC/PBAC by putting expressions into roles. We have seen that already. When role is assigned, the expressions in the role gets evaluated. There can be any complex algorithm in the expression, even a complete ABAC/PBAC policy. At least in theory. MidPoint expressions do not make access control decisions, because it is not the job of an identity management system to make such decisions. Identity management system should set up the account. It provides the "material" for an authorization system to make a correct decisions. Therefore, midPoint goes as close to ABAC/PBAC as a provisioning system can go. In an extreme case the entire ABAC/PBAC policy can be implemented in outbound expressions in resource definition. Yet, there are a good reasons nobody does that.
Dividing the policy into smaller parts brings substantial advantage. Therefore, many midPoint deployments are very RBAC-like. There are many roles and rich role hierarchies. Role expressions are used in moderation. Yet, there are also deployments that are using parametric roles and role expressions extensively. In such cases there is a smaller number of roles, almost no role hierarchy, but the roles are smarter. Those are more PBAC-like deployments. Yet, roles are still there. The roles act as "handles" for users to understand the policies, to give names to relevant parts of the policy. This combined approach works surprisingly well.
Of course, this idea is not new. Many RBAC-like systems use some kind of "smart" behavior inside the roles. However, so far we haven’t seen anything as comprehensive as midPoint dynamic role-based access control model. Therefore, we had to invent an impressive marketing name for our creation. Due to a momentary lapse of imagination we dubbed it policy-driven RBAC (PD-RBAC). Whatever you choose to call it, the fact is that this approach is very useful in practice. It can transform apparent chaos into something that can be efficiently managed. After all, that is the whole point of identity management and governance.
Role-based access control (RBAC) means many things to many people. Some consider it a cure-all, the only viable access control standard, others consider it cumbersome, yet others proclaim its death. Whatever is said about RBAC, the fact is, that RBAC is here, and it is here to stay. When it comes to midPoint, RBAC has its place as a very useful concept and essential tool. The truth is that the policy-driven RBAC variant that midPoint is using is miles apart from the traditional static RBAC models of the past. MidPoint would not be able to work efficiently without major innovation of the RBAC model.
Role-based access control as well as dynamic policies are at the heart of midPoint. Similarly, identity management systems such as midPoint are at the heart of IT infrastructure. Many applications implement at least some aspects of RBAC or similar access control models. However, almost all the applications limit the applicability of RBAC to the application itself. I.e. roles in an application can contain only those privileges that apply to that particular application. The roles cannot have privileges from other application. However, identity management systems are different. Identity management systems such as midPoint are reaching out to many applications (resources). Therefore, a single midPoint role can give access to many applications at once. No other application can do that. This properly alone make identity management systems indispensable.