Access Certification in midPoint

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:

Access certification campaign in midPoint

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.

3 thoughts on “Access Certification in midPoint

  • Hi Radovan,

    I like your article. It seems as if MidPoint has a clear vision about how to certify access permissions. However, I have been working a lot with Oracle Identity Analytics recently. OIA offers different types of certification (one of which doesn’t technically work, but that’s another story). I found out that the identity certification type is highly flexible. For example: While virtually everyone on this planet seems to think only about certifying centrally managed accounts, we also think about accounts that are created locally on servers. I know… your argument now might be that this is where a PAM comes into place. But unfortunately we don’t live in world where everything is designed as we’d love it to be. 🙂

    So our solution preprocesses the data to import in such a way that OIAs identity certification can be used to first certify the identity and then whether or not specific entitlements need to be revoked. Since we need to change the visual representation of data so that a manager is able to identify even abbreviated names, we use a feature of OIA that allows us to display toasts with detailed information (we had to fix a bug for that to work).

    I was wondering if such scenarios might be possible to achieve with MidPoint as well…

    Cheers,
    Christian.

    P.S.:

    It’s german, but you may have a look at our blog here: http://blog.toptechnologies.de.
    There’s a whole OIA series with 4 Articles:

    http://blog.toptechnologies.de/post/Microsoft-goes-Linux-und-ich-installiere-Oracle-Identity-Analytics-auf-einem-Windows-Server.aspx
    http://blog.toptechnologies.de/post/Wie-man-wirklich-(!)-eine-manuelle-Korrekturverfolgung-im-OIA-konfiguriert.aspx
    http://blog.toptechnologies.de/post/Bugfix-Glossar-Beschreibung-im-OIA-anzeigen.aspx
    http://blog.toptechnologies.de/post/Wie-man-OIA-Microsoft-SQL-beibringt.aspx

    • Of course, this scenario is possible to implement in midPoint. In fact it is easy to do by combination of several core features that midPoint provides for several years. As any self-respecting IDM system, midPoint can easily do “inbound” reconciliation of non-centrally managed accounts. There are several options what to do: simple link them to maintain status quo or legalize them. Legalization will attempt to create new assignments for such accounts. And those can be routed through approval – which provides almost realtime reaction to change as opposed to a campaign-based certification. But even if campaign-based certification is required this is still possible. Just make the legelized assignments subject to certification. And that’s it. No other extra product is needed. MidPoint can do it all.

      • Thank you for your reply! Maybe I will set up a test environment and evaluate MidPoint then. 🙂

Leave a Reply

Your email address will not be published.