MidPoint Organizational Structure Introduction

MidPoint has a native support for organizational structures. The organizational structure model implemented in midPoint is very flexible. Although the organizational structure model is primarily designed and optimized to support hierarchical organizational trees it is quite flexible to accommodate even other organization structure types.

Organizational structure is composed of objects called orgs (see OrgType). An org is a universal grouping mechanism. Its purpose is to group other objects and orgs. Orgs usually represent organizations, divisions, departments, sections, workgroups, projects, teams, subteams, ad-hoc groups, domains, realms or similar organizational division units. Orgs are designed to "nest" inside other orgs hence creating an organizational hierarchy. However they work equally well in a flat structure.

Figure: Simple hierarchical organizational structure

The basic features of the "org model" are:

Organizational structure is composed of org objects (OrgType). Therefore the organizational structure is created by creating appropriate org objects and linking them into a structure by using parentOrgRef references. Part of an organizational structure is illustrated in the following diagram.

Figure: Linking org objects using parentOrgRef references.

The org objects have a slightly different use of common object attributes than other objects. This is motivated by a sensitive nature of organizational structure when it comes to changes in the objects. Change in a single user object usually only affects only a very small portion of a user base (single user). E.g. if a user record is deleted and re-created the collateral damage is usually small. While change in a single org object may affect significant portions of user base (entire departments, divisions or organizations). If a single organizational unit is deleted and re-created there may be too many users that are affected and the total damage may be more than significant. This is usually not an issue if the organizational structure is managed manually inside midPoint. However the organizational structure is frequently synchronized from external sources such as HR database or project management systems. Changes in organizational structure are common and usually include renames and moves of organizational units. If the synchronization is automatic it is essential that the synchronization process does as little damage as possible. E.g. renaming organizational unit is quite a simple operation. However if the rename is processed as delete of org with an old name and create of org with a new name it may cause a lot of churn in the user base.

The important properties of org objects are described in the following table:

It is essential to rely on immutable identifiers when synchronizing organizational structure. Uncontrolled changes in organizational structure affects many users. Therefore it is recommended to use the combimation of identifier and orgType as primary composite identifier of organizational unit for the purposes of synchronization. If this identifier changes then we can assume that the old organizational unit is gone and new unit is created even if the displayName is the same. But even more importantly: we can correctly detect renames. If only the name of the unit changes that only a displayName property needs to be updated and the rest of the org object remains the same. It is not deleted and re-created and therefore also OID remanins the same. Users (and other objects) are linked to the org using OID-based references therefore the membership is correctly maintained.

Organizational structure is linked together using parentOrgRef references. Vast majority of midPoint components will look at these references only when working with organizational structure, displaying it, etc. The references are internally backed by indexing structures that make it very efficient to suppport tree-like structures - which is something that relational databases are not usually built for. But there is price to pay for this efficiency. The parentOrgRef references are very simple and quite static. There is no (direct) way how to specify conditional or temporary membership in an org just by using parentOrgRef. Doing so would complicate the system to the point that it would no longer be efficient or maintainable. But conditional and temporary membership is something for which assignments were designed. Therefore the plain organizational structure is combined with assignments to get the benefits of both mechanisms.

Organizational structure is usually related to the role structure (RBAC). E.g. it is usual that all users belonging to a specific department have the same role. MidPoint makes this arrangement easy to implement by a simple mechanism: every org is also a role at the same time. This may be quite unusual and it may take some time to fully understand but it is a powerful mechanism. Most of the orgs do not have any inducements therefore they are considered empty roles and nothing special happens. But it all gets much more interesting if an org has an inducement. If a user is assigned to such org the org behaves as a role and automatically computes and executes all the construction element that the inducement leads to.