Greetings MIM enthusiasts!
Today I'm going to talk about a small project I've been working on for the past couple of weeks. The idea behind it was born quite a while back, when I did some consulting for a customer that wanted to have more control over group membership than the OOTB MIM portal functionality provides. Namely, the ability to put a time limit on a person's group membership in advance and the ability to define “Enterprise roles”, which comprise of functionally similar permissions, that can span across multiple systems or applications.
The terms “Role assignment”, “Enterprise role”, “Permission” should already be known to anyone who has worked with an RBAC engine before, such as Bhold for example. I don’t know about you, but my experience with Bhold is that it’s not really worth the hassle, the UI is even less user-friendly than the MIM Portal one, plus it was filled with bugs in the early versions – although that might have changed in the recent versions. Anyway, I’ve learned to steer clear of it.
Back to the main topic of this blog post – creating a basic, stateless RBAC engine for MIM. The idea is simple: By using the standard SQL MA and some Portal schema modifications, we want to introduce basic RBAC functionality into our MIM solution. The engine should be fast, error-proof and built on top of the existing MIM infrastructure, as opposed to a separate service/ web portal UI.
The thing I personally really like about MIM sync service is the fact that it’s NOT event based. That means that the synchronization can be run repeatedly on the same input data (=source connector space), resulting in a predictable outcome. If something goes wrong in the process, fix the error and re-run the synchronization. Not true for event-based engines. One such example are MIM workflows – if you create an MPR that fires when a certain condition is met, if something goes wrong during the workflow execution, the workflow will fail and the conditions to trigger it a second time may never be met again (that may be an oversimplification, but you get the idea). That, by the way, is the main reason why I opted for an SQL Server DB / SQL MA / MIM Sync solution instead of a MIM-WAL workflow approach.
The role engine introduces five main object types, as seen on the drawing above:
- User – these are our identities or persons in MIM dialect.
- Permission – these are the actual permissions in the target systems, they can be AD Groups, SAP Roles, O365 licenses, etc …
- Role – Roles are groups of permissions, that can be split into two categories:
- Application Role – contains permissions that provide a common set of functionalities in a single application / system.
- Enterprise Role – Also sometimes called business roles, these roles contain permissions that span multiple applications but are required to complete a common business process.
- Temporary assignment – Temporary assignments can be used to assign people to roles temporarily, such as when they are filling in for someone or when they are assigned to a different workplace for a short period of time. They add a new dimension to group assignments not really present in MIM – time.
- Organization unit – The organizational unit structure typically represents departments in a company, but can be any other organizational hierarchy, such as Project groups. By assigning roles to specific OUs, all people under that OU are assigned the role. In truth, this is kind of the same as MIM criteria groups, only from the perspective of the OU, not the group.
All this data is synced from the MIM Portal to the Role Engine DB via the standard SQL MA, where it is transformed, on the fly, via SQL views, to direct permission membership that can be exported to target systems. That’s what the term Stateless in the title means – there are no stored procedures needed to calculate the data. All the calculations are done via SQL queries. Export, Import, Done.
A more or less detailed guide on how to achieve this in my next blog post: A basic, stateless RBAC engine for MIM Part 1: Roles.