PingOne for Customers: Controlling Access via Roles

Unless you want to provide everyone in your organization with unfettered access to PingOne for Customers (and I can immediately think of a dozen reasons why that would be a bad idea!), you’ll likely want to establish permissions that determine who can do what. Granting permissions to users and applications enables you to ensure appropriate controls and collaboration while balancing security needs. 

But how should you best go about assigning these permissions? One approach could be to separately dole out specific permissions to each user. This would enable you to fine-tune the exact actions an individual would be allowed to take, and ensure that a user could read, change or delete only what they need to. Depending upon the size and makeup of your organization, however, the process of setting up those permissions one by one could be tedious, complicated and ultimately unmanageable.

In many cases, a better method is to employ roles. PingOne for Customers includes user (and app) roles that govern the ability to perform actions with regard to the software, and the use of roles allows you to efficiently manage permission settings throughout your organization.

At their most basic level, roles are collections of responsibilities, abilities, allowable actions and powers. You’re familiar with the use of roles in much of the software you use in your daily work life, which may categorize users into groups such as general users, admins, superadmins, lord of developers and so on.  

In PingOne for Customers, it has been set up so that every role is associated with certain resources, and those resources belong to or are tied to a specific structural component in the PingOne for Customers ecosystem. Before we take a look at each role, let’s go over a quick rundown of the hierarchy of structural components from top to bottom:

1. Organization. The top level, often the company itself or some large initiative completely isolated from another one.

2. Environment. An isolated part of your company or working space, whatever the organization level is. An environment could be a dev, stage or prod environment, or it could be a slice of the organization defined by whether it’s composed of customers or employees.

3. Population. A collection of identities. A population belongs to a particular environment.

4. Identities and Apps. Either users or apps that act on behalf of a user.

How roles work within this structural system is that if the role’s level is at the same level in the hierarchy as the structural component, it gets access to create and modify the resources that belong to that component. So, for example, if a role is tied to an organization, that role access to the organization’s license and has the ability to modify it. Or, if a role is tied to an environment, that role has access to the password policies that belong to that environment and can modify them.

PingOne for Customers Roles has four roles. I’ve included the highlights for each role below, and while these aren’t the only abilities associated with each role, they typically help you determine which role or roles should be assigned to an individual.

1. The Organization Admin. This powerful role oversees the entire organization, and its main ability is having access to organization resources. A user with this role can read and update licenses, for example, or they can also create, delete and update environments.

2. The Environment Admin. The environment admin oversees one or more environments. While not as powerful as the organization admin, the environment admin exerts control over resources at the environment level, such as populations, password policies, notifications and emails, branding and app role assignments.

3. The Identity Data Admin. This role bestows the ability to create, modify and verify users. Key actions revolve around passwords, such as reading a user’s password state or setting, recovering, validating, resetting or unlocking a user’s password. 

4. The Client Application Developer. Last but not least, the client application developer can manage an application’s settings. This role can retrieve or reset an app secret, as well as create and modify resources.

One important thing to keep in mind when assigning roles is that they are not boundless; roles can be scoped to certain components in order to restrict access only to the components needed. For example, if you have multiple environments in your PingOne for Customers instance, you can assign the environment admin role abilities over a single environment and not others. Or, the identity data admin may have responsibilities in some environments but not others.

What’s so Cool about Roles?

One of the great things about roles is that we at Ping did a lot of the hard work in creating a customizable permissions set. We made some logical collections to allow you to quickly assign someone a role and get them access to only the right things. 

Do you have someone with a larger view of the overall company or organization? You can give them the Organization Admin role, and they’ll be able to change or upgrade licenses and promote or demote certain environments. Or, if you have someone responsible for a certain segment of your company like QA, Production Environment or North America Lead, you can allow them to take control of some kind of environment by giving them the Environment role.  They’ll be able to do things like set the default password policy, create populations and give permissions to certain apps.

Going down the list, for individuals dealing with users or identities behind the scenes, you can assign them the Identity Data Admin role. They’ll be able to reset user passwords, create users and modify user attributes. And a developer working on integrating identity into their apps has their work streamlined when you give them the Client Application Developer role, which allows them to start testing out the PingOne for Customers integration into that app.

Roles are easy to apply and experiment with and there’s a list of permissions you can always reference within the admin console and in our API docs. Come try it out with a free trial of PingOne for Customers.