This page describes a feature planned for future midPoint versions.
This feature is roughly designed and it was evaluated as feasible. However, there is currently no specific plan when it will be implemented because there is no funding for this development yet. In case that you are interested in supporting development of this feature, please consider activating midPoint Platform subscription.
There are many motivations for this feature, each of them looking at the feature from a slightly different angle.
Firstly, there are lists of objects that are used quite frequently, such as list of all employees, list of all contractors, list of all business roles and so on. It would be nice to have such lists pre-defined and then reuse that definition in many places:
- Menu: It would be nice to have a menu item to quickly list all employees or business roles. Just click on that and there is a user list that contains just the employees.
- Dashboard: Having a custom dashboard widget that displays object collection and works as a quick access to see the collection would be nice as well.
- Search: Global search field may be extended with a control that allows searching in specific collection (e.g. employees, business roles, ...)
In addition to that, there may be specific views defined for a collection. E.g. we would like to see different columns when we list employees than the columns that we see for business roles. Similar approach may be applied to ordering, default items present in the search box and other details of user interface presentation.
As midPoint already has ability to export results of a search operation as CSV this can be used to create quick ad-hoc reporting capability. Just define frequently-used filter as object collection. Then click on that collection in menu, click on the CSV export button and import that to your favorite spreadsheet processor.
The idea of object collections may look simple, but there is unexpected strength in it. Object collections can be slightly extended to support simple compliance reporting. Simply speaking, the collection itself provides already some form of compliance reporting. E.g. even a simple filter can be used to show disabled users or active roles. If we add ability to use expressions in filters then this feature gets more interesting as we would be able to show all the users that are about to expire in next two weeks. If we add a little bit of metadata (e.g. timestamp of last lifecycle transition) then the things may be get even more interesting, e.g. we can get ability to show all the roles in
proposed lifecycle state that are stuck in this state for more than a month. Or we could show all the orphaned accounts that were detected in last 24 hours.
This will give us very basic compliance reporting. But this can be extended even further. We can extend object collection with the definition of the domain. In other words the collection may know what is the set of all the objects from which the collection is filtered out. For example the collection of disabled employees may know that it is in fact selected from list of all employees. Then the collection can evaluate percentages. For example, the disabled employees collection may show that there are 52 disabled employees, which is 2% of all employees.
The collections could be easily presented in a form of dashboard widget, like this:
Click on the dashboard widget could lead directly to a list of disabled employees, therefore an administrator can take action to rectify the situation.
This compliance reporting gets even more interesting when it is coupled with policy rules. When a policy rules is evaluated a special-purpose policy situation property is set. The policy situation is set in every object or even every assignment for which the policy rule is triggered. Then the policy situation can be used to report on the result of policy rule evaluation.
For example, let's assume that we are about to implement new segregation of duties (SoD) policy. However, we do not want to blindly roll out the policy, as existing role assignments may immediately be in violation and that may impact the business. Therefore we would like to know how many existing assignments are in violation of the policy. We may want to manually resolve the situation for each violation. But that may take some time, it may take days or even weeks. And we would like to monitor the progress. Therefore this is what we can do:
- Set up SoD policy rules. Those rules will not enforce the policy. Not yet. The rules will just set a special policy situation when evaluated.
- Recompute all the objects to evaluate the assignments and policies. This will set the policy situations in objects.
- Set up object collection that collects all the objects and assignments with that policy situation.
- Use object collection to list all the objects that are in violation, setup dashboard widget to monitor the progress and so on.
This is a very flexible mechanism as it relies on policy rules that are already quite flexible. E.g. several policy rules may use the same policy situation, therefore their effect may be evaluated together. E.g. several rules may work together to implement data protection policy and the progress of data protection implementation can be monitored from a single dashboard widget.
The object collection concept can be further refined in the future. E.g. there may be thresholds that change dashboard widget color, send notifications and so on. E.g. we could display the above dashboard widget as red if the percentage of disabled employees gets above 5%.
TODO: It would be nice to use just "employees" as a criterion in authorizations instead of copying the search filter everywhere. And also policy rules.
TODO: scanner task that looks for users to expire and send notifications ... and showing the same information on a dashboard.
New Policy Rules
TODO: Policy rules that triggers on collections, e.g. percentage of a collection more than 5%, count less that 1, etc.
Phase 1: Collections and Views
TODO: Collections: definition (system config).
TODO: Views: use in GUI (filter, columns, maybe search box)
Collection is not just GUI concept, is is core concept. View is a GUI concept that builds on top of object collection.
Phase 2: Compliance
TODO: allow expressions in filters (e.g. all users about to expire in two weeks)
TODO: more metadata (e.g. timestamp of last lifecycle transition, timestamp of sync situation change, timestamp of policy situation change)
TODO: Collection "domain" and percentages
Phase 3: Use in Authorizations and Policy Rules
- Selection for global search to search in specific collection (employees, business roles, ...)
- Integrate with reporting, e.g. ability to schedule a report based on object collection that will produce CSV or a spreadsheet and send it by mail.
- Threshold definition in collections and their properties (e.g. above 10%: display widget as red)
- New Policy rules that triggers on collections, e.g. percentage of a collection more than 5%, count less that 1, etc.
- Collections and views could be used only on (native) midPoint objects. Which includes users, roles, orgs, services, resources, tasks and almost anything else. With a notable exceptions of work items (e.g. approvals). Work items will not work with object collections and view (at least not yet). But some approval information can be evaluated indirectly, e.g. by looking at object metadata.
Additional improvements may be needed for this feature to be usable in a convenient way:
- Lightweight recompute process that will only update policy rule situations. Currently the policy situation gets updated during full recompute. This is perfectly acceptable for consistent small-to-medium scale deployments. But for complex, large and/or partially inconsistent deployments an improvement to recompute process may be needed.
- "Quick preview" of a policy rule effect: GUI functionality that transparently sets up policy situation for the rule (or rulesets/policies) and associates a collection(s) with it.
- The concept of policy as a collection of related policy rules. The policy may be used to evaluate many related policy rules together, version them together, control their lifecycle and so on.
- It may be needed to record assignments that are not yet approved (e.g. in proposed lifecycle state). Currently such assignments are only part of the delta which is encapsulated in approval processes and work items. It is not directly observable in the objects (e.g. users).
Those features are anticipated in the future, but they are not yet planned to any specific midPoint version or implementation date.
- - MID-3408Getting issue details... STATUS
- - MID-3517Getting issue details... STATUS
- Policy Rules