PingOne

Publishing policy versions to Authorize gateway instances

You can publish policy and Trust Framework versions to gateway instances through Version History in PingOne or you can use an Authorize gateway.

Publishing a version is like saving a snapshot of your policies and Trust Framework definitions. The published version reflects the state of these objects at a specific point in time. Learn more in Authorization version history.

You can also publish policy versions to cloud-based decision endpoints. However, decision endpoints don’t provide the data residency and reduced latency benefits of gateway instances deployed in your organization’s infrastructure.

Each gateway instance that is associated with the same Authorize gateway uses the authorization version published to that gateway. When you publish a version to an Authorize gateway, the authorization version deployment configuration is downloaded and stored locally with the gateway instance in your infrastructure.

Publishing could fail if policies include features that aren’t compatible with gateway instances, such as version differences or unsupported features. Learn more in Policies published to Authorize gateways.

Before you begin

  • Version History

  • Authorize gateway

Publish a version in Version History

You can use Version History to publish authorization versions to gateway instances. This method enables you to view which versions are published to particular Authorize gateways.

Steps

  1. In the PingOne admin console, go to Authorization > Version History.

  2. Click the More Options (⋮) icon next to the version you want to publish and select Publish Version.

    A screen capture of the Version History page with Publish Version highlighted in the More Options menu.

    In this example, the Prod Gateway, Test Gateway, and Dev Gateway Authorize gateways were created using the Bootstrap authorization version. You can also see that the Prod and Test cloud-based decision endpoints use the Bootstrap version, and that the Dev decision endpoint uses the latest policy version by default. You’ll publish versions to Authorize gateways and not to cloud-based decision endpoints.

  3. In the Publish to list, select an Authorize gateway.

    A screen capture of the Publish to list with a gateway selected.

  4. If you’re publishing the latest version, which is unnamed, enter a Name that makes the version easy to identify.

    If you’re publishing a version that’s already named, you can use the existing name or change it.

    A screen capture of the Publish Version page with a gateway selected and the version Name set to 'Payment checks'.

  5. Click Publish.

    Result:

    The latest version is renamed and it is now published to the Dev Gateway, in addition to the Dev decision endpoint.

    A screen capture of the Version History page with the Payment checks policy version published to the Dev Gateway and the Dev decision endpoint.

Select a version in an Authorize gateway

This method for publishing authorization versions to gateway instances provides a convenient way to change the version when you’re editing a gateway.

Steps

  1. In the PingOne admin console, make sure that you’ve named an authorization version.

    As an example, you’ll use the Payment checks version that you just published to the Dev Gateway and promote it to the Test Gateway.

  2. Go to Integrations > Gateways and click the Authorize gateway you want to work with.

  3. On the Configuration tab, click Edit.

  4. Select an Authorization Version.

    A screen capture of the Authorization Version page with Payment checks selected as the version to use.

  5. Click Save.

    This updates the authorization version that the gateway will download and deploy to any associated gateway instances.

    A screen capture of the gateway’s Configuration tab showing the version ID and version name.

    Version History also reflects which policy version the Authorize gateway is using.

    A screen capture of the Version History page showing the Payment checks policy version published to the Dev endpoint and the Dev and Test gateways.