ForgeOps

Integrate ForgeOps with the PingOne Worker service

Why integrate a ForgeOps deployment with the PingOne Worker service?

Integrating ForgeOps with the PingOne Worker Service allows a ForgeOps deployment to extend platform capabilities through PingOne Universal Services such as PingOne Protect, PingOne Verify, and others. The PingOne Worker service provides the integration point between ForgeOps and these PingOne services using secrets and configuration.

For example, when integrated with PingOne Protect through the PingOne Worker Service, journeys can use real-time risk scores to make smarter authentication decisions. PingOne Protect evaluates signals such as device, network, and user behavior to produce a risk score for each sign-on event. Journeys can then use that score to adapt authentication journeys dynamically—such as, allowing access for low-risk events, prompting step-up authentication for medium-risk events, or denying access for high-risk events.

This guide provides sample instructions for setting up the integration in a ForgeOps deployment running on minikube. You can adapt the instructions for your environment and the PingOne services you want to use.

Set up a PingOne environment

Use the steps in the PingOne documentation to set up a PingOne environment and a PingOne Worker application.

  1. Create a PingOne Workforce solution environment as described in Create a PingOne environment.

  2. Create a PingOne Worker application as described in Create a PingOne Worker application.

  3. Enable the PingOne Worker application using the Enable switch on the top right of the application overview tab.

  4. Note the following data from the PingOne Worker application overview tab:

    • Environment ID:

    • Client ID:

    • Client Secret:

Set up ForgeOps on minikube

  1. Since 2026.3.0 Helm chart is not yet published, check out the main branch.

  2. Ensure that the window running the minikube tunnel remains open as long as you run the ForgeOps deployment.

  3. All forgeops commands must be run in the Python virtual environment.

  1. Use the steps in the Quick deployment on minikube to set up a ForgeOps deployment on minikube. Use the local Helm chart to deploy ForgeOps in step 7 of the Perform ForgeOps deployment section:

    helm upgrade --install identity-platform ./charts/identity-platform  \
--namespace my-namespace --values helm/my-env/values.yaml

  2. Create a filesystem secret:

    In the following command, replace my-client-secret with the client secret you obtained in the PingOne Application overview.

    $ kubectl create secret generic pingone-secrets \
  --namespace my-namespace \
  --from-literal=am.services.pingone.worker.pingprotect.clientsecret='my-client-secret'

  3. Modify your ForgeOps deployment environment to set the secret name:

    $ cd /path/to/forgeops/bin
$ ./forgeops env --env-name my-env --pingone-secret pingone-secrets

  4. Redeploy ForgeOps to pick up the new secret:

    Since 2026.3.0 Helm chart is not yet published, use the local Helm chart to deploy ForgeOps:

    helm upgrade --install identity-platform ./charts/identity-platform  \
--namespace my-namespace --values helm/my-env/values.yaml

  5. Check if AM pods have started:

    $ kubectl get pods --namespace my-namespace
$ *kubectl rollout status deploy/am --namespace my-namespace

    If you find any of the pods is in Error or CrashLoopBackOff state, try to delete the pod with the kubectl delete pod pod-name command and let Kubernetes restart the pod.

  6. Verify the secret is present and accessible to the AM pod:

    $ kubectl exec --namespace my-namespace deploy/am -- ls  /var/run/secrets/pingone
Defaulted container "openam" out of: openam, ...
am.services.pingone.worker.pingprotect.clientsecret

  7. Configure a secret store in AM native console:

    1. In the AM native console, navigate to Secret Stores > Add Secret Store and create a new secret store with the following values:

      Field Value

      Secret Store ID

      p1-worker-service

      Store Type

      File System Secret Volumes

      Directory

      /var/run/secrets/pingone

      File Suffix

      (leave empty)

      Value Format

      Plain Text

  8. Configure a Worker Service in AM:

    1. In the AM native console, navigate to Services > Add Service > *PingOne Worker Server and click create.

    2. In the Secondary Configuration tab, click Add a Secondary Configuration and enter the following values in the New workers configuration form. Then click Save:

      Field Value

      Name

      Ping_SDK_Worker (note no spaces!)

      Client ID

      11a2…..(obtained from PingOne Worker application overview)

      Client Secret Label Identifier

      pingprotect

      Environment ID

      b2d….(obtained from PingOne Worker application overview)

    3. In the ensuing WORKERS CONFIGURATION form for Ping_SDK_Worker, enter the following values and click Save and Test Connection: |PingOne API Server URL and Authorization URL |Select from these options, depending on where the PingOne tenant is hosted:

      Region API URL Authorization URL

      North America (Excluding Canada)

      https://api.pingone.com/v1

      https://auth.pingone.com

      Canada

      https://api.pingone.ca/v1

      https://auth.pingone.ca

      Europe

      https://api.pingone.eu/v1

      https://auth.pingone.eu

      Asia-Pacific

      https://api.pingone.asia/v1

      https://auth.pingone.asia

The configuration changes made in this section are file-based configuration changes. So you must export the configuration changes, build a new configuration image, and redeploy as explained in the next steps. Otherwise, you may lose the configuration changes when you redeploy AM.

Export AM runtime config into a profile and redeploy

In order for AM ensure that the new configuration, such as file system secret store, worker service connection, and so on are not lost, the changes must be built in to a new image. The following steps show how to export the configuration changes into a new profile, build a new configuration image, and redeploy AM.

  1. Create a new profile:

    $ cd /path/to/forgeops/bin
$ ./forgeops config profile create --profile-name workerService \
  --baseline-profile default --env-name my-env

  2. Export the new profile:

    $ cd /path/to/forgeops/bin
$ ./forgeops config export --baseline-profile default --no-upgrade am \
  workerService --env-name my-env

  3. Build the new config image:

    $ cd /path/to/forgeops/bin
$ ./forgeops config build --config-profile workerService \
  --env-name my-env --tag workerService am

  4. If needed, load the configuration image into minikube:

    $ minikube image load am:workerService

  5. Redeploy ForgeOps to pick up the new config image:

    Since 2026.3.0 Helm chart is not yet published, use the local Helm chart to deploy ForgeOps:

    helm upgrade --install identity-platform ./charts/identity-platform  \
--namespace my-namespace --values helm/my-env/values.yaml

  6. Check status and wait until the rollout is complete:

    $ kubectl rollout status deploy/am --namespace my-namespace

Test the integration

  1. In the AM native console, navigate to Services > PingOne Worker Service > Secondary Configuration tab > Ping_SDK_Worker > Save and Test Connection.

    You should see the Connection was successful message.

  2. [Optionally] Configure a test journey using these links to test the integration: