Object Collections and Views Improvements

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:

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:

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 compliance percentage gets below 95%.

Object views are mostly just a presentation concept, those affect only the user interface. But underlying object collections can be used for much wider purpose. Most notably, the collections may be reused in authorizations and policy rules. E.g. It would be nice to use just "employees" as a criterion in authorizations instead of copying the search filter everywhere. Similarly this collection may be reused in policy rule specifications. In the future there may be scanner tasks that scan just the objects that belong to the collections, bulk actions for the collections and similar improvements.

Reusing the definition on many places is not just convenience. It is important for consistency of configuration. Nothing in the IDM world is really constant. E.g. the definition what is an employee may change in time. If object collection is used properly, then that definition needs to be updated in just one place. All the authorizations, views and dashboards should adapt automatically.

Object collections open new opportunities for midPoint. The amount of objects that is part of the collection may change, the collection may grow or shrink. And it is quite obvious that there may be events associated with such changes. For example we might want to notify the administrator if the proportion of disabled user is suspiciously high. Or we want to notify security officer in case that the overlap of people that have both executive controlling privileges gets too high. In other words: we may want to react when a specific threshold is reached.

In midPoint 4.0 several objects were "promoted" to be able to contain assignments. Object collection was one of those. This means, that object collections can now contain policy rules. In a typical midPoint tradition of reuse, we want to apply policy rules to the collections themselves. Therefore reaching a specific threshold may be just a new constraint for a policy rule. Then the usual actions associated with policy rules can be applied. Which, once again, works very well with somehow an independent functionality with quite similar effect: thresholds.

Combination of policy rules and object collections is a critical part of planned compliance functionality. It is also important for customizable dashboards.

Implement definition of a collection (as a new object type). Collections will contain simple object query. Implemented in midPoint 4.0.

Implement object views as part of midPoint user interface. The views can define basic properties (columns, sorting. maybe search box configuration). List views in menu. No dashboard support yet. Implemented in midPoint 4.0.

Note: Collection is not just GUI concept, it is core concept. View is a GUI concept that builds on top of object collection.

Allow the use of expressions in collection e object query. (e.g. all users about to expire in two weeks).

Implement concept of collection domain to allow evaluation of percentages.

Make system dashboard configurable. Allow replacing current hardwired widgets with custom widgets based on collections. Allow adding new widgets. Partial (experimental) functionality in midPoint 4.0.

Optional: create single "compliance dashboard" which will be empty (and disabled) by default. But this page can be used to create a custom dashboard with compliance widgets showing various compliance collections.

Add more metadata to make specific compliance collections useful (e.g. timestamp of last lifecycle transition, timestamp of sync situation change, timestamp of policy situation change)

Make collections usable in authorizations and policy rules. E.g. specify authorization to access all employees, specify global policy rules that applies to all employees and so on.

Additional improvements may be needed for this feature to be usable in a convenient way:

Those features are anticipated in the future, but they are not yet planned to any specific midPoint version or implementation date.