PingCentral

System requirements and supported configurations

For the best possible experience, ensure your computer meets or exceeds the minimum system requirements and become familiar with the configurations supported for this release.

PingFederate 9.3 and later.

PingAccess 5.3.2 and later.

Platforms:

  • Microsoft Windows Server 2019

  • Microsoft Windows Server 2016

  • Red Hat Enterprise Linux ES 8.0

  • Red Hat Enterprise Linux ES 7.6

Browsers:

  • Chrome

  • Firefox

Databases:

  • MySQL 5.7+

  • PostgreSQL 11.5+

  • RDS (MySQL)

A demonstration-only, embedded H2 database is installed by default. Use the H2 database only for trial or training environments. It is not recommended to use the default H2 database in production. For testing and production environments, always use a secured external storage solution for proper functioning in a clustered environment.

Java runtime environments:

  • Oracle Java 11 LTS

  • OpenJDK 11

Docker:

  • Docker 23.0.1

  • Docker 19.03.13. Base image operating system: Alpine Linux 3.11.

  • Docker 18.09.0. Host operating system: Ubuntu 18.04 LTS, Kernal: 4.4.0-1052-aws 7.3.

Ping Identity accepts no responsibility for the performance of any specific virtualization software and in no way guarantees the performance or interoperability of any virtualization software with its products.

Supported configurations

PingCentral is an orchestrator for PingFederate. Configurations are sourced from PingFederate to define PingCentral applications and templates. Configure each environment in advance and ensure you have working authentication policies with persistent grants, access token mappings, and access token managers (ATMs) in place before using PingCentral to promote new applications.

Review additional information regarding supported features, protocols, and frameworks before you get started:

General configurations

Configuration Supported Unsupported

Single sign-on and user management

  • Directly managing users, which are stored in PingCentral embedded database.

  • Signing on with single sign-on (SSO) using an OpenID Connect (OIDC) token.

  • Optional feature: Group management, which allows the OIDC token used for SSO to include the groups claim.

  • Beta feature: Provisioning users and groups from an external store using API calls.

If you want to provision users and groups of users through the API, you must disable the groups claim functionality by setting thepingcentral.sso.oidc.groups-claim-enabled property to false in the application.properties file.

Entitlements

  • Assigning one or more application owners that have already been provisioned.

  • Editing and promoting entitlements for an application.

  • After signing into PingCentral using SSO, administrators can assign groups of users as application owners, in addition to adding users one at a time. Group membership is based on the groups claim included in the OIDC token used for SSO.

Assigning groups of users entitlements based on an external attribute, such as LDAP group membership.

Backup and restoration

Saving the database and configuration files by copying the directories h2-data/ and config/ to a new instance.

Use the H2 database only for trial or training environments. It is not recommended to use the default H2 database in production. For testing and production environments, always use a secured external storage solution for proper functioning in a clustered environment. For more information on setting up an external database, see Setting up MySQL.

Testing involving H2 is not a valid test. In both testing and production, it might cause various problems due to its limitations, and PingCentral does not support H2-involved cases.

To ensure these files contain the most up-to-date information, do not copy them while PingCentral is running.

Using an API to export PingCentral configuration information.

OAuth and OIDC configurations

Configuration Supported Unsupported

Client authentication

Using a client TLS certificate, private key JSON web token (JWT), or symmetric keys.

Grant types

Using all OAuth and OIDC grant types.

Scopes

All scopes and exclusive scopes referenced in the PingFederate client JSON file, which is obtained during the template creation process.

ATMs and OIDC policies

Saving ATMs or OIDC policies into templates created from client applications that have them.

If ATMs or OIDC policies do not exist in an environment, PingCentral will create them during the promotion process. If an ATM or OIDC policy of the same name already exists in a target environment, it will not be modified.

Saving or promoting access token mapping, persistent grants, policy contracts, or authentication policies.

Selectors

Connection set selectors. Clients can only be automatically connected to authentication policies via policy contracts. If your authentication logic requires use of a selector, add it in PingFederate.

SAML 2.0 SP configurations

Configuration Supported Unsupported

Bindings

Using POST bindings.

Using artifact, redirect, or SOAP bindings.

Profiles

  • IdP-initiated SSO

  • SP-initiated SSO

  • IdP-initiated SLO

  • SP-initiated SLO

Attribute mapping

  • Mapping attributes, provided by a single authentication policy contract, in an unspecified format. You can also map attributes to static text.

  • Using OGNL expressions as part of attribute mapping.

Mapping attributes from data sources, such as basic or URI.

Policy contracts

Referencing one policy contract per template.

Referencing more than one policy per template.

If multiple policy contracts are referenced in a template when it is promoted, newly-created applications will only map attributes from the first policy contract referenced. If PingFederate applications are directly added to PingCentral, the mappings from each policy contract are preserved.

Adapter mappings

Use authentication policy contract mappings instead of adapter mappings.

Certificate management

  • Providing a public certificate for a service provider (SP) connection. PingCentral creates a self-signed certificate with an expiration date of one year from today and configures it as the PingFederate identity provider (IdP) certificate.

  • Uploading a key pair to use as the IdP certificate for all SAML 2.0 connections promoted to an environment.

An SP certificate is required to promote a SAML 2.0 connection, but might be optional in future releases.

PingAccess configurations

Configuration Supported Unsupported

Destination

Both Agent and Site are supported.

The destination is not promoted with the application but selected per environment.

PingAccess application types

All application types (Web, API and Web+API) are supported.

The application type cannot be changed in PingCentral.

Token provider

PingFederate must be the token provider.

Third-party token providers for PingAccess are not supported.

Application resources

Resources can be added and updated for each application.

You can configure resources in Web applications with specific HTTP methods in PingAccess version 6.2 or later, but this feature is not yet supported in PingCentral.

Resource ordering

Automated and manual resource ordering are both supported.

Identity mappings

Identity mappings for all application types (Web, API and Web+API) are supported.

Identity mappings are not promoted with the application but selected per environment.

Virtual hosts

Virtual hosts are supported.

Virtual hosts are not promoted with the application but selected per environment.

Policy

Application and resource policies can be updated per application.

New rules and rule sets cannot be created in PingCental.

Virtual resources are available in PingAccess version 6.2 or later, but are not yet supported in PingCentral.

Customized authentication challenge responses, which support single-page applications, are also available in PingAccess version 6.2 or later. Applications with this type of policy can be added to PingCentral, but cannot be promoted to another environment unless the authentication challenge policy also exists in the target environment.