PingIdentity (PingOne, PingFederate) connects to Authdog over SAML 2.0. Ping stays the system of record for your workforce; Authdog fronts your application and consumes the assertion.

## Copy the Authdog SP details

In the [Authdog console](https://console.authdog.com), select the project and environment, open **Authentication > Providers**, find **PingIdentity**, and click **Enable**. The form shows the service-provider values to paste into Ping:

| Authdog field | Where it goes in Ping |
| --- | --- |
| **ACS / Reply URL** | **ACS URL** on the SAML application |
| **SP Entity ID (Audience)** | **Entity ID** |
| **SP metadata XML** | Download and import where Ping accepts SP metadata |

Each environment has its own connection id, so its own ACS URL.

## Create the SAML application in Ping

1. In the PingOne admin console (or PingFederate), create a **SAML application** / SP connection.
2. Set the **ACS URL** to the ACS URL from Authdog and the **Entity ID** to the SP Entity ID.
3. Map attributes: `email`, `givenName`, `surname`. Authdog reads standard defaults; custom names can be mapped in the connection's **IdP attribute mapping** section.
4. Enable the application, then copy the **SSO URL** (the IdP single sign-on endpoint) and download the **signing certificate**. Ping's SAML metadata URL works too.

## Configure Authdog

Fastest path: paste the Ping **metadata URL** into **Import from IdP metadata URL** and click **Fetch**. Authdog fills the SSO URL, certificate, and entity ID for you.

| Field | Value |
| --- | --- |
| **IdP SSO URL** | The Ping SSO endpoint |
| **IdP X.509 certificate** | The signing certificate PEM |
| **Email domains** | Domains routed to this connection, e.g. `acme.com` |

Save, then toggle the connection **active**.

## Test the connection

1. On the saved connection, click **Test connection**. Authdog checks required fields, the SSO URL, and that the certificate parses as X.509. With a metadata URL set it also re-fetches the metadata and flags drift (`metadata_mismatch`, `certificate_mismatch`). Each fault comes back with a named code and a fix.
2. Then run a real login: open the **Sign-in URL**, complete the Ping prompt, and confirm the user appears under **Users** with a Ping identity linked.

## Rotate the certificate

1. If the connection has a metadata URL, click **Rotate certificate** — Authdog re-fetches the metadata and stores the new certificate.
2. Otherwise paste the new PEM from Ping into the certificate field and save.

Every rotation writes a `sso_connection_certificate_rotated` event to the environment audit log with the actor and the source. The old certificate is not readable afterward.

## Troubleshooting

| Symptom | Cause |
| --- | --- |
| `invalid_url` fault | SSO URL is not a valid https URL |
| `invalid_certificate` fault | The PEM includes the whole chain — paste only the signing cert |
| `certificate_mismatch` fault | Ping rotated its cert; run **Rotate certificate** |
| `metadata_mismatch` fault | The application was recreated in Ping with a new endpoint — re-import the metadata |
| Works in one environment only | Each environment has its own ACS URL to register in Ping |

## Related

| Read | To learn how to |
| --- | --- |
| [Enterprise SSO](/docs/sso) | Understand the SSO model and discovery |
| [SCIM provisioning](/docs/concepts/provisioning) | Sync Ping users and groups over SCIM |
| [Audit logs](/docs/audit-logs) | Find the rotation and sign-in events |