Environments

In PingOne, a population defines a set of users, similar to an organizational unit (OU). In a given environment, you can use populations to simplify the management of users. For example, you can create a population for similar types of users and apply a password policy to that population. You must create at least one population before you can create users. An individual user cannot belong to more than one population simultaneously, but users can be moved to a different populations.

For more information, refer to Populations in the PingOne Platform API Reference.

Users are unique entities that interact with the applications and services within the environment to which the they are assigned. User resources in PingOne are the full representation of a user profile, including the user’s relationships, roles, devices, and attributes. Users are associated with populations rather than defined within a population. The user’s association with a population is established as a property on the user resource.

For more information, refer to Users, User password management, User role assignments, and Enable user devices in the PingOne Platform API Reference.

Applications in PingOne define the connection between the PingOne platform and the actual application (also thought of as the client configuration). Resources represent the connections to external services, enabling secure access to PingOne resources and other defined external resources.

For more information, refer to Application Management, Application role assignments, Application sign-on policy assignments, Resources, Resource scopes, and Resource attributes in the PingOne Platform API Reference.

Activities are collections of user activity information such as login attempts, password reset attempts, and total active user counts. This audit data can be exported, reported on, or streamed out to customer security information and event management (SIEM) solutions.

For more information, refer to User activities in the PingOne Platform API Reference.

Branding can be configured for elements of the PingOne interface. All end user interfaces are branded according to the theme defined in the associated branding resource. Image resources can be configured to upload custom branding image files to the content delivery network (CDN) and manage the lifecycle of those images.

For more information, refer to Branding and Images in the PingOne Platform API Reference.

These resources represent the password management actions and password policies that can be applied to users within an environment.

For more information, refer to Passwords in the PingOne Platform API Reference.

These resources represent the sign-on workflow policies to establish an authentication flow during login, re-authentication, or registration actions that identify and verify users. The authentication workflows are part of the authentication API. The signOnPolicy resource is a proxy back to other APIs to perform authentication actions.

For more information, refer to Sign-on policies and Sign-on policy actions in the PingOne Platform API Reference.

These endpoints manage notification templates resources and notifications content.

For more information, refer to Notifications templates and Notifications settings in the PingOne Platform API Reference.

The certificate management endpoints provide an implementation that supports FIPS 140-2 Level 1 compliant security algorithms to generate key pairs. They manage customer-provided certificates, customer-provided signing/encryption keys, Ping-generated certificates (PKI), and Ping-generated signing/encryption keys.

For more information, refer to Certificate management in the PingOne Platform API Reference.

The identity provider endpoints manage external identity provider configurations to enable social login and inbound SAML login features in PingOne. An external identity provider configuration allows linked users to authenticate and gain access to PingOne resources using the login flow and credentials provided by the external identity provider.

For more information, refer to Identity providers and Linked accounts in the PingOne Platform API Reference.

Roles, permissions, and entitlements are defined at the root of the platform, and are scoped to an environment. Roles are assigned to users, and these user roles include a scope property to grant the user permissions corresponding to the role. For example, a role of Identity Admin contains permissions allowing the subject to read and edit user data. When this role is assigned to a user, it can be assigned with the scope property that identifies a population or an environment to which the permissions apply.

Self-service application permissions are described using scopes rather than roles. Scopes are more narrowly defined roles in that a scope cannot cross an environment boundary, and it is restricted to a specific task. For example, the p1:read:user scope grants permission to read the user resource’s data only; it does not grant permission to read another user’s data or perform create, update, or delete operations on user resources.

For more information, refer to Roles and Resource scopes in the PingOne Platform API Reference.

The license resource identifies the organization that owns the license, the licensing package type, and the expiration date for the license.

For more information, refer to Licensing in the PingOne Platform API Reference.

These environments contain the actual identities managed by your business. Production environments cannot be deleted (unless they are first demoted to a SANDBOX type), which offers additional protection against unintentional removal. You must have a non-Trial license to create or promote an environment to the PRODUCTION type. Any long-standing environments, even those used for testing and staging, should be configured as PRODUCTION to minimize the risk of data loss.

These environments are temporary configurations used primarily for configuration testing. Sandbox environments can be deleted using the DELETE {{apiPath}}/environments/{{envID}} endpoint operation.