What you cannot enforce, do not command.
Many people think that all the identity management systems do is management of identities. This view is simple, easy to understand and wrong. Of course, a lot of functionalities of identity management system are indeed designed to manage identities. However, identity management systems are information systems too. As information systems, identity management systems have to do all the usual boring stuff that all self-respecting information systems do. Such as controlling access to data and operations.
We are talking about controlling access to data and operations within midPoint. We do not want any user to see a list of all the data of all the other users, and we definitely do not want any user to modify the data. As pretty much any other information system, midPoint needs an ability to deliberately limit access to data stored in its repository. However, as midPoint is an identity management platform, the requirements for access control to data are quite demanding. For example, following scenarios are quite common in identity and access management world:
-
Allow any user to see its own user profile, allow editing selected set of properties. A user can see significant part of own user profile. However, when looking at other users, only a very minimal set of properties is displayed.
-
Allow members of an organizational unit to see more details about people in the same organizational unit. For example, team members would like to see e-mail addresses and telephone numbers of other members of the same team.
-
Allow managers to see more details about people in their organizational unit, maybe even allow them to edit some user properties.
-
Allow project managers and research leaders to assign members to projects they are managing.
-
Allow call center agents to change limited set of properties for any user, except for users marked as sensitive (such as superusers).
-
Allow system administrators to see configuration details, but only for the system that they own. Also allow to see all account information that midPoint keeps for that particular system.
-
Allow ordinary users to browse roles, select them to form an access request. Let the users see only a limited set of role properties, to let them effectively select a role, but do not reveal too much about role composition and specific privileges.
-
Allow role administrator to see all details of roles that he owns. Also, allow editing of roles that he owns, but only the roles in a
draftlifecycle state. We do not want to have uncontrolled changes to roles that are actively used. -
Allow auditors to see everything - except for sensitive personal data. Although the auditor can see almost everything, he can change nothing.
These are common scenarios. Then there is exotica, such as a very custom and fine-tuned access for some administrators, support engineers, business power users and so on. This is further complicated with the access given to other systems instead of users. MidPoint has to be able to support all such scenarios. Quite obviously, midPoint access control mechanism needs to be very flexible, customizable and fine-grained. And indeed, it is.
Access to midPoint data is controlled by authorizations. Authorizations are small access control statements that are located in midPoint roles. Authorization statements from all the active roles assigned to a users are combined, specifying access control policy and privileges of that particular user.
Despite authorizations being relatively small, they may be quite complex. Such complexity that comes from simplicity is perhaps no surprise for anyone that ever worked with flexible access control system. This chapter attempts to explain the intricacies of midPoint authorizations, starting from the simple cases, working towards the complex ones.
In theory, the essence of any authorization scheme is very simple. An authorization statement has three basic parts: subject, action and object:
-
Subject is the active part of an operation. It usually represents the user initiating an operation.
-
Action specifies what the operation does. The action is usually specifying read or write data operations, such as
read,add,modifyordelete. -
Object is the passive part of an operation. It is the "thing" that is being affected by an operation.
Authorization allows action to be performed on object by subject.
For example, it allows user aanderson (subject) to modify (action) organizational unit Project Enigma (object).
The basic idea of this approach is to create authorization statements that allow operations for specific subject-action-object combinations. However, it would be quite difficult to maintain large set of authorization statements if they are maintained in a single place. Therefore, midPoint has authorization model integrated with the role-based access control (RBAC) mechanisms. Authorization statements are placed inside midPoint roles, which are in turn assigned to users. A user that has a role with an authorization statement is automatically considered to be a subject of the statements. This approach allows very scalable and maintainable authorization configurations.
Authorization placed in a role looks like follows in XML notation.
The orgRef clause refers to Project Enigma org.
This authorization allows read and modify operation for project Enigma.
<role>
<name>Project Enigma Maintainer</name>
<authorization>
<action>http://midpoint.evolveum.com/xml/ns/public/security/authorization-model-3#read</action>
<action>http://midpoint.evolveum.com/xml/ns/public/security/authorization-model-3#modify</action>
<object>
<type>OrgType</type>
<orgRef oid="9b909ef0-2deb-11ed-a421-971f0aad86d0"/> <!-- Project Enigma -->
</object>
</authorization>
</role>TODO: several causes in authorization (type and orgRef) → all must match
However, this simple scenario is not very practical.
We usually do not want to grant permission to modify a single project.
That approach does not scale well.
Therefore, single authorization statement often grants permission to modify many objects.
For example, we may want to have a Project Maintainer role which allows a user to modify any project.
While extending the authorization a bit, the result looks like follows in XML notation.
<role>
<name>Project Maintainer</name>
<authorization>
<action>http://midpoint.evolveum.com/xml/ns/public/security/authorization-model-3#read</action>
<action>http://midpoint.evolveum.com/xml/ns/public/security/authorization-model-3#modify</action>
<action>http://midpoint.evolveum.com/xml/ns/public/security/authorization-model-3#add</action>
<action>http://midpoint.evolveum.com/xml/ns/public/security/authorization-model-3#delete</action>
<object>
<type>OrgType</type>
<orgRef oid="832e37e4-edfd-11ea-9f8c-ef736d6646a2"/> <!-- "Projects" org hierarchy root -->
</object>
</authorization>
</role>TODO: many subjects, using a filter → maintainer of all projects (all subnodes of Projects top node (832e37e4-edfd-11ea-9f8c-ef736d6646a2))
TODO: giving abiliy to add and delete projects as well.
TODO: NOTE: orgRef may be too powerful. It grants transitive rights. Use with care. Good for simple delegated administration, but not for fine-grain control. Use filters instead.
TODO: example of simple authorization: allow modify any Org
TODO: XML example of authorization statement
TODO: TIP: authorizations are stored in roles: aligning RBAC and internal access control: benefits
TODO: action and object are "multi-valued", e.g. filter for objects, multiple actions.
TODO: table with subject-action-object examples
TODO: use of filters in subject/object
TODO: … sometimes also target
TODO: default deny
TODO: Roles for everything
TODO: allow vs deny
TODO: authorizations are supposed to be additive, avoid using deny unless there is a very good reason
TODO: big picture: user, role, authorization, action, object (from docs)
TODO: Authorization apply to midPoint, are enforced in midPoint. Applied to other system only indirectly.
TODO: note how to apply authorizations in other systems (entitlements). They can be in the same role.
TODO: assign and unassign authorizations, access request
TODO: this is where target is often used
The same for orgunits, services and other "assignment holders".
TODO: All the authorizations that were mentioned so far are object access authorization, or data access authorization if you will.