ForgeOps

Limitations

This page documents limitations on the Ping Identity Platform when deployed on a Kubernetes cluster in the cloud.

On all Ping Identity Platform components

The forgeops config export command doesn’t handle object deletion correctly.

Configuration objects, such as AM authentication trees and service definitions, aren’t deleted correctly by the forgeops config export command. If you’ve deleted one or more objects from your Ping Identity Platform configuration in a single-instance deployment, and then you export the configuration, the deleted objects continue to exist in your configuration profile.

To work around this problem, locate the deleted objects in your configuration profile after you’ve run the forgeops config export command. Then, delete the objects that should’ve been deleted from the JSON configuration files. After deleting the objects, if you build a new Docker image based on your configuration profile, the new image won’t contain the deleted objects.

On PingDS

PingDS live data and logs should reside on fast disks.

PingDS data requires high performant, low latency disks. Use external volumes on solid-state drives (SSDs) for directory data when running in production. Don’t use network file systems such as NFS.

Adding DS pods to a cluster should be done in advance of anticipated additional load.

When you increase the number of DS pods in a cluster, they’re automatically provisioned with the same directory data in existing pods. You must allow time for the data provisioning to complete and new pods to become available.

Database encryption isn’t supported.

The ds Docker image doesn’t support database encryption. DS fails to start if it detects that any data was encrypted during the Docker build process.

DS starts successfully even when it can’t decrypt a backend.

When the DS master key isn’t available, DS starts up successfully even though it’s unable to decrypt a backend.

Root file system write access is required to run the DS Docker image.

The DS Docker image won’t run without root file system write access.

On AM

AM must be reconfigured and restarted if the number of DS pods changes.

In DS 8.0.0, you can elastically scale the number of DS pods in Kubernetes. However, the AM configuration doesn’t automatically respond to changes in the number of DS pods.

Because of this, you must modify the AM configuration after you scale the number of idrepo or cts pods in a running AM deployment.

Using subrealms in ForgeOps deployments requires additional considerations.

If you decide to deploy AM with subrealms, you’ll need to configure the subrealms in the DS repository before starting AM. Make the LDAP configurations for the AM backend in the relevant backend ldap configuration files.

Session stickiness is recommended for all deployments.

ForgeOps recommends that you configure your load balancer to use sticky sessions to achieve better performance.

Session stickiness is required for some deployments.

Two AM features are stateful, and require you to configure your load balancer to use sticky sessions:

  • SAML v2.0 single logout.

  • Browser-based authentication using authentication chains, which is deprecated in AM 8.0.0. Note that AM authentication trees are not stateful, and don’t have this limitation.

Value substitution is supported only for some configuration properties.

AM doesn’t support property value substitution for several types of configuration properties. Refer to Property value substitution in the AM documentation for more information.

The SOAP binding isn’t supported for SAML v2.0 single logout.

When deploying SAML v2.0 single logout, use the HTTP-POST or HTTP-Redirect bindings. The SOAP binding isn’t supported when AM runs in a container.

The shared identity repository isn’t preconfigured for UMA deployments.

The shared identity repository deployed with the CDK and the CDM isn’t preconfigured to store UMA objects, such as resources, labels, audit messages, and pending requests.

In order to use UMA in the CDK or the CDM, you’ll need to customize your deployment. For more information, refer to the User-Managed Access (UMA) 2.0 Guide.

On IDM

The IDM repository is deployed in a single master topology.

IDM can actively use only a single instance of DS as its repository. Should the DS instance fail, IDM can fail over to another DS instance; the limitation that only a single instance can be active applies. Using multiple DS replicas at the same time isn’t supported.

ForgeOps deployments aren’t preconfigured to support IDM’s workflow engine.

ForgeOps deployments use DS as the IDM repository. Because of this, these deployments don’t support IDM’s workflow engine, and workflow features are disabled.

Adding workflow support to ForgeOps deployments requires substantial, complex configuration changes, including:

  • Adding a JDBC repository to the ForgeOps deployment.

  • Enabling workflow features in IDM.

On PingGateway

There are no limitations for this release.