Using Persona Workflows to manage PingOne users, groups & populations

Overview

PingOne is the cloud identity platform from Ping Identity. It gives a user directory, single sign-on, and multi-factor authentication for workforce and customer identities. The Persona PingOne integration connects to the Platform API of your PingOne environment. You can then find and manage users, groups, and populations directly from Persona Workflows.

This integration helps IT, Compliance, and People Ops teams manage the employee account lifecycle in Persona. They can find profiles, update attributes, manage group membership, and disable access during an investigation.

Benefits

Unified User Management: Find, create, update, and delete PingOne users directly from Persona Workflows. All identity operations stay in one location.

Faster Investigations: Disable the access of a user immediately during an investigation. When the investigation is complete, enable it again. You do not have to leave Persona.

Group & Population Visibility: Read the group memberships of a user, add or remove the user from groups, and list groups and populations. This gives you more data for account decisions.

Integration Features

The Persona PingOne integration supports 12 operations across three resource types in the PingOne Platform API:

• User management: List, create, read, update, and delete users. Read and set the enabled state of a user.
• Group management: List the group memberships of a user, add or remove a user from a group, and list groups in the environment.
• Population management: List populations. A population is the PingOne term for a defined segment of users in an environment.

Setting up the PingOne integration

Prerequisites

To set up the PingOne integration, make sure that you have:

• Admin access to a PingOne environment.
• Permission to create a Worker application and assign roles in that environment.

Setting up the PingOne credentials (PingOne side)

Persona uses a Worker application with the OAuth2 client credentials grant to authenticate to the PingOne Platform API. PingOne supports two Token Endpoint Authentication Methods for this credential type: Client Secret Post and Client Secret Basic. To select one, read the FAQs.

Setting up the PingOne credentials (Persona side)

Using the PingOne integration in a Workflow

PingOne Operations Overview

Below is a full list of the Workflow Action steps and configurations for the PingOne integration, in groups by resource type.

Users

List users

Lists the users in a PingOne environment. You can filter the users with a SCIM search expression. The step returns results one page at a time.

Configuration Steps:

• Optionally add:
  • Filter: SCIM search expression that limits the users that the step returns, for example email eq "person@example.com". The supported operators are eq (equals), sw (starts with), ew (ends with), and co (contains). You can combine them with and/or. You can filter on these attributes: username, email, external ID, family name, given name, mobile phone, and population.
  • Page Size: Maximum number of users to return in one page (1–200).
  • Page Cursor: Cursor that identifies the next page of results. Get it from the next link of a previous response.

Create user

Creates a user in a PingOne environment. If you do not give a population, the step adds the user to the default population of the environment.

Configuration Steps:

• Provide values for required fields:
  • Username: Must be unique in the environment. It is not case sensitive.
• Optionally add:
  • Email, Email Verified, Name (First/Middle/Last/Formatted/Honorific Prefix/Honorific Suffix), Address, Primary Phone, Mobile Phone, Nickname, Title, User Type, External ID, Locale, Preferred Language, Time Zone, Photo Address, Multi-Factor Authentication Enabled, Identity Provider ID, Population ID (required when the environment has no default population), and Initial Status (Active or Verification Required, with an option to suppress the verification email).

Read user

Gets one user from a PingOne environment with their identifier.

Configuration Steps:

• Provide values for required fields:
  • User ID: Identifier of the user to retrieve.
• Optionally add:
  • Include: Return more group membership details with the user (Group IDs or Group Names).

Update user

Updates selected attributes of a user. The step changes only the attributes that you give. The other attributes keep their current values. To enable or disable the user, use the Set user enabled state operation.

Configuration Steps:

• Provide values for required fields:
  • User ID: Identifier of the user to update.
• Optionally add:
  • Any of the attributes available on Create user (Username, Email, Name, Address, etc.) to change them.

Delete user

Deletes a user from a PingOne environment.

Configuration Steps:

• Provide values for required fields:
  • User ID: Identifier of the user to delete.

Read user enabled state

Tells if a user can authenticate at this time.

Configuration Steps:

• Provide values for required fields:
  • User ID: Identifier of the user to check.

Set user enabled state

Enables or disables a user. A disabled user keeps their account and group memberships, but cannot authenticate. Use this step to disable the access of a user during an investigation and to restore it after. It is similar to the Okta Suspend/Unsuspend actions.

Configuration Steps:

• Provide values for required fields:
  • User ID: Identifier of the user to enable or disable.
  • Enabled: Set to true to allow the user to authenticate, or false to block them.

Groups

List group memberships for user

Lists the groups of a user. Each membership tells if it was assigned directly or inherited through a nested group or the user filter of a group.

Configuration Steps:

• Provide values for required fields:
  • User ID: Identifier of the user whose group memberships are listed.
• Optionally add:
  • Expand: Return the full details of each group with the membership.
  • Page Size / Page Cursor: Control pagination of results.

Add user to group

Adds a user directly to a group. Administrators cannot add or remove themselves from a group that has administrator roles.

Configuration Steps:

• Provide values for required fields:
  • User ID: Identifier of the user to add to the group.
  • Group ID: Identifier of the group to add the user to.

Remove user from group

Removes a group membership that was assigned directly. You cannot use this step to remove memberships that are inherited from a nested group or from the user filter of a group. These memberships end when the group configuration stops applying to the user.

Configuration Steps:

• Provide values for required fields:
  • User ID: Identifier of the user to remove from the group.
  • Group ID: Identifier of the group to remove the user from.

List groups

Lists the groups in a PingOne environment. You can filter the groups with a SCIM search expression on group name, display name, external identifier, or population.

Configuration Steps:

• Optionally add:
  • Filter: SCIM search expression, for example name eq "Verified Employees" or name sw "Contractor".
  • Page Size: Maximum number of groups to return in one page (1–1000).
  • Page Cursor: Cursor identifying the next page of results.

Populations

List populations

Lists the populations in a PingOne environment. Populations put users into groups, so that you can apply password policies and themes to them. If the environment has no default population, you need a population identifier to create a user. For more information about populations, read the FAQs.

Configuration Steps:

• Optionally add:
  • Filter: SCIM search expression. Only two filters are supported: an identifier with eq, or a name with sw (starts with). For example, name sw "Employees".
  • Page Size: Maximum number of populations to return in one page. The default is 250.
  • Page Cursor: Cursor identifying the next page of results.

FAQs

Should I use Client Secret Post or Client Secret Basic?

Both are standard OAuth2 client credentials authentication methods for a PingOne Worker application. In the Persona integration, they give the same capabilities. Persona shows Client Secret Post first, because the Ping Identity setup guidance for worker applications recommends it for client-credentials use cases like this one. But Client Secret Basic works equally well. Use the method that is the standard of your systems or security team for client-credential authentication.

What is a “population” in PingOne?

A population is the PingOne term for a defined segment of users in an environment. You use it to apply password policies and branding/themes to a subset of users. Each user is in exactly one population. If an environment has no default population, you must give a population ID when you create a user.

What role does the PingOne Worker application need?

The Worker application needs an Identity Data Admin role. The scope of the role must be the environment of the application. PingOne returns a 403 error, not a clearer authentication failure, in these conditions: the role is missing, the role has the wrong environment scope, or the application is disabled. Thus, if operations fail unexpectedly, first check the role assignment, environment scope, and enabled state of the application.

Plans Explained

PingOne Integration by plan

Learn more about pricing and plans.