midPoint goes multitenant

The organizational structure in midPoint does not always represent a typical enterprise. In case of multitenant setup in the cloud, the organization units represent “tenants” which are completely independent. In enterprise organizations, the sub-organizations and their members are usually readable (to some extent) to all members. In the multitenant setup must maintain tenant isolation. How can this be done using midPoint?

We have created a sample story available here: Multitenant User Management for SaaS. The main goals and tasks documented there are:

1. provide a way of importing an initial tenant information including the tenant itself and the first administrator user for that tenant from a common source. Generate random password and send it to tenant administrator e-mail address. (Represented by CSV file instead of the customer database.)
2. create tenant-like objects in target systems. (Represented by OpenLDAP groups and organizational units created per-tenant.)
3. allow the first administrator user to create more administrators and end users for that tenant. Allow to assign them to roles which will add users to target resources and groups. (Configured as MidPoint delegated administration along with OpenLDAP provisioning to the groups created per-tenant.)
4. allow the administrators and end users to change passwords. (MidPoint user GUI utilizing the delegated administration.)
5. allow the administrators to setup the password policy for their tenant organization. (MidPoint user GUI utilizing the delegated administration.)

The midPoint provisioning functions are really strong, yet in this case the delegated administration is the leading actor here. See how the tenant isolation looks like in GUI:

How administrator sees the organizational structure

How megadot-admin (administrator for tenant megadot) sees the organizational structure

How ultraone-admin (administrator for tenant ultraone) sees the organizational structure

Basically each administrator sees only the “Customers” container and his own tenant organization instead of all tenants.
This magic was achieved by assigning the tenant administrator to his tenant organization with the “manager” relation and using this (and other) fragments of “role-customer-authz-admin.xml”:

<!-- Authorization to read own organization and its content including the path from root - if assigned as manager -->
    <authorization>
        <name>Magic read/modify</name>
        <action>http://midpoint.evolveum.com/xml/ns/public/security/authorization-model-3#read</action>
        <action>http://midpoint.evolveum.com/xml/ns/public/security/authorization-model-3#modify</action>
        <object>
            <orgRelation>
                <subjectRelation>org:manager</subjectRelation>
                <scope>allDescendants</scope>
                <includeReferenceOrg>true</includeReferenceOrg>
            </orgRelation>
        </object>
    </authorization>

Each tenant administrator has the right to read and modify all objects under the tenant organization (and the organization itself) of which he is manager (relationship = manager). Other organizations are not visible/editable for him.

This feature is available in midPoint 3.3.1 and midPoint 3.4.

The scenario can (and most probably soon will) be enhanced to also support:

• self-service for end users to request more roles, with approvals of administrators.
• support for creating groups in target resources as projections of midPoint roles. This will make creation of organizational units and groups fast and simple.