Delegated Administration, another B2B use case

10 min readJun 4, 2024

In the B2B IAM landscape, we’re witnessing an increasing number of clients seeking delegated administration. When providing services to companies, the notion is to enable your customers — the corporations — to directly manage their team members within your system. Let’s do that with PingOne Advance Identity Cloud (P1AIC)!

The Use case

Imagine I’m Securus, an insurance company for both individuals and businesses. While I offer life insurance, I also provide auto and office insurance, catering to two distinct clienteles: individuals seeking life coverage and companies in need of office insurance. Now, envision I’m Vector, a transportation firm. As a Securus client, Vector holds a comprehensive insurance contract covering all its trucks.

Vector is registered in Securus’ systems as a client, and some of its employees require access to our systems. It’s imperative that Vector employees access only what’s permitted — no more, no less. For instance, Vector insists that its drivers access their truck insurance without access to other Securus policies.

As such, each Vector user must possess their own account with tailored access rights, authenticated by name — generic access to Securus systems is strictly prohibited. Consequently, whenever a new employee joins Vector, Securus must register them in our system and configure their access rights to ensure they access only what’s necessary.

This is where Delegated Admin steps in: Securus intends to delegate administrative tasks to Vector, enabling them to manage their team’s access rights and perform create/read/update/delete (CRUD) operations on user accounts.

With Ping Identity Platform, Securus will use Organizational objects to represent customer companies like Vector, and will use relationships for Delegate Administration rights.

In this blog post, we’ll explore how to configure and use various admin rights: Full admin access, HR admin rights for employee management, Accountant admin rights for updating company information, and Truck drivers admin rights for accessing specific truck insurance policies. The diagram below illustrates this scenario.

Our approach in the platform

The Ping Identity platform already include an Organizational object to managed delegated Admin. We will use this mechanism for Full Admin and we will extend the Organizational object schema to add HR, Accountant and Truck driver links and admin rights. The following schema shows the Organizational and user objects relationships (extract from the object schemas) we will implement in this blog.

Note: PingOne Advance Identity Platform is evolving really fast and many new features are added frequently. What I explain here may be incorporated in new releases in the future.

How to do it ?

Update the schemas

In the Identity Platform it’s possible to extend your data model as explained in this page. You can:

Add new managed object types.
Specify default values for object properties
Derive object property values from other object property values, known as virtual properties.
Define custom relationships between managed objects.

We will extend our Organization and User schemas to store HRs, Accountants and Drivers links with there Organization.

Note: Org Admin, and Org Owners are existing by default in the platform; the delegated administration is already working for Admin and Owners; we don’t need to configure anything for these profiles.

Add custom_hrs, custom_accountants, and custom_drivers attributes on Organization object schema and custom_hrOfOrg, custom_accountantOfOrg, and custom_driverOfOrg attributes on User object schema.

We’ll use the native Identity Management console to add theses attributes to store the link information (both ways Organization <-> User).

With your browser, connect to your platform UI https://<YOUR TENANT>/platform (where <YOUR TENANT> is equal to your platform server) as an administrator, and browse to “Natives Consoles > Identity Management” Menu. It should open a new window.
In this new window, browse to “Configure > Managed Objects”. On this page click on “Alpha_organization”.
Click on “Add a Property”, name this property custom_hrs, with a label HRs and type Relationship, and click “Next”.
In the new popup select “alpha_user” as a resource, in DISPLAY PROPERTY field select Username and click “Save”.
In the custom_hrs attribute configuration page (Details tab), in the section “Relationship Configuration”, click on the arrow from Alpha_organization to Alpha_user and select “Has many”.
In the same page, same section click on the arrow from Alpha_user to Alpha_organization and select “Has many”.
In the new popup enter custom_hrOfOrg in “Reverse property name”, in DISPLAY PROPERTIES field select Name and click “Save”.
Scroll down an click on “Save”.
Repeat these operations for custom_accountants attribute with these values:
NAME: custom_accountants,
LABEL: Accountants,
TYPE: Relationship,
REVERSE PROPERTY NAME: custom_accountantOfOrg.
Repeat these operations for custom_drivers attribute with these values:
NAME: custom_drivers,
LABEL: Drivers,
TYPE: Relationship,
REVERSE PROPERTY NAME: custom_driverOfOrg.
Finally, browse to Configure > Managed Objects. On this page click on “Alpha_user”.
Click on custom_hrOfOrg property and then in the READABLE TITLE field, enter “Organisations for which I am HR” and click “Save”.
Repeat these operations for custom_accountantOfOrg, with this value READABLE TITLE: Organisations for which I am accountant.
Repeat these operations for custom_driverOfOrg, with this value
READABLE TITLE: Organisations for which I am driver.

The following figures show the Organization object and User object with the relationships.

Organization Schema updated with relationships

Now if you connect the Identity Platform UI,browse to the Identities>Manage section and edit an Organization, you’ll see 3 new tabs (HRs, Accountant & Drivers) in the interface ready to be used. You can add HRs Accountnants and Drivers to this Organization.

An Organization with HRs, Accountants, & Drivers new tabs

Add custom_hrIDs, custom_parentHrIDs and custom_accountantIDs, custom_parentAccountantIDs RelationShip Derived Virtual Properties on Organization object schema.

After creating the relationship between Org and user objects, we need utilities attributes to store the IDs of the HRs or the Accountants directly on the Org objects. These attributes (custom_hrIDs and custom_accountantIDs) will be virtual which means dynamically calculated based on the relationship attributes we created previously (custom_hrs and custom_accountants). These special attributs are called RelationShip Derived Virtual Properties (RDVP) in the Identity Platform.

To have an heritage mechanism (HR of parents Org can manage childs Orgs) we will also add custom_parentHrIDs and custom_parentAccountantIDs RDVP to store the IDs of HRs and Accountants from the parent Organizations.

With your browser, connect to your platform UI https://<YOUR TENANT>/platform (where <YOUR TENANT> is equal to your platform server) as an administrator, and browse to Natives Consoles > Identity Management Menu. It should open a new window.
In this new window, browse to Configure > Managed Objects. On this page click on “Alpha_organization”.
Click on “Add a Property”, name this property custom_hrIDs, and type Array, and click “Save”.
Then click on the property and in the “Details” tab click on “Show advanced options” link,
Scroll down, select “Virtual” and “Return bu Default” and click “Save”,
Click on “Query Configuration” tab, enter [“custom_hrs”] in REFERENCED RELATIONSHIP FIELDS and _id in REFERENCED OBJECTS Fields. Activate “Flatten Properties” and click “Save”,
Repeat these operations for custom_parentHrIDs attribute with these values:
NAME: custom_parentHrIDs,
TYPE: Array,
QUERY CONFIGURATION: [“custom_hrs”],
REFERENCED RELATIONSHIP FIELDS: custom_hrIDs,custom_parentHrIDs,
Repeat these operations for custom_accountantIDs attribute with these values:
NAME: custom_accountantIDs,
TYPE: Array,
QUERY CONFIGURATION: [“custom_accountants”],
REFERENCED RELATIONSHIP FIELDS: _id,
Repeat these operations for custom_parentAccountantIDs attribute with these values:
NAME: custom_parentAccountantIDs,
TYPE: Array,
QUERY CONFIGURATION: [“custom_accountants”],
REFERENCED RELATIONSHIP FIELDS: custom_accountantsIDs,custom_parentAccountantsIDs.

Add custom_hrIDs Properties on User object schema.

Lastly to make it easier to know which HR can manage a user we will create another RDVP. Follow the same step as for the previous RDVP but this time on alpha_users with the following parameters:
NAME: custom_myHrIDs,
TYPE: Array,
VIRTUAL: true,
RETURN BY DEFAULT: true,
QUERY CONFIGURATION: [“memberOfOrg”],
REFERENCED RELATIONSHIP FIELDS: custom_hrIDs,custom_parentHrIDs.

The figure below shows an example of a user which is belonging to an Organization which is the chld of another. Both os these Organizations have HRs, so we see the IDs of the HRs from these two Organizations.

That’s it, now Organization and User Schemas are ready. Let’s configure the access rights.

Note: All these operation can be done using command-line or REST interface to load the configuration file managed.json. You can access mine here : https://gist.github.com/sorluc/3753cbd5c32d753652090f23e205762a

Create Authorization roles

To manage access right in the Identity Platform, we use Authorization roles/Internal roles (Authz role). You can create as many Authz roles as you need and you can fine tune it:

Access Rights: you can define on which object and which attribute of this object the members of this role will be allowed to operate. For instance, you’ll be allowed to operate on password attributes of users. You can also create dynamic rules (similar to LDAP filters) to define the objects on which the role gives you access.
Role Assignment: you can assign manually the roles but you can also define dynamic rules (similar to LDAP filters) to automatically assign the role to someone.

We will create two Authz roles to give administration right: one for the HRs and the other for Accountants. with these roles they’ll be allowed to manage the Orgs for which they are HRs or Accountant. Drivers don’t need specific Authz role because they won’t have specific rights on the delegated admin interface; they’ll be added as Drivers in the platform.

Note: Org Admin, and Org Owners are existing by default in the platform; the delegated administration is already working; we don’t need to configure anything.

Create HRs and Accountants Authorization roles

With your browser, connect to your platform UI https://<YOUR TENANT>/platform (where <YOUR TENANT> is equal to your platform server) as an administrator, and browse to “Identities > Manage Menu”. Click on “Internal Roles” tab.
Click on “New Internal role”, enter HRs in the NAME field, Role used for HRs delegated admin in the DESCRIPTION field and click “Next”.
In the page “Internal role Permissions”, select Alpha realm — Organizations and click “+ Add”.
Click on “Show advanced”, activate “Administer only a subset of Alpha realm — Organizations by applying a filter”, click on “Advanced Editor”, enter (/custom_hrIDs co "{{_id}}" or /custom_parentHrIDs co "{{_id}}").
In the same page, select Alpha realm —Users and click “+ Add”, and check “Update” option.
Click on “Show advanced”, activate “Administer only a subset of Alpha realm — Organizations by applying a filter”, click on “Advanced Editor”, enter /custom_myHrIDs co "{{_id}}", and click “Next”.
In the page “Dynamic Internal role Assignment”, activate “A conditional filter for this ”, click on “Advanced Editor”, enter /custom_hrOfOrg pr, and click “Next”. Finally click “Save”.
Repeat these operations for Accountants Authz role with these values:
NAME: Accountants,
DESCRIPTION: Role used for Accountants delegated Admin,
INTERNAL ROLE PERMISSIONS: Alpha realm — Organizations / View
ORGANIZATION SUBSET FILTER: /custom_accountantIDs co "{{_id}}" or /custom_parentAccountantIDs co "{{_id}}",
DYNAMIC INTERNAL ROLE ASSIGNMENT: /custom_accountantOfOrg pr.

The following figure shows the result with HRs and Accoutnants Authz Roles creted in the platform.

Authz role interface with Accountants and HRs roles

Create a Provisioning role for Drivers

To give access to applications protected by the Identity Platform, we use Provisioning Roles/Internal Roles (Role). You can create as many Roles as you need and you can fine tune it:

Provisioning: It’s possible to associate your role with Applications and Application’s assignments. Doing this you’ll be able to automatically provisioning the user account with the associated assignment (groups, role, profile, …) in the connected Applications.
Role Assignment: you can assign manually the roles but you can also define dynamic rules (similar to LDAP filters) to automatically assign the role to someone.

Note: being a member of a role can also be used to calculate SAML Response content and OAuth/OIDC scopes and claims.

In this blog, we will create one role automatically assigned to the Drivers but we won’t explain how to how to use it to provision an account in an application and neither how to use it in SAML and OAuth/OIDC.

Create Drivers Provisioning role

With your browser, connect to your platform UI https://<YOUR TENANT>/platform (where <YOUR TENANT> is equal to your platform server) as an administrator, and browse to “Identities > Manage Menu”. Click on “Alpha realm — Roles” tab.
Click on “New Alpha realm — Role”, enter Drivers in the NAME field, Role for Drivers in the DESCRIPTION field and click “Next”.
In the page “Dynamic Internal role Assignment”, activate “A conditional filter for this ”, click on “Advanced Editor”, enter /custom_driverOfOrg pr, and click “Next”.
In the next page, click “Save”.

The figure below shows a user profile with has been dynamically assigned to the Provisioning role Drivers because she is driver of a Demo Organization.

A Driver automatically assigned to a role

Now let’s see it in action.

Demonstration

The following video shows an HR accessing the self-service/delegated adminisistration interface. He has access to all the Organizations and their members.

HR access to Self-service/Delegated admin UI

The gif below present an Accountant accessing the self-service/delegated admin interface; he can see the Organization for which he is Accountant.

Accountant access to Self-service/Delegated admin UI

The next animation is a Driver accessing the Self-service/Delegated Admin interface. He can only use the self-service functionalities.

Driver access to Self-service/Delegated admin UI

Conclusion

With this blog we’ve seen in action many different concepts of the Ping Identity Platform: Schema extension, RelationShip Derived Virtual Properties (RDVP), Authorization roles/Internal roles, Provisioning Roles/Internal Roles and the use of the Self-service/Delegated Admin UI.

These lesser-known features play a crucial role in rendering the identity platform exceptionally powerful and adaptable to various contexts. I strongly urge you to utilize them!