PingOne Platform APIs

Users

A user is any end-user of the applications and services provided by the PingOne platform. Workforce users, customers, and admins are all user types. Each user is a resource with a unique identity that interacts with the applications and services in your PingOne environment.

Every user is associated with a PingOne environment and a user population.

The Users service lets you create, read, update, and delete user resources. You can manage user group membership, passwords, admin roles, and manage associations with external identity providers (IdPs).

  • For more information about user management, refer to Users in the PingOne Admin Guide.

  • Managing user accounts

    The base endpoint, /environment/{{envID}}/users, enables directory operations to create and manage user accounts, including assigning the user to a population, assigning user roles, and unlocking a user account. It also supports an import capability that gives privileged applications the ability to create a new user and set the user’s password.

    For more information, see:

  • Password management

    The password management endpoints provide functions to set, update, unlock, and recover a user’s password.

    For more information, refer to User Passwords.

  • MFA device management

    The multi-factor authentication (MFA) device endpoints enable the user’s MFA capability and specify MFA devices associated with the user account.

    For more information, see:

  • User agreement consent management

    The /environments/{{envID}}/users/{{userID}}/agreementConsents endpoint provides directory operations to read, accept, and revoke an agreement associated with a user account.

    For more information, refer to User Agreement Consents.

  • User ID verification

    The /environments/{{envID}}/users/{{userID}}/verifyTransactions endpoint provides directory operations to create, read, update, and delete an ID verification transaction record associated with a user.

    For more information, refer to PingOne Verify.

You must have the Identity Data Admin role to perform operations on users resources.

The original admin user for an organization starts with full roles and permissions for PingOne. However, as the deployment moves forward, that admin user might no lose access to the full roles and responsibilities within the organization.

For example, a worker application creates a new environment and automatically gets Identity Data Admin and Client Application Developer role assignments for that environment. However, the worker application can perform Identity Data Admin operations in that environment. Because only the worker application has the Identity Data Admin role in that environment, the initial admin user cannot perform Identity Data Admin operations in it. However, the worker application can give the role assignment to another user or another worker application. For more information about roles, refer to Roles.

The original admin user can lose access to a worker application’s client secret. This can happen when the admin user does not have a superset of the worker application’s role assignments. The worker application receives all of the role assignments of the admin user or worker application that created it, which gives the admin, or any other admin with a superset of those role assignments, access to the worker application’s secret.

However, if the worker application gains new role assignments (for example, by creating a new environment and being granted role assignments to cover the new environment), then the admin who originally created the worker application can no longer access the worker application’s secret.

You can prevent this by ensuring that when an environment is created by a worker application, that worker application grants any newly received role assignments for that environment to the original admin user or any other admins or worker applications that need access to the worker application’s secret.

Use Cases