If the access level is defined for whole application - then build standard application role. If you have multiple resources within application and user may have different access level between resources, then build application resource roles.
IGA Design: Application Resources - Parametric Access
The Problem
We have file shares, or confluence spaces, or similar resources. We want to grant access to these resources on several "levels": reader, writer, admin
We do not want to create "cartesian" roles such as Share foo reader, Share bar reader, Share foo writer, …
The Solution
Import shares/spaces/whatever as services in midPoint. These will represent the "things" that the person gets access to.
The user will want to select the "thing" first. That looks natural. I want access to "marketing files" first, only then I think about read-only or read-write access.
Then the user selects a relation to that thing.
Access levels will be represented as relations: reader, writer, admin.
Default relation can be an advantage here, it allows getting "default" access to share/space without caring about the details (without explicitly selecting access level).
Relations that are available for particular type of service (e.g. Windows shares) can be specified in the archetype.
It is natural that all services that represent windows shares will have Windows Share archetype.
The archetype can specify assignmentRelation, listing all the applicable relations.
This is a natural mechanism that works in midPoint GUI already.
Special variations of access (e.g. different account setting) can be specified in orderConstraint in the inducement.
This can be done either in the "thing" itself (space/share), or in the archetype.
Thoughts
This is almost the same process used for teams and projects. I want to be a member of a team/project. Then I think about having a "community-level" access, full member access, being team manager, etc. The relation is used in teams/projects as well.
Relations are global.
This can be a problem if we get 1000 different meanings what "reader" and "writer" mean.
This will lead to explosion of relation definitions.
However, the fact that relation is global may also be an advantage.
IDM engineers will probably tend to reuse reader relation if such relation already exists - simply because reuse is less work than to specify a new relation.
This could naturally create a semi-standardized vocabulary.
For example, I can easily find out all the systems where I am an "admin" by looking at all my assignments that have admin relation.
(Still need to account for non-parametric roles here).
Maybe we can help with this by pre-defining a reasonably rich vocabulary for relations out of the box?
Maybe orderConstraint outgrew its name.
Maybe it is not about the order any more, and we should rename it?
How do we evaluate the risk here?
Obviously, being a reader and admin of the same space is vastly different risk.
Also, being a reader of Public space is a vastly different risk than being a reader of Top Secret (burn before reading) space.
We have to divide the risk to two parts:
-
Risk posed by the content of the service (share/space). This can be specified in the service object. This is obviously very specific to the content of the space/share, this is going to be different for each share/space.
-
Risk posed by relation to the service (reader/writer/admin). This can be specified in the archetype (in
assignmentRelation). It would probably be some kind of "multiplier", a ration that is applied to the risk specified by the space. Risk of a specific relation is probably be the same for all the services. E.g. being a reader of any space will produce 50% of the "nominal" risk specified in the service. Being an admin will produce 300% of the nominal risk.
The overall risk given by a specific assignment is computed from the target of the assignment (in this case a service), and corrected by a multiplier given by the relation.
The implementation of concept in midPoint is described in Access to application resource example 2 and 3 in access modeling.
Additional thoughts - UI and operation
We need some name for such type of roles. Need to be distinguished in the design concepts from standard application roles - configuration will be slightly different and also, operation tasks may be different. Possible names: Application resource role (not just resource role, because this is confusing with midpoint resource), Auxiliary role (not always it is auxiliary - for fileserver it is normal role), Component role (confusing with role component), … Let’t use Application resource role for now.
We could call the relation in UI as access level. This is quite natural for end users. "I want to have access to this resource with reader access level". But we then need to rename the access level attribute in role (basic user / power user / privileged user) to something else. (probably user level).
We must identify in UI the relation that will be default (selected first) in role definition.
This concept is enhancing and slightly confusing the concept how application roles are defined now. Application roles define one level of access within whole application. Application resource roles (parametric roles) define access to resource within the application. As there may be many resources and we don’t want to have many roles for each resource, these application resource roles may define multiple levels of access.
In deployment methodology, we need to define the difference between application roles and such parametric roles to explain application engineer when to use which type of role. The best discriminator is probably application wide vs. application resource definition.
In reporting and views, the concept slightly increases complexity, but it can be quite well handled.
-
Where does the user have access? - list of applications for the user. Nothing changes here.
This is the view My access: by application. -
What access does the user have? - list of (application + role + access level for app resource role). Here we will need to read and display also the "access level" for application resource roles.
This is the view My access: by role.
Although the concept is almost the same as in membership of org. units, it would be best to distinguish it in UI. Not to confuse the user. In business terminology the access into application and being member of an organization are 2 completely different things and mixing is confusing.
Problems
How do we get this to the connector? We so not have complex attributes yet. Moreover, this is in fact a complex membership in an entitlement, membership with a parameter. Do we need to improve ConnId?
How to design the archetype for parametric roles in midpoint ? Will there be multiple archetypes or just one archetype for all parametric roles in midpoint ?
Was this page helpful?
YES
NO
Thanks for your feedback