Organizations

Organization objects let you arrange and manage users in hierarchical trees. Organizations also let you give users fine-grained administrative privileges to various parts of the tree based on their location in that tree. For example, an administrator of one organization might have full access to the users within that organization but no access to the users in an adjacent organization.

An organization object (defined in the managed object configuration) contains a set of relationship properties that reference the parent, child, owners, admins, and members of an organization. These relationship properties enable a hierarchical organizational model.

Users and organizations have a set of relationship-derived virtual properties used by the delegated administration filters to provide the visibility and access constraints that underpin the organization model. Users have the ids of all the organizations of which they are members, and organizations have the ids of all their admin and owner users.

Only IDM administrative users can create top-level organizations. Within organizations, there are various levels of privileges, depending on how a user is related to the organization.

The following diagram gives a high-level overview of how privileges are assigned to various entities in the organization hierarchy:

An organization owner can manipulate all organizations, members, and admins in their ownership area. The ownership area includes any part of the tree in or beneath the organization that they own. So, in the preceding image, the owner of Org A can do the following anywhere within their ownership area (the pale green region):

Add and update members.

Organization owners only have access to the members in their ownership area. So, an owner can create a new user as a member of their organization, but cannot add an existing managed user to their organization if that user is outside of their ownership area (that is, in any part of the tree not in or beneath the organization that they own).

Add and update sub-organizations, such as Org B and Org C.

Give an organization member the admin privilege for the parent organization or any sub-organizations.

An organization owner cannot create additional owners in their root organization.

An organization owner does not have to be a member of the organization. If the organization owner is a member of the organization, that owner is automatically in the administrative area of any admins of that organization, and can therefore be manipulated by an organization admin. To avoid accidentally giving organization admins privileges over an organization owner, do not make the owner a member of the organization.

An organization admin has control over their administrative area. The administrative area includes any part of the tree in or beneath the organization that they administer. In the preceding diagram, the administrative area of Admin A is shaded red. The administrative areas of Admins B and C are shaded grey. An admin can do the following in their administrative area:

Add and update members.

Organization admins only have access to the members in their administrative area. So, an admin can create a new user as a member of their organization, but cannot add an existing managed user to their organization if that user is outside of their administrative area (that is, in any part of the tree not in or beneath the organization that they administer).

Add and update sub-organizations of the organization they administer.

Notice that Admin B and C are outside of the administrative area of Admin A. An organization admin cannot create additional admins in their administrative areas.

An organization admin must be a member of the organization, so must either be an existing member of the organization, or must be given the memberOfOrg relationship at the time they are created.

Organization members are regular users, with no special privileges in the organization hierarchy.

Managed users have a memberOfOrgIDs virtual property that lists the organizations to which the user belongs (either directly, or through any parent organizations).
Parent and child organizations are essentially relationships between an organization and existing organizations in the tree.

Organizations rely on the privilege mechanism. To use organizations effectively, you must therefore enable dynamic role calculation, as required by the privilege model.

This is not required if you are authenticating through AM, using the rsFilter authentication module.

Select Configure > Authentication > Session > Enable Dynamic Roles in the admin UI or set the enableDynamicRoles property to true in the sessionModule in your conf/authentication.json file:

"sessionModule" : {
    "name" : "JWT_SESSION",
    "properties" : {
        "maxTokenLifeMinutes" : 120,
        "tokenIdleTimeMinutes" : 30,
        "sessionOnly" : true,
        "isHttpOnly" : true,
        "enableDynamicRoles" : true
    }
}

For more information about dynamic role calculation, refer to Dynamic Role Calculation.

PingIDM 7.5.0

Organizations