JumpCloud connects to Authdog over SAML 2.0. JumpCloud 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 **JumpCloud**, and click **Enable**. The form shows the service-provider values to paste into JumpCloud:

| Authdog field | Where it goes in JumpCloud |
| --- | --- |
| **ACS / Reply URL** | **ACS URL** on the SSO connector |
| **SP Entity ID (Audience)** | **IdP Entity ID** / **SP Entity ID** pair |
| **SP metadata XML** | Download and upload where the connector accepts metadata |

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

## Create the SSO connector in JumpCloud

1. In the JumpCloud admin portal, open **SSO Applications** and click **Add New Application**, then **Custom SAML App**.
2. Set the **IdP Entity ID** and **SP Entity ID** to the SP Entity ID from Authdog, and the **ACS URL** to the ACS URL.
3. Map attributes: `email`, `firstname`, `lastname`. Authdog reads standard defaults; custom names can be mapped in the connection's **IdP attribute mapping** section.
4. Activate the connector, then copy the **IdP URL** (the SSO endpoint) and download the **signing certificate**. The connector's metadata URL works too.

## Configure Authdog

Fastest path: paste the JumpCloud **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 connector's IdP URL |
| **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 JumpCloud prompt, and confirm the user appears under **Users** with a JumpCloud 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 JumpCloud 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 is truncated — export the certificate again and paste it whole |
| `certificate_mismatch` fault | JumpCloud rotated its cert; run **Rotate certificate** |
| Signature validation failure | The connector signs the response only — set it to sign the assertion, or both |
| Works in one environment only | Each environment has its own ACS URL to register in JumpCloud |

## Related

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