Understanding the Org Model

PingOne Advanced Identity Cloud (AIC) and PingIDM (Ping’s self-managed Identity Management) provide a powerful model called Organizations which enables out-of-the-box extensible, inherited relationships between users and associated groups of users. In short, Organizations give you the ability to match your IAM strategy to your business strategy, and not the other way around - they are a means to unify, simplify, and standardize your process across your internal, external, and partner identities.

Considering its flexibility and scalability, starting with an empty tenant and the base Organization model can feel a bit daunting.

This Guide intends to teach you the key information you need to know when interacting with AIC/PingIDM’s Organization model. It is split into the following sections:

By the end of this Guide you’ll have a medium-level understanding of Organizations and how they operate generically within AIC and PingIDM.

This Guide expects a beginner level of familiarity with AIC or PingIDM. Certain topics covered here will be specific to the AIC platform: when this happens, we’ll call it out. If you do have a tenant or deployment available, feel free to follow along however it is not necessary.

Before we define Organizations, we need to understand the underlying infrastructure that surrounds it. Let’s start broadly and then narrow down as we go.

The Organization model is a part of Identity Management (IDM). PingIDM is the self-deployed instance and is a core feature set within AIC. Identity Management’s job is to represent, control, connect, and map identity data in and out of the Ping platform. Regarding Organizations, we care most about representing and controlling its data - what does the template look like, and ensuring that the data within it is managed appropriately (think CRUDPAQ - Create, Read, Update, Delete, Patch, Action, Query).

Managed Objects are a templatized instance of data in IDM that contains Properties. In essence, they are the representation of identities within IDM. By default, your instance comes with Users, Roles, Assignments, Groups, and Organizations, but you can create as many as you’d like. Managed Objects store data within a Directory, with each Managed Object being categorized separately.

Properties (sometimes called Attributes) are the individual data fields within a Managed Object that represent the data types stored within that object. They define the specific pieces of information each instance of that Managed Object will hold. As an example, a User is a Managed Object, and their Username is one of their Properties. Properties can be booleans, numbers, arrays (called multivalues), objects (including nested objects), strings, Relationships, and Virtual Properties. You can also create custom types as needed. Properties have their own unique indexinghttps://gwizkid.com/posts/understanding-the-org-model-aic/#fn:1[1], validation, hashing or encryption, and triggers which can be performed on actions such as validating, retrieving, or storing an instance of this Property.

Relationships are a type of Property that creates a linkage between instances of Managed Objects. Relationships can be one-to-one, one-to-many, many-to-one, and many-to-many, and can be linked to different Managed Objects or the same Managed Object. Common examples of relationships include Manager to Employees, Parent to Children, or Department to Teams. Relationships can contain their own data within the link itself, can return their data alongside either end of the link in a query, and can be used as a means to notify the connected Managed Objects that changes have occurred on opposite ends of the link (Relationship-Derived Virtual Property).

Virtual Properties are a powerful Property type that can dynamically calculate its own data on the fly, either on time of retrieval or based on notifications received from a Relationship tied to this Managed Object (Relationship-Derived Virtual Property). This significantly simplifies data and queries as well as improves performance because the complex calculations are handled for you dynamically at run time or statically at storage time - for example, you could have a virtual property that dynamically returns the “Full Name” of a User as a combination of their First and Last name without actually having to store and update that value separately.

Relationship-Derived Virtual Properties (RDVPs) are a type of Virtual Property that update based on notifications from the Relationships linked to its Managed Object. An RDVP has access to content from the Object’s Relationships and can travel the chain of relationships to create a composite value of the chain. Relationships and RDVPs are the two components of IDM that make Organizations so flexible and capable.

Organizations are a Managed Object that contain multiple Relationships both to Users and to other Organizations. These Relationships store RDVPs that define the linkages that the Organization has with other Organizations and Users. Since Organizations are a Managed Object, they are adherent to the same scale as Users, meaning that AIC is rated for hundreds of millions of Organizations while PingIDM is hypothetically as scalable as your hardware will allow.

Organizations, at their core, build a hierarchy of templatized data. Due to the Relationships between Organizations and Users, this data can be inherited up and down the hierarchy.

Visualized, the Organization model often looks like a tree.

Organizations enable hierarchical, inherited data templates, allowing you to standardize and represent complex structures such as families, business partnerships, and supplier/distributor models.

But just having this data is only one part of what makes this model special. Organizations don’t just represent Parent/Child relationships between other Organizations: they also by default contain 3 different Relationship types with Users - and Users can retrieve and inherit information from the hierarchy as well. Due to the RDVPs already on the Organization, and the permission model in place on the Organization, elevated Relationship types (i.e. Owners and Admins) have the ability to manage aspects of both the Organization, its related Users, and any Organizations and Users that they’ve inherited - both via REST API and (in the case of AIC) hosted UI.

The Organization Model with Users

Organizations enable hierarchical, inherited delegated administration, allowing you to scale administration alongside your platform by delegating operational management of the hierarchy and its Users to the Users within the Organization (or its Parent).

Additionally, these Relationship types are many to many, meaning that a single User can be a Member, Admin, and Owner of as many different Organizations and Hierarchies as they need.

Universal Identity in Organizations

So, why Organizations?

Organizations let you:

So let’s put this all together and see how the Organization Model works in practice. Note that the platform screens shown below are taken from the built-in Hosted Pages within AIC, however each and every action is available in PingIDM via the Native UI or REST API.

Our goal today will be to create a basic business hierarchy. We’ll take the Supplier/Distributor model for this example.

__

Supplier/Distributor Example

In our example we have a Manufacturing vertical named BX Manufacturing.

BX Manufacturing has partnerships with Suppliers, who provide goods and services, and Distributors, who purchase BX Manufacturing’s products to then be sold elsewhere. Both Suppliers and Distributors need to give their employees access to BX Manufacturing’s systems but what they ultimately do with those systems is very different.

To start, let’s create the Root Organization. As the Tenant Admin, we can select “New Organization”, enter in the Name, and then we’re ready to go.

__

Creating the Root Organization

Now, an Organization is only as useful as its Relationships. With that in mind, let’s assign an Owner to this Organization so that we can delegate management of the Manufacturing Vertical and its subdivisions.

Underneath the “Owner” section, we can assign a User to our Organization. In my example, the user “Owner” has already been registered. Note that while we are assigning manually here, you can always automate this assignment during provisioning, user registration (likely via a Journey/Tree in AIC/PingAM), or (if you have Governance features in your AIC tenant) during Access Request or with a Form submission that triggers a Workflow or Approval.

__

Assigning the Owner

Let’s log in as the Owner User. You’ll find that you have access to update and delete BX Manufacturing and its users and can create new Organizations underneath the Organization you’re an Owner of.

__

Default Owner Permissions

While you have very similar capabilities to the Tenant Administrator by default, you won’t have access to manage other Owners - that’s the job of the Tenant Administrator.

__

Default Owner Permissions - No Owner Management

Since we’ve been delegated ownership of BX Manufacturing, let’s set up the Suppliers and Distributors suborganizations and assign some people to manage them. We’ll create a new Organization and assign that Organization to BX Manufacturing as a Parent.

__

Creating the Sub-Organizations (Children)

We’ll repeat the same action for the Distributors Organization.

__

Creating the First-Level Children

Currently, our Organizations don’t have any Users in them. Let’s fix that. As an Owner, we can create a new User and assign them as a Member and/or an Administrator to any and all Organizations that we own and have inherited ownership to.

__

Creating the Suppliers Administrator

If we log out as an Owner, and log in as the Suppliers Admin (and if using a password login, make sure to set their password!), we’ll see that we only have access to the Organization that we were assigned, and unlike the Owner can’t manage other Administrators of our Organization(s).

__

Default Administrator Permissions

We can, however, manage our Users and create and manage new Organizations. Let’s create Supplier A and Supplier B now as children of Suppliers.

__

Creating the Suppliers

Additionally, let’s create some Users who are Members of the different Suppliers.

__

Assigning Members

Log back in as the Owner. You’ll see that you have inherited permissions to the Suppliers and the Users made by your delegated Administrator.

__

Inheritance at Work

Owners and Admins inherit permission to all of their sub-Organizations and its Users. Members inherit context from all of their Parent Organizations. Owners and Admins permission goes down the tree, Members context goes up.

We mentioned before that Users can have more than one Relationship to one or more Organization(s). Let’s say, for example, that Supplier B interacts with Distributor A to sell OEM add-ons to a customer, like a spoiler on a car. Since BX Manufacturing is the creator and owner of the finished product, they must be intrinsically involved in the linkage between this Supplier and Distributor. Here we’re dealing with a B2B2C scenario, or Business-to-Business-to-Consumer.

Unified Identity

In this situation, our User is an Admin to Supplier B and is also a Member to Distributor A. At the end of the day, this is the same person with the same account and the same login but with different relationships to each Organization. One person is tied to a single identity, but the Relationships that they have to the Organizations give them different permissions to Organizations and Users and give others different permissions to them.

In practice, as the user Supplier B Admin I can see Supplier B and the Members associated with Supplier B. As Distributor A Admin, I can see and manage Supplier B Admin because they’re a Member of my Organization.

My Supplier received the context they needed to interact with Distributor while still being able to manage their own Users and Supplier information. My Distributor cannot receive the context of the Supplier but can manage the suppliers associated with their Organization.

__

B2B2C Using Organizations

Advanced Identity Cloud takes the Organization Model one step further and incorporates it throughout its platform. That way, actions and interactions can reference the context and relationships to make unique experiences and define specific permissions defined by each individual user.

To start, the openidm binding allows you to access and manage any IDM data throughout AIC. This gives you the flexibility to interact with your Organization throughout the User journey, for example:

To give you a sense of what actions are useful in the context of Organizations, take a look at this Library Script that you can use wherever Next-Gen scripting is available.

If you have Governance enabled within your AIC Tenant, Organizations appear in the following places:

Just like with the rest of the platform, you can utilize the same bindings to interact with the Organization in actions such as Workflows.

So where do we go from here?

Organizations give us a template with pre-built relationships that can be referenced throughout Ping’s platform. And that’s just it: it’s a template upon which we can extend and expand to meet the needs of our organization.

As a start, add Properties to your Organization - things you see your business units and partnerships doing over and over again that could (and should) be standardized.

Once you’ve built that model the way you like it, connect the model to your platform. It could be a way to control branding, extended support capabilities, or something completely different - work with your stakeholders to decide what is important for them and their users to have and to manage.

When you’ve got the model in a place you like, delegate administration to the capabilities you’d like to share with your partnerships. You own the model, and you delegate the controls.

If you see that the parent organizations need more control than the children, consider applying inheritance rules.

And, as you expand, keep changing it! The beauty of this template is that it grows with you: you can enable the right experience, security, lifecycle, and overall IAM strategy for each and every use case without having to rebuild your entire platform every time a new business requirement comes along.

Through this Guide we have:

The Organization model provides you the bricks to build dynamic, magical experiences for your Administrators and your Users. And with this foundation the only limit you have is your imagination.