PingOne Advanced Identity Cloud

New name for ForgeRock Identity Cloud

What is the new name for ForgeRock Identity Cloud?

From early 2024, the new name for ForgeRock Identity Cloud will be PingOne Advanced Identity Cloud.

Will my service be interrupted?

No, all existing deployments will continue to function normally, with no action required from you.

Why is the name being changed?

In 2023, Ping Identity and ForgeRock became one company, with the Ping Identity brand being chosen for the new combined company. As part of this effort, all ForgeRock products will be given a Ping Identity family name with no interruptions to service and no removal of product functionality or capabilities.

ping product names cloud
ping product names platform
ping product names standalone

The name change to PingOne Advanced Identity Cloud also reflects the purpose of the product within the newly combined product offering. With its full-tenant isolation, advanced security architecture, and high level of configurability, PingOne Advanced Identity Cloud supports complex use cases and stringent data isolation requirements.

When will I see the product name change?

The name change to PingOne Advanced Identity Cloud is a work in progress, and will be updated gradually. You will see both the new and the old names used in different places for the foreseeable future.

Is ForgeRock Identity Cloud going away?

No, only the name ForgeRock Identity Cloud is going away. PingOne Advanced Identity Cloud is the same product, with the same capabilities. The product plays a business critical role for many of Ping Identity’s customers and is only being renamed to align with the Ping Identity brand. The new naming emphasises Ping Identity’s commitment to the future of the product.

Will the name change again?

No, the name change was necessitated by the joining of the Ping Identity and ForgeRock companies, but once changed the new name is here to stay.

PingOne Advanced Identity Cloud

PingOne Advanced Identity Cloud (formerly ForgeRock Identity Cloud) is a SaaS-based digital identity and access management (IAM) solution designed for workforce, consumer, and B2B identities. Ping Identity handles the deployment, management, upgrades, and monitoring of the platform’s various software components, ensuring a seamless and secure experience.

With Advanced Identity Cloud, you can manage the complete lifecycle of identities including:

And much more...

Support and customer success

Ping Identity is here to help you with your identity journey. You’ll have a dedicated team to help you achieve your goals. To find answers to common questions, create a support case, access training, and more, visit the Ping Identity Support Portal.

Our dedicated cloud engineering team monitors and manages your environment. We’ll help you with moving configuration, and with secrets management, between environments. Learn about moving configuration between environments.

power_settings_new
Getting Started

Steps for
first-timers
format_list_numbered
How-Tos

Cookbook instructions
library_books
Deep Dives

How things work & other concepts

Data regions

Ping Identity provides PingOne Advanced Identity Cloud capabilities at worldwide geographic locations, or regions. Learn more about data regions in Data residency.

Global region map

Product availability by region

Region Group Location (Region) Advanced Identity Cloud Identity Governance and Administration &
Autonomous Identity

Asia

Hong Kong (asia-east2)

Yes

No

Singapore (asia-southeast1)

Yes

Yes

Jakarta (asia-southeast2)

Yes

Yes

Europe

Belgium (europe-west1)

Yes

Yes

Finland (europe-north1)

Yes

No

London (europe-west2)

Yes

Yes

Frankfurt (europe-west3)

Yes

Yes

Netherlands (europe-west4)

Yes

Yes

Zurich (europe-west6)

Yes

No

Paris (europe-west9)

Yes

Yes

United States

Iowa (usa-central1)

Yes

Yes

South Carolina (usa-east1)

Yes

Yes

North Virginia (usa-east4)

Yes

Yes

Oregon (usa-west1)

Yes

Yes

Los Angeles (usa-west2)

Yes

No

Canada

Montreal (northamerica-northeast1)

Yes

Yes

Australia

Sydney (australia-southeast1)

Yes

Yes

Brazil

Sao Paolo (southamerica-east1)

Yes

Yes

Plan for Advanced Identity Cloud

To plan for your organization’s future using the cloud, you need a comprehensive, enterprise-grade identity platform that supports your priorities, such as:

  • Intuitive usability

  • Extensive customizations

  • Detailed configuration options

  • Wide-range of functionality

  • Operational ease

The Advanced Identity Cloud checklist highlights the top 10 considerations and best practices for your PingOne Advanced Identity Cloud strategy.

As you consider implementing Advanced Identity Cloud in your organization, the topics in the plan for Advanced Identity Cloud section (also referred to as the Adoption Framework Guide) provide guidance to help you effectively integrate the Advanced Identity Cloud services into your business environment.

Your transition into Advanced Identity Cloud does not have to be a hard transition. It can be a phased approach. For example, you can migrate a key business application into Advanced Identity Cloud and then transition other applications later.

There are functional differences between Advanced Identity Cloud and self-managed Ping Identity Platform.

Learn more about migrating from a self-managed version of Ping Identity Platform to Advanced Identity Cloud in Functionality differences when moving from self-managed.

The framework evolved from the best practices of Ping Identity employees, partners, and customers to help customers adopt Advanced Identity Cloud services. Proficiency in deploying, customizing, and administering the Advanced Identity Cloud is essential for the successful adoption of the Advanced Identity Cloud services. Our Training Platform offers training to architect, build, and deploy your identity solution using the Ping Identity platform.

The topics in the Plan for Advanced Identity Cloud section use Software to SaaS (S2S) to refer to the process of migrating customers from a self-managed deployment to Advanced Identity Cloud.

Create an implementation team

The successful adoption is dependent on establishing a project implementation team with the following roles or expertise:

  • Project sponsor

  • Project manager

  • Implementation engineers

  • UI developers

  • JavaScript developers

  • Enterprise architect

  • Operations

  • Performance testing

Gather project information

Timely gathering of the following information is essential:

  • Current project plan and important milestones

  • Enterprise architecture diagrams

  • Target system access and authentication methods

  • Directory service information and data model (such as business units, user roles, groups, object hierarchy)

  • Descriptions of existing identity and access management processes, procedures, and logic (such as sequence diagrams)

  • Current and planned technical changes within the timeframe of the project

  • Identity onboarding and offboarding flows

  • Relevant system access and approval groups, as well as associated authority levels

Adoption phases

The adoption of Advanced Identity Cloud services is best accomplished using existing products, proven methods, and reusable tools built from global field experience, in the following phases:

Ping Identity Adoption Framework diagram with four phases

  1. Assess and plan:

    • Analyze functional and nonfunctional requirements

    • Review most significant use cases for phase 1

    • Review existing Ping Identity platform configurations for S2S movement

    • Provision tenants and set up project governance

  2. Transform:

    • Define overall architecture

    • Define required data models

    • Define migration path for application data and solution configurations

  3. Adopt and refine:

    • Set up basic administration interfaces

    • Migrate data

    • Migrate configurations leveraging proven migration toolsets (for S2S)

    • Define journeys

    • Integrate applications

  4. Enable:

    • Set up operational and monitoring interfaces

    • Perform functional and performance tests

    • Transition to Advanced Identity Cloud in phases

    • Hand over to Ping Identity support team

Support

Customers can access and manage the resources linked to their support subscription. Customer’s nominated administrators can manage users, access policies, and application integration. Learn about getting started with Ping Identity support in the Support Portal Administration Guide.

Phase 1 - Assess and plan

You create an overall cloud adoption plan to guide your project team and confirm how the PingOne Advanced Identity Cloud services will be used.

The best practices for creating a cloud adoption plan focuses on speed, efficiency, and repeatability of the migration processes.

The actions to take in this phase are:

Functionality differences when moving from self-managed

If you currently use PingAM and PingIDM on-premises or in a private cloud, you’ll notice some differences in functionality when moving to PingOne Advanced Identity Cloud.

Key areas of difference

Key difference Description

Advanced Identity Cloud is the platform

With Advanced Identity Cloud, you get the combined functionality of PingAM and PingIDM without the need for manual integration. For example, there’s no requirement to deploy a datastore or the admin console, as these are included in the Advanced Identity Cloud deployment.

File system access

File system access isn’t available in Advanced Identity Cloud. All functionality is accessed through the UI and REST APIs.

Direct access to the datastore

Direct access to the datastore is not supported in Advanced Identity Cloud. Instead, Ping Identity manages the datastore for you and provides access through the UI and REST APIs. Configuration of PingDS isn’t required.

Custom code and extensibility

Advanced Identity Cloud supports extending the platform using JavaScript. Groovy and Java binaries aren’t supported.

Extending the data model schema

Advanced Identity Cloud supports creating managed objects through the UI. The storage of these objects is managed by Advanced Identity Cloud and cannot be explicitly configured.

Learn more in Can I extend the data model schema?

Unsupported features

The following features are not currently supported in Advanced Identity Cloud:

  • Identity of Things (IoT)

  • LDAP as a service

  • Open Banking

  • Security Token Service (STS)

  • Sub-entry PingDS password policies

  • User-Managed Access (UMA)

In addition, Advanced Identity Cloud only supports a subset of hashed passwords for import. Learn more in Synchronize passwords.

No planned support

Ping Identity does not plan to support the following in Advanced Identity Cloud:

  • AM XUI end user login

  • Authentication modules and chains

  • Groovy

  • Java binaries

  • SOAP STS

Frequently asked questions

Yes. You can configure the cookie domains of your custom domains in Advanced Identity Cloud. Learn more in Cookie domains.

Can I customize policy evaluation with a plugin?

Instead of a plugin, you can use scripted policy conditions to modify the actions taken by Advanced Identity Cloud during policy evaluation. Learn more in Scripted policy conditions.

Can I customize SAML 2.0 with plugins?

Advanced Identity Cloud provides a scripting engine and template scripts for you to extend SAML 2.0 behavior. Java plugins aren’t available with Advanced Identity Cloud. Learn more in Customize SAML 2.0.

Can I use Amster with Advanced Identity Cloud?

Amster is not supported in Advanced Identity Cloud deployments. However, several options are available for managing configuration data. These include:

  • Journey export and import: You can export and import journeys through the Advanced Identity Cloud admin UI. This includes all dependencies such as nodes, inner journeys, scripts, and themes attached to a journey. Learn more in Journeys.

  • Postman collection: Ping Identity provides a Postman collection with example requests organized by feature, making it easier to use and understand Advanced Identity Cloud REST APIs. Learn more in Advanced Identity Cloud Postman collection.

  • Open source tooling: Community-supported tools are also available for managing configuration.

Can I use ssoadm with Advanced Identity Cloud?

The ssoadm feature isn’t available in Advanced Identity Cloud. This is because ssoadm communicates directly with PingDS, which is not a requirement of Advanced Identity Cloud. Use the options mentioned in Can I use Amster with Advanced Identity Cloud? to help manage configuration data.

Can I have multiple realms?

Advanced Identity Cloud tenants include two configurable realms, Alpha and Bravo. If you need to group identities further, you can use the Organizations feature.

Can I extend the data model schema?

You can create managed objects through the UI. The storage of these objects is managed by Advanced Identity Cloud and cannot be explicitly configured.

Adding arbitrary custom attributes to the user schema is supported. However, there is a limitation on indexing custom attributes, so an indexed extension attribute is provided for this purpose.

Learn more in Advanced Identity Cloud identity schema.

Can I connect applications to LDAP (PingDS)?

Not directly. The PingDS instance in Advanced Identity Cloud is not exposed for connecting applications. If you have an existing on-premises PingDS instance that your applications connect to, you will need to use a Remote Connector Server (RCS) to connect to your on-premises PingDS instance and then synchronize data using Advanced Identity Cloud. Learn more in Sync identities.

Is Kerberos or desktop authentication supported in Advanced Identity Cloud?

Yes. You can delegate Kerberos or desktop authentication via PingGateway, by using the Identity Assertion node.

Are native log handlers implemented in Advanced Identity Cloud?

In Advanced Identity Cloud, audit and debug log data is extracted through a consolidated REST endpoint. Learn more in Get audit and debug logs.

Phase 2 - Transform

Cloud adoption design helps you convert your cloud adoption project goals into an actionable plan. Use the cloud adoption design to guide and align your technical efforts with your organization’s business strategy.

In consultation with your stakeholders, document the cloud adoption project goals and your desired business outcomes, and develop a technical architecture of the proposed solution.

The actions to take in this phase are:

For further information on how to set up and configure Advanced Identity Cloud, view the article Configuration management for ForgeRock Identity Cloud - Part 1.

Phase 3 - Adopt and refine

After completing the transformation phase, your organization is ready to adopt PingOne Advanced Identity Cloud.

The actions to take in this phase are:

Phase 4 - Enable

After testing the PingOne Advanced Identity Cloud solution, you can transition it into production.

The actions to take in this phase are:

  • Operations and monitoring: Monitor your tenant through audit and debug logs.

    The Advanced Identity Cloud analytics dashboard provides real-time metrics of your tenant.

  • Functional and performance testing for the new Advanced Identity Cloud deployment

  • Phased migration plan for migrating applications to Advanced Identity Cloud

  • Production transition to Advanced Identity Cloud

  • Deprovision existing deployment

  • Hand over to Ping Identity support team

Plan for data object modeling

Learn more about the deployment process in Plan for Advanced Identity Cloud.

When preparing an PingOne Advanced Identity Cloud deployment, one of the most important phases of the planning process is data object modeling. Data object modeling is the process of creating an identity data model describing the data types, its structures, and its relationships that meet the business requirements of your company.

Successful deployment of Advanced Identity Cloud requires early and detailed consideration of the data object model. This applies as much to Advanced Identity Cloud as it does to a customer’s own deployment of the Ping Identity software.

A structured approach of discovery and rationalization creates a solid foundation for the implementation of the object model, and allows for evolution over time in line with business requirements.

Planning considerations for data object modeling

The key planning considerations for data object modeling are the following:

Item Description

User communities

Determine the different user communities the platform will serve, such as customers, business partners, and employees.

Entities

Determine the different entities and identities that make up each of these communities, such as end users, organizations, and devices.

Authentication and authorization requirements

Determine the information needed for each of these entities to support your authentication and authorization requirements.

Use Introduction to Authentication to understand authentication. Use Authorizations and policy decisions to understand authorization.

Combine the two together with Journeys.

Data organization

Determine how end user identities (or data) are organized and how the organization affects authentication and authorization.

Utilize realms, relationships, organizations, and groups to aggregate entities and identities into business units, standalone organizations, or families of users.

Identity mappings

Determine the specific identity mappings required for your applications. It is important to understand how identity information is created or updated in Advanced Identity Cloud and which information is managed externally.

The development of the new identity model should preserve the entities and attributes relevant to your business requirements while leaving behind the identity data relevant only internally to your organization.

Advanced Identity Cloud uses schemas and other techniques to provide a common and consistent way to manage new and existing data sources across your organization. Advanced Identity Cloud offers extensive flexibility for identity profiles and their associated business processes. However, the overall object model is relatively fixed, as expected of a Software as a Service (SaaS) delivery model. The data object modeling process therefore involves some level of adaptation for any pre-existing customer identity model. It is unlikely—​and often undesirable—​that the existing model can be implemented exactly as-is within Advanced Identity Cloud.

Learn more about the building blocks of the identity model in object modeling.

Key functions

The data object model in PingOne Advanced Identity Cloud should support the key functions of an identity platform including one or more of the following:

  • Identification: Occurs when a user or entity makes a claim about their identity when attempting to gain access to a system or resource. For example, a user enters their username or ID to access a system. Learn how to achieve this via a journey in login journey.

  • Authentication: Occurs when the user or entity proves their identity to the satisfaction of the access system. For example, a user enters their password or their identity is confirmed through some other process, which is verified by the system. Learn more in Introduction to Authentication.

  • Authorization: Occurs when the system checks that the user or entity is allowed to access the resource or system after proper identification and authentication. Learn more in Authorizations and policy decisions.

  • Identity provisioning: Ensures user accounts are created, updated, deleted, and assigned the proper access privileges to resources across applications and systems.

    You can achieve this in various ways in Advanced Identity Cloud:

    Item Description

    Application management (current)

    Use a library of templates for OIDC applications that makes the process of registration, provisioning, and configuration quick and easy.

    Bulk import identities

    Use a CSV file to import a set of identities. This is useful when you want to add a large number of identities to Roles and assignments in a single operation.

    Roles and assignments

    Create an entitlements structure that fits the needs of each realm by using roles and assignments.

    Sync identities

    Synchronize identities from an external data store.

    Pass-through authentication

    Use pass-through authentication to validate user passwords via a remote service.
Object modeling key functions
Figure 1. Key functions of the data object model

Approach

The approach to data object modeling in PingOne Advanced Identity Cloud consists of three main phases: discovery, rationalization, and implementation.

Discovery

This stage involves the discovery of the current state of the identity and future requirements, including:

  • Sources of identity information, such as customer databases, directories, and third-party identity providers

  • Business application requirements, including the authorization model and identity data required for operation

  • Authentication requirements

  • Actors and entities within the identity space, including users, roles, and organizations

Rationalization

This stage involves analyzing the results from the discovery phase and defining privileges to deliver a workable object model. This step involves the following:

  • Includes all entities and attributes required for authentication, authorization, and identity management

  • Excludes identity data that is not relevant to business requirements

  • Defines all privileges for access to identity data at the field level

  • Maps all identity data from Advanced Identity Cloud to external repositories and vice-versa

Implementation

This stage involves configuring the managed data object model within the PingOne Advanced Identity Cloud tenant, following the detailed plan developed during the rationalization phase. This step includes the following configuration:

  • Ping Identity object attributes, roles, and internal privileges

  • Connector definitions for external repositories, including the attributes returned by each connector

  • Synchronization mappings for Advanced Identity Cloud to external repositories and vice-versa

Organize user communities

First, it is critical to decide if and how to use realms when planning the object model.

You can organize distinct user communities, such as business partners and consumers in PingOne Advanced Identity Cloud. For example, you can distinguish users by implementing a shared property, such as a user type, or divide users by organizational membership.

The most complete separation of users is through the use of realms, which allows each community to have its own user properties, authentication and authorization policies, and journeys.

User communities via realms

You can also separate users within realms through:

  • Organizations: Use organizations to separate identities with parent and children organizations.

  • Groups: Use groups to follow an organization structure or base groups on the needs and privileges of an arbitrary set of users.

User profiles

Another critical stage in data object modeling is deciding which properties to assign to users. This assignment is driven by your business application requirements. For example, you can assign properties to users based on the type and level of authentication required, and the level of access granted by passing authorization information to each application.

Object modeling user profiles

Storing user properties in Advanced Identity Cloud

When considering which user properties to store in Advanced Identity Cloud, there are a number of important considerations for each property that fall under the following points

  • Relevance

  • Data validation

  • Least privilege

  • Search enablement

Relevance

You should only store user attributes in Advanced Identity Cloud if they are used for identity management, authentication, or authorization. For example, if a user’s home address is never used during authentication and is never included in an ID or access token, then there is no requirement for this information to be stored in Advanced Identity Cloud.

Defining properties not in use in Advanced Identity Cloud creates unnecessary overhead and can introduce potential privacy issues. Once the data object model is live, you can always add properties to the model, but it is much harder to remove properties that can affect existing users.

Likewise, if the backend application fetches fine-grained user entitlements from an internal repository at access time, there is no need to include such entitlements in an access token; the token simply provides broad scope information to inform the application what constraints to apply for this method of access.

Relevance

Also, when using OAuth2 access tokens, for example, the token can include a scope to indicate the broad permissions granted to the user; however, there is a balance between what authorization data Advanced Identity Cloud can deliver versus what additional entitlement checks can perform by the relying applications themselves. For example, the scopes and privileges included in an access token versus the resource access privileges held within an internal entitlements repository for the subject of that token. The commonality of authorization requirements between business applications also influences what authorization data can deliver.

Data validation

Each property should have a validation policy applied to it to maintain the integrity of the identity data. It is important to establish validation policies in full ahead of going live in production. Adjusting validation policies to live production data is complicated. Any policies applied retroactively to existing identity information cause issues when updating existing identities.

Least privilege

For each property defined in the data object model, you should apply the principle of least privilege. For properties that the user should not be able to update directly, the user editable setting should be disabled. For properties that should only be accessed internally, you should disable any viewable option, such as a managed object event trigger or custom endpoint. Learn more about setting this property in Creating and modifying managed objects.

Search enablement

If a property is used to search for identities, such as retrieving a list of users by their surname or finding users who have not logged in for over a year, then the property must be a searchable field. Advanced Identity Cloud implements this as an indexed field. Learn more about the searchable field in Creating and modifying managed objects.

The property can either be a standard search field, such as sn, or an indexed placeholder field, such as frIndexedString1. Custom fields added by the customer, for example custom_userType, cannot be searched upon. Since there are a limited number of searchable user fields, you must use care when using indexed placeholders for fields that will never be searched on.

Relationships

Relationships are a key consideration in the identity model. You can use relationships in various ways to organize identities and to drive authentication and authorization policies. Relationships exist between users, between users and organizations, and between organizations.

Data object modeling relationships
Relationship-derived virtual properties

For those relationships that exist in the PingOne Advanced Identity Cloud default schema, consider using relationship-derived virtual properties (RDVPs) for any information that can be used for authentication or included in authorization tokens. For example, if you use an organizational property to determine whether to enforce multi-factor authentication at login, then it is more efficient to store a copy of that property in the profile of each member of the organization, rather than looking up the organization properties using the relationship each time.

The caveat is that each update to the organization properties triggers an update to the users belonging to that organization if you mirror the organization properties using an relationship-derived virtual property. This overhead is amplified if the RDVP is included in outbound synchronization to any external repositories.

Relationship properties

In some cases, relationships are not completely binary in nature. For example, if a user belongs to multiple organizations, the relationship may be different for each organization. A user can be authorized to represent multiple organizations, but have a different role at each. You may also want to store additional information about the relationship. For example, a user can be an alumni of multiple educational establishments and have a start/end date for each one.

In this case, you can consider defining relationship properties in the data object model. One or more properties can be defined for the relationship itself, such as role, date range, privileges, and others. You can include these properties in authentication decisions and access tokens.

Data object modeling
Custom relationships

The Advanced Identity Cloud schema supports custom relationships. Custom relationship properties allow you to define custom relationships between managed objects. For example, you could model a parent-child relationship by creating the custom_Parents and custom_Children properties and configuring them as one-way one-to-many relationships. Learn more in Manage custom relationship properties.

Identity mappings

When external identity data is synchronized with PingOne Advanced Identity Cloud, either as a one-time migration or on an ongoing basis, you should take into account the synchronization strategy into the data object model.

Data object modeling
Data mastering

When identity information is synchronized between environments, it is best to establish a single source of truth for that data. For example, if you create customer identities within a customer relationship management (CRM) system and then synchronize them into Advanced Identity Cloud, you should avoid the same customer information being updated in both Advanced Identity Cloud and the CRM system.

This case can lead to a circular synchronization process, where changes are synchronized outbound to the CRM, then pulled back again at the next inbound sync, triggering another outbound sync, and so on.

Data hygiene

Prior to enabling synchronization, you should validate external identity data against the field policies set in Advanced Identity Cloud. You should resolve any discrepancies by updating existing data or by mapping logic included in the synchronization process.

Getting started with PingOne Advanced Identity Cloud

Step 1: Register your Advanced Identity Cloud tenant

After your organization purchases PingOne Advanced Identity Cloud and requests a tenant, Ping Identity prepares the tenant for initial use. Afterward, Ping Identity sends a registration email to the person from your organization that is designated as the tenant administrator.

If you are the designated tenant administrator and received the registration email, click on the registration link and perform the sign up steps in the next section.

Step 2: Sign in to Advanced Identity Cloud

If you haven’t received a confirmation email, contact your Ping Identity representative.

You receive an email for each environment.

  1. In a supported web browser, enter your first name, last name, and password.

  2. Accept the privacy policy.

  3. Set up Multi-factor authentication (MFA).

Step 3: Know your tenant

  1. Take 5 minutes to read about Advanced Identity Cloud and its capabilities.

  2. Take 5 minutes to read about your tenant.

Step 4: Take a test drive

Here are some things you can try in your development environment:

  1. Create a user profile.

  2. Create an external role for your user.

  3. Add an application to your identity platform.

  4. Set up a basic login end-user journey.

  5. Sign out of your tenant administrator session, then be the end-user:

    1. Using a browser, go to your tenant URL.

    2. Sign in as the test user you created.

Step 5: Get going

Once you’re ready to stage real users and applications in your tenant, start with these steps:

  1. Take some time to read up on how your engineering environments work.

  2. To provision your tenant, import identity profiles to your tenant.

  3. Invite others to be tenant administrators.

  4. Add an application to your tenant.

  5. Sync your application users with users in your tenant.

  6. Use the Ping SDKs to set up authentication.

  7. Set up a login end-user journey.

Admin UIs

PingOne Advanced Identity Cloud provides three user interfaces (UIs) to help you manage your tenant:

idcloudui admin consoles

① Advanced Identity Cloud admin UI
② AM admin UI (native console)
③ IDM admin UI (native console)

Advanced Identity Cloud admin UI

This is the primary UI, designed to handle most of the day-to-day tasks associated with managing your tenant. To get started, take a test drive.

AM admin UI and IDM admin UI (native consoles)

These are secondary UIs, intended for specialist tasks when configuring AM and IDM in Advanced Identity Cloud. They let you access functionality not yet available in the Advanced Identity Cloud admin UI.

You don’t need separate credentials to access these UIs. If you are signed into the Advanced Identity Cloud admin UI, you can seamlessly switch from one UI to another.

AM admin UI

Use to register SAML 2.0 applications, for example.

To open, in the Advanced Identity Cloud admin UI, click Native Consoles > Access Management.

IDM admin UI

Use to set up a built-in connector, for example, or map your identities to identities stored in an external resource.

In the Advanced Identity Cloud admin UI, click Native Consoles > Identity Management.

Advanced Identity Cloud analytics dashboard

PingOne Advanced Identity Cloud analytics dashboard provides a comprehensive snapshot of your Advanced Identity Cloud system usage. You can use the dashboard to gain valuable insights on your tenants:

Analytics Dashboard

Monitor the number of users and engagements

At the top of the Identity Cloud analytics dashboard, there is a summary of total number of users, applications, and organizations in your realm. These realm usage totals are summarized as follows:

  • Total Users. Displays the total count of active and inactive users in this realm.

  • Applications. Displays the total number of current applications in this realm.

  • Organizations. Displays the total number of organizations in this realm.

Analytics Dashboard Summary page

Below the realm usage totals, Identity Cloud analytics dashboard displays three trendline charts: user engagements, total users, and new users. These trendline charts are updated every two to three hours and are summarized as follows:

  • User Engagement. Displays the trendline of the number of user engagements within a given time period; by default, the last 30 days. A user engagement is counted when a user is involved in an identity operation within the given time period. An identity operation can be any of the following:

    • Sign-in/authentication

    • Token refresh (for example, token issuance, validation, and refresh)

    • Password creation or change

      A user who has multiple user engagements within a given time period is counted once.

  • Total Users Trend. Displays the trendline for total users (active and inactive) during the time period in this realm.

    The total users trend number may differ from the Total Users number at the top of the page as the data depends on the selected time period and the update frequency. For example, new users who have been added to the system within the last hour may not appear yet on the page.

  • Sign Ups. Displays the trendline for new user sign-ups during the time period in this realm.

Filter timelines

Each chart displays the usage numbers for the current time period, expressed as solid lines; the dotted lines display the numbers for the previous time period. For example, if the time period is Last 30 days, the solid line displays the numbers over the last 30 days from today’s date; the dotted line displays the previous 30-day numbers.

To compare the numbers for a specific date, hover over a point on either line to display the numbers for the current and the previous time periods.

Analytics Dashboard Trends page

By default, the Identity Cloud analytics dashboard displays the number of engagements, total users, and new user sign-ups for a 30-day period, you can filter the output by changing the time period.

Change the time period for the trendline charts

  1. Click Last 30 days, and select one of the following time periods:

    • Today. Displays the numbers for today, 12:00 a.m. to the current time.

    • Yesterday. Displays the numbers for yesterday, 12:00 a.m. to 12:00 p.m. on the previous day.

    • Last 7 Days. Displays the numbers for the last seven days from today’s date.

    • Last 30 Days. Displays the last 30 days from today’s date. This is the default time period.

      All dates and time periods are based on UTC time.

  2. Click Apply to save your changes.

Analytics Dashboard Trends time periods filtering

Monitor journeys

You can refer to a chart on the number of successful and failed journey outcomes within your realm on the Identity Cloud analytics dashboard. Scroll down the Identity Cloud analytics dashboard page to refer to the Journeys graph.

By default, the Identity Cloud analytics dashboard displays the aggregation of all successful and failed journeys on the Advanced Identity Cloud. These aggregations express four different types of information:

  • Blue lines indicate successful journey outcomes.

  • Red lines indicate failed journey outcomes.

  • Solid lines indicate the journey outcomes that occurred within the current selected time period.

  • Dotted lines indicate the journey outcomes in the previous time period.

The journey usage is not counted if the journey is used as a node in another journey.

Analytics Dashboard Journeys section

The Identity Cloud analytics dashboard also lets you filter the chart by journey type. The available journeys are listed on the Advanced Identity Cloud Journeys page and includes any custom journeys that you may have configured. For example:

  • EvaluateRisk

  • ForgottenUsername

  • Login (default)

  • PasswordGrant

  • ProgressiveProfile

  • Registration

  • ResetPassword

  • Sample Tree

  • UpdatePassword

The categories are:

  • Authentication

  • Password Reset

  • Progressive Profile

  • Registration

  • Username Reset

The journeys and categories options come from any tag that you have selected.

Filter journeys

  1. On the Journeys chart, click All journeys.

  2. On the Filter Journeys dialog box, select one or more journeys on the drop-down list to include in your chart.

  3. Click Apply to update your journeys chart. The changes appear immediately.

Access journey pass/fail details

The Journeys chart also lets you drill down at specific points on a trendline to access its details, or metric breakdown. Red lines indicate failed journeys. Blue lines indicate successful journeys.

For example, you can use the Metric Breakdown page to review the journeys for the selected date, sorted by a ranking of percentage failures (default). The percentage is calculated for each journey as the total outcomes passed or failed, and then sorted in descending order from the highest failed journey by percentage to the lowest failed journey by percentage.

Analytics Dashboard Metric Breakdown page sorted by percentage success or failures

The Metric Breakdown page also lets you sort the journeys by number ranking. Number indicates the actual number of successful or failed outcomes for each journey.

The following table provides an example of how the analytics dashboard ranks by percentage and by number:

Table 1. Metric Breakdown Example of How Percentage Rank and Number Rank and Determined
Journey Total Outcomes Passed Failed Percentage Rank Number Rank

A

900

630

270 (30%)

2

1

B

100

50

50 (50%)

1

2

C

100

80

20 (20%)

3

3
Timeouts are not displayed in the Journey outcomes.

Access the metric breakdown page

  1. On the Journeys chart, hover anywhere over a trendline to view the successful or failed outcomes for that date, and then click View detail. The Metric Breakdown page appears with more insights on the individual journeys. By default, All Journeys and Percentage are selected.

  2. On the Metric Breakdown page, click Number to display the number of failed and successful journeys sorted by rank.

    Click to show how to access the metric breakdown page
    How to access the Metric Breakdown page

Top Five Journeys by Outcome and Top Five Journeys by Usage widgets

The Identity Cloud analytics dashboard displays two additional widgets providing trendlines into your journeys: Top Five Journeys by Outcome and Top Five Journeys by Usage. The Top Five Journeys by Outcome widget displays the top five journeys ranked by percentage failed or successful. The default selection is Fail. You can change the selection to Success to display top five successful journeys.

The Top Five Journeys by Usage widget displays the top five most or least used journeys. By default, the most used journeys are selected. Each bar chart provides the percentage usage of the journey in the given time period based on the outcomes only. For each journey, the calculation is based on the total number of outcomes for the journey divided by the total number of all journey outcomes in the time period.

The widgets only display the journey outcomes for the selected time period. The x-axis denotes the percentage outcomes in the journey.
Analytics Dashboard Top Five Journeys by Outcome and Top Five Journeys by Usage Widgets

Access top five journeys by outcome and top five journeys by usage

  1. On the Top Five Journeys by Outcome widget, the widget displays the top five failed journeys by default. Click Success to display the top five successful journeys.

  2. On the Top Five Journeys by Usage widget, the widget displays the most used journeys by default. Click Least to display the least used journeys.

Notice

The analytics dashboard service provides key insights and trends with respect to successful or failed journey outcomes, number of users, user engagement, number of new users (sign-ons), applications, and organizations. By leveraging this functionality, Ping Identity customers can better understand their usage of the Advanced Identity Cloud. This functionality also allows Ping Identity to maintain accurate billing information with respect to such use.

All data Ping Identity collects for the purposes of providing the analytics dashboard service is anonymized using industry standard practices. The purpose is to ensure that the data does not contain any personally identifiable information, and further, so it cannot be re-identified. This includes, but is not limited to, a one-way SHA-256 hashing function that returns a hexadecimal representation of a UUID. This ensures that no personally identifiable information is used by Ping Identity, or any other third-party or system.

Plan for security in Advanced Identity Cloud

When you set up your PingOne Advanced Identity Cloud tenant environments, you must ensure that they are configured with security in mind.

The following topics lay out a comprehensive list of actions to take to help you set up Advanced Identity Cloud as securely as possible. However, security is a very broad subject, and every Advanced Identity Cloud customer has different use cases; you are expected to do your own research to complement the information found in these topics.

You should also ensure any changes you make to security settings in Advanced Identity Cloud follow your own corporate security policies, especially in relation to password complexity and active features.

Network connections

HTTPS and HTTP

Always use HTTPS for connections into Advanced Identity Cloud.

Advanced Identity Cloud does not accept connections over HTTP. However, a client making API calls to Advanced Identity Cloud over HTTP instead of over HTTPS can still send unprotected credentials in an HTTP Authorization header, inadvertently exposing sensitive information. Even though Advanced Identity Cloud rejects the request, the credentials could be leaked to eavesdroppers.

Configure the cookie domain in your Advanced Identity Cloud tenant to ensure only users and entities from trusted domains can be authenticated.

By default, Advanced Identity Cloud sets the cookie domain based on the fully qualified hostname of a tenant, such as id.mycompany.co.uk. However, you may want to change the cookie domain to mycompany.co.uk so Advanced Identity Cloud can communicate with any subdomain.

Learn more in Configure the cookie domain for a custom domain.

CORS

Configure cross-origin resource sharing (CORS) to securely share browser resources across domains.

In Advanced Identity Cloud, you can configure CORS to allow browsers from trusted domains to access Advanced Identity Cloud protected resources. You can create as many individual CORS configurations as your applications need. The configurations combine to form the entire set of rules for resource sharing. The CORS service also collects the values of the JavaScript Origins property in each OAuth 2.0 client and adds them to the list of accepted origins.

Learn more in Configure cross-origin resource sharing.

CSRF attacks

Advanced Identity Cloud includes a filter to harden protection against cross-site request forgery (CSRF) attacks. The filter applies to all REST endpoints under /am/json/. It requires all requests other than GET, HEAD, or OPTIONS to include at least one of the following headers:

X-Requested-With

This header is often sent by Javascript frameworks, and the UI already sends it on all requests.

Accept-API-Version

This header specifies which version of the REST API to use. Use this header in your requests to ensure future changes to the API do not affect your clients.

Failure to include at least one of the headers causes the REST request to fail with a 403 Forbidden error.

Learn more about API versioning in REST API versions.

Identify originating client IP addresses

The X-Forwarded-For HTTP header identifies the originating IP address of a client; however, there are security and privacy concerns associated with its use. Learn more in the MDN Web Docs X-Forwarded-For.

Advanced Identity Cloud includes two alternative HTTP headers:

X-Real-IP

This header contains the IP address of the client making the request.

X-Trusted-Forwarded-For

This header contains three trusted X-Forwarded-For IP addresses as an array. The first IP address in the array is always the real client IP address. The remaining two values in the array are load balancer IP addresses.

Consider using one of these headers as a trusted replacement for the X-Forwarded-For header, especially when making decisions concerning access.

If the client is behind a reverse proxy, the trusted replacement headers contain the real IP address of the reverse proxy, not the client.

Identify client geolocation

Advanced Identity Cloud provides HTTP headers to let you identify the geographical location of client requests coming into your tenant environments. Use these headers to implement region-specific behavior in your scripts and journeys. For example, you can enforce MFA for clients originating from a specific country or set of countries.

X-Client-Region

This header contains the country (or region) associated with the client’s IP address in the form of a two-letter region code, such as US or FR. For most countries, these region codes correspond directly to ISO-3166-2 codes.

X-Client-City

This header contains the name of the city where the client request originated. For example, Mountain View for Mountain View, California. There is no canonical list of valid values for this header. The city names can contain ASCII letters, numbers, spaces, and the following characters: "!#$%&'*+-.^_`|~".

X-Client-City-Lat-Long

This header contains the latitude and longitude of the city where the client request originated. For example, 37.386051,-122.083851 for a request from Mountain View.

Request data size limits

To protect against requests that contain large amounts of data, Advanced Identity Cloud rejects the following:

  • Requests with a body size larger than 1 MiB (1,048,576 bytes).

  • Requests that contain JWTs that expand to a size larger than 32 KiB (32,768 bytes) when decrypted.

Protect applications

Ping Identity provides policy enforcement points (PEPs) to improve application security by enforcing Advanced Identity Cloud authentication and authorization decisions in your applications:

  • Use PingGateway to protect your applications without modifying them or the infrastructure where they run—whether on-premises, in a public cloud, or in a private cloud. PingGateway acts as a reverse proxy, intercepting client requests and server responses to enforce authentication and authorization.

  • Use Ping Identity web or Java policy agents to protect your applications when you have access to the infrastructure where they run. Policy agents natively plug into web or application servers and intercept inbound requests to enforce authentication and authorization. You can manage the policy agent configurations centrally from Advanced Identity Cloud.

Learn more in these guides:

Learn more about applications built using an SDK in Security guide for SDKs.

Sessions

Set expiry time for sessions and JWT tokens

To minimize the time an attacker has to attack an active session, set expiry times for Advanced Identity Cloud sessions and JWT tokens.

Ping Identity recommends setting an expiry time of 15 minutes. However, you should decide your expiry time according to the context of your deployment, balancing security and usability so that your end users can complete operations without their authenticated sessions frequently expiring. Learn more in the OWASP Session Management Cheat Sheet.

To update the expiry time for authenticated sessions and JWT tokens in Advanced Identity Cloud, learn more in Configure session termination settings.

Journey session allowlisting

Enable journey session allowlisting to protect journey sessions from replay attacks, whereby a malicious user might try to rewind an authentication flow to a previous node.

Learn more in Authentication session allowlist.

Session invalidation after password reset

Advanced Identity Cloud has no automatic mechanism to delete authenticated sessions when a user changes their password. To implement automatic invalidation of authenticated sessions on password reset, consider one of the following approaches:

  • Use the logoutByUser action, specifying the username in the request payload.

    This action can be used for server-side and client-side sessions and is described in Invalidate all sessions for a user.

  • Use a query to locate all sessions for a user, then use the logoutByHandle action to invalidate those sessions.

    This action can be used for server-side sessions only and is described in Invalidate specific sessions.

Access

Remove non-essential access

Make sure only authorized people can access Advanced Identity Cloud, and audit system access periodically.

Deactivate non-essential features

The more features you have turned on, the greater the attack surface. If something is not being used, switch it off, or remove its configuration to deactivate it. These are some features to consider turning off:

Harden password policy

Ensure you harden your password policy for each realm. These are some common ways to harden a password policy:

  • Require a minimum of 12 characters

  • Prevent the use of repetitive characters

  • Prevent the use of commonly used passwords

  • Prevent reuse of the last three passwords

Learn more in Password policy.

Account lockout

Account lockout is a security mechanism that locks a user account after repeated failed login attempts. You can use it to supplement your password policy to slow down brute-force attacks.

Ping Identity recommends using a persistent lockout. If that’s not compatible with your company’s preferences, Ping Identity recommends using a duration lockout of at least 15 minutes.

Learn how to configure account lockout and implement account lockout in your journeys in Account lockout.

Use service accounts to generate access tokens

Ensure any automated scripts do not rely on a tenant administrator account to generate an access token. Instead, use a service account. Additionally, restrict the scopes that a service account can grant only to those needed by the automated script.

Learn more in Service accounts.

Enforce 2-step verification for tenant administrators

Make sure 2-step verification is mandatory for tenant administrators.

Learn more in Tenant administrator mandatory 2-step verification FAQ.

Keys, secrets, and encryption

Update cryptography

Different algorithms and methods are discovered and tested over time, and communities of experts decide which are the most secure for different uses. Use up-to-date cryptographic methods and algorithms to generate keys.

Small keys are easily compromised. Use at least the recommended key size.

Store sensitive data in secrets

Ensure sensitive data such as passwords and encryption keys are stored in ESV secrets, and never embedded directly in configuration or scripts.

Learn more in the Secrets section of ESVs.

Rotate keys

These are some reasons to rotate keys regularly:

  • To limit the amount of data protected by a single key.

  • To reduce dependence on specific keys, making it easier to migrate to stronger algorithms.

  • To prepare for when a key becomes compromised. The first time you try key rotation, it shouldn’t be during a real-time recovery.

  • To conform to internal business compliance requirements.

Learn more in Use ESVs for signing and encryption keys.

Encrypt sensitive data

Advanced Identity Cloud supports encryption of data stored in the repository. Data can be encrypted using reversible encryption or one-way encryption.

Ping Identity recommends you encrypt all sensitive data. These are examples of sensitive data:

  • Passwords

  • Authentication questions

  • Credit card numbers

  • Government benefit ID numbers

Learn more in Secure identity data.

Encrypt OIDC ID tokens

OpenID Connect 1.0 (OIDC) ID tokens can contain sensitive data and personally identifiable information (PII). Ping Identity recommends you encrypt all ID tokens.

Learn more in Encrypt ID tokens and backchannel logout tokens.

Journeys

Add account lockout to login journeys

Login journeys are vulnerable to brute force attacks. You can mitigate this risk by adding account lockout to your login journeys.

Add email confirmation to registration journeys

Registration journeys are vulnerable to denial-of-service attacks, where attackers try to create extremely high numbers of new users with the intention of exhausting system resources and creating an outage. You can mitigate this risk by using the Email Suspend node in your registration journeys to prevent new users from being created until an email address is verified.

Learn more in Email Suspend node.

Deactivate unused or insecure journeys

Advanced Identity Cloud is preconfigured with default journeys to get you started. However, Ping Identity recommends you harden these default journeys or implement your own journeys using security best practices; for example, by adding MFA to a login journey to confirm user identity using a device.

Once you have built your journeys, ensure you deactivate any unused journeys, particularly insecure login journeys that only require a username and password.

Learn more in the Deactivate a journey section of Journeys.

Deactivate hosted pages

If you have developed your own end-user journey and account experience using Ping SDKs or APIs, Ping Identity recommends that you deactivate the hosted journey pages and/or the hosted account pages to ensure there is no risk of unauthorized access by a malicious user.

Learn more in Advanced Identity Cloud hosted pages.

Threats

Misconfiguration

Misconfiguration can arise from bad or mistaken configuration decisions and poor change management. Depending on the configuration error, features can stop working in obvious or subtle ways and potentially introduce security vulnerabilities.

To guard against bad configuration decisions, implement good change management:

  • For all enabled features, document why they are enabled and what your configuration choices mean. This implies a review of configuration settings, including default settings that you accept.

  • Validate configuration decisions with thorough testing.

  • Maintain a record of your configurations and the changes applied.

  • Use version control software for any configuration scripts and to record changes to configuration files.

Compromised passwords

Despite efforts to improve how people manage passwords, users have more passwords than ever before, and many use weak passwords. You are strongly encouraged to use a password manager to generate secure passwords.

Audit logging and monitoring

Advanced Identity Cloud provides an audit logging service that captures key auditing events critical for system security, troubleshooting, and regulatory compliance.

Audit logs gather operational information about events that occur within an Advanced Identity Cloud tenant. They track processes and security data, such as authentication mechanisms, system access, user and administrator activity, error messages, and configuration changes.

You are strongly encouraged to set up systems to monitor your audit logs and alert you to unusual patterns of behavior.

Learn more in Monitor your tenant.