Environments define separate working domains within an organization. Environments are used to model regions within a large global enterprise such as NA (North America) or EU (European Union). They are also used as the defining entity to segregate enterprise operations by functionality, staging environments, or configurations.

In the management API sample requests shown in this document, the {{apiPath}} variable in the sample requests represents the regional domain for the PingOne server. See PingOne API domains for more information.

For more information, see Environments.

Environments contain many of the core resources on which all identity services are built. Environments encompass:

• MFA

  A multi-factor authentication (MFA) authentication policy prompts users to complete an MFA action, such as entering a one-time passcode received on a registered device or accepting a push confirmation on a registered native device. There ae severl services that enable MFA configuration at the environment level.

  For more information, see Device Authentication Policies, MFA Settings, and Sign-On Policies.

• Populations

  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, see Populations.

• Resources

  Resources represent the connections to external services, enabling secure access to PingOne resources and other defined external resources.

  For more information, see Resources, Resource scopes, and Resource attributes.

• Activities

  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, see User activities.

• Branding and images

  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, see Branding and Images.

• Password policies

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

  For more information, see Passwords.

• Sign-on policies

  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, see Sign-on policies and Sign-on policy actions.

• Notifications templates

  These endpoints manage notification templates resources and notifications content.

  For more information, see Notifications templates and Notifications settings.

• Certificates and keys

  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, see Certificate management.

Roles, entitlements, and permissions

Roles, permissions, and entitlements are defined at the root of the platform. 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, see Roles and Resource scopes.

Licenses

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

For more information, see Licensing.