Identity Management (IDM) systems usually provide quite a broad mix of features. But there is one thing that no other system can do: management of access rights. No other system comes even close, even if they often pretend to do so. Access rights, privileges, role assignments, authorities, authorizations … whatever these things are called they need to be managed. They need to be assigned to the right people in the right systems at the right time. And that is no easy task.
The naïve solution would be to adopt a precise model such as Role-Based Access Control (RBAC) and automatically assign the roles based on deterministic rules (policies). That looks great on paper and auditors love it. But it almost never works in practice. The problem is that nobody can really define the rules that cover every single privilege in every single system for every single user and every single situation. Even if someone spends the tremendous effort to define such rules, it will not take long until the rules get outdated. It usually takes the first re-organization to almost completely ruin all the effort.
Therefore, the IDM systems implement a less formal but much more practical process. The users request the access rights that they think they need to do their work. Someone else reviews the request and approves or rejects it. These approvers are usually managers, security officers, owners of the requested role, owners of the affected system or any combination of these. This method admits that some decisions can only be done by the people because they are difficult to automate. This process may seem not entirely ideal from security and compliance point of view. But the choice is fully-automated formal but infeasible model or a semi-formal partially-automated process that is perfectly feasible. This choice is not that difficult, is it? In fact, the approval process is very successful in practice and if implemented properly, it yields surprisingly good results.
Of course, there is a catch.
The request-approval-provision process works very well. In fact, it works a bit too well. Users get request and get privileges easily in a matter of hours or even minutes. There is an easy way to add privileges and no practical way to remove them. It ends up pretty much as expected: privileges accumulate. A lot.
Clearly, there also needs to be a process to remove privileges. But the same approach will not work here. If the user does not have a privilege that he needs, he is motivated to request it. But if someone has a privilege that he no longer needs – what is the motivation to drop it? Obviously, someone else needs to do it. That’s where the access certification campaigns come in.
Access certification campaign is usually executed at regular intervals. The IDM system determines list of reviewers and a list of privileges that need to be re-certified. The reviewers are usually managers or system owners. They are selected in a similar way as approvers in the role request-and-approval process are selected. The privileges are distributed to reviewers. Each reviewer has to decide whether the privilege is still required for the specific user to do his work. This is done in a fashion that allows to make a lot of decisions very efficiently. Like this:
If a privilege is not re-certified in this way, then it is automatically removed when the campaign ends. This is the way how to keep privilege accumulation under control.
The certification campaigns are usually implemented in specialized systems that belong to the Governance, Risk Management and Compliance (GRC) category. It is still not entirely common for an IDM system to implement this feature. And this feature is especially rare in the open source IDM systems. In fact, there is only one open source system that implements it out-of-the-box: Evolveum midPoint.
Access certification is a part of midPoint since version 3.2. In that version, the feature was available as a technology preview. Usability is a critical part of the process. Therefore, we have first implemented it as a preview to gather user feedback and incorporate that in the final implementation. Two versions later and the feature is implemented in its entirety. The implementation is now finished and it is already merged into the midPoint master branch. It will be released in midPoint version 3.4 that is due in a couple of months. This is the final step that makes midPoint the only open source IDM system capable of handling complete identity lifecycle management out-of-the-box.