In the previous part, I outlined governance features that organizations may use if they wish to fully enjoy the advantage of having Identity Management solution. Today, I will show some examples of how Identity Governance features are handled in midPoint.
I will start with simple workflow, that can be for instance enforced on user-role assignment requests. MidPoint offers great flexibility in creating approval processes. You may have multi-level approvals consisting of many steps, you may have different approval strategies within single step (first decides vs. all must decide) and you may also set approval steps durations and escalation policies so midPoint knows what to do when original approver does not respond in time. That way you are able to include many different approvers to your workflows, starting e.g. with business managers, then role approvers and ending with Security team.
Technically, best way to setup your workflows is to use midPoint’s global policy rules which may be combined with meta roles. I recommend setting the mandatory steps (e.g. manager approval) to global configuration so every role request is governed by at least one fixed rule. Then you may combine it with per-role setting using the meta roles. Meta role for instance induces additional approval action from security which follows manager approval step. By assigning roles to this meta role, you effectively turn on/off whether role is approved by security or not, it’s like a flag. The variability of configuration of midPoint workflows is really vast. You can combine policy rules with other midPoint’s synergistic concepts like high-order inducements – e.g. using organizational structure to induce approval rules. Special type of approval rule is SoD – when two or more roles are marked to be mutually exclusive, approvers can still override such rule in specialized approval step (if set).
But enough of role requests, let’s see Identity Governance jewelry now! This is certainly Access certification in my opinion. In midPoint, certification is technically different piece of code than request workflow, but some similarities (escalation, part of outcome logic) exist. The crucial difference is that certification campaigns typically contain multiple users and multiple roles, therefore many reviewers are asked for action. In classical request workflows, manager (e.g. step #1) approves the role and workflow immediately advances to step #2. On contrary, in certification campaigns when approver makes decision, nothing happens (yet). That decision is accounted only when the whole stage ends for everybody – e.g. after one week from the campaign beginning. It’s like a big gong. Certification campaigns, like many other features in midPoint, are very generic, common use case is to certify user-role assignments, but you may also include many different types of objects in the scope – e.g. role-role inducements or service-resource, organization-role, user-organization assignments and more.
With practise I began to appreciate stages concept a lot. In classical request workflows, target user usually needs something (new role) as fast as possible. In certification, no end user is really in hurry to (perhaps) lose privilege and we can afford to give the best comfort for reviewers by providing them fixed moments when they can go to midPoint and see all cases at once. There is one more thing I like – simple, but brilliant idea, which makes campaigns for reviewers extra effective in midPoint. Certification GUI is designed for bulk data and in fact it’s just one huge table, where each line represents user-role assignment. Right next to the assignment information are the decision buttons (approve/reject), so reviewers do not need to click in for detail and therefore finish work-items swiftly.
I have already shown how midPoint’s policy rules can be used to turn on workflows on role requests. There is other usage of policy rules – enforcing that objects (e.g. users or roles) are in certain state before midPoint allows to save them. Good example is rule enforcing that active roles must have description and at least one owner and approver. On top of setting restriction rules, midPoint is also capable of setting rules for automated assignments. There are actually more configurable options, how to do that so e.g. every employee from certain department gets respective business role. Also, midPoint’s organizational tree offers easy way to induce roles from organizations that users are assigned to.
Hope you liked my article about Identity Governance with midPoint! There are certainly some features I missed (e.g. business roles, more org. structure), but hopefully you got a nice taste of the area.