Jira Cloud SSO: the SAML values Atlassian expects, and how to wire them up

Jira Cloud does not authenticate users itself when SSO is on. It trusts a SAML assertion from your identity provider, and it uses Atlassian Guard to manage the connection, the domains and the user lifecycle.

Short answer: in Atlassian Guard Standard, copy the service provider assertion consumer service URL (the ACS URL) and the service provider entity URL (the audience) from your organization's SAML setup, create a SAML application in Casdoor, paste those two values into Redirect URLs and SAML reply URL, send the email as the NameID, and map the three Atlassian attributes. Responses must be signed, and SCIM is the clean way to deprovision users.

What you need before you start

• Atlassian Guard Standard. SAML SSO for Atlassian Cloud is part of Guard Standard, not a Jira project setting.
• Organization admin access. The SAML configuration lives in the Atlassian admin, not in a Jira project.
• A verified domain. Users are matched to the organization by their email domain.
• An identity provider directory and a linked domain. Guard needs the directory before it will enforce SSO.
• HTTPS everywhere. Atlassian requires HTTPS between the browser, the IdP and Atlassian.

If you are still on Atlassian Access, the same concepts apply; Guard is the current product name for the security and identity layer.

Step 1: get Jira's service provider values

In the Atlassian admin, open the SAML configuration for your identity provider. Atlassian shows two values that are unique to your organization:

• Service provider assertion consumer service URL (ACS URL): the endpoint that receives the SAML response.
• Service provider entity URL (entity ID or audience): the identifier that the assertion must be addressed to.

Do not copy these from a blog post or from another tenant. They are generated per organization and they change if the organization is rebuilt. Paste them somewhere safe; you will need both in Casdoor.

Step 2: create the SAML application in Casdoor

In Casdoor, create an application and open its SAML tab. Casdoor exposes a metadata URL in this form:

https://your-casdoor-host/api/saml/metadata?application=admin/your-app

Most service providers can import the IdP metadata from that URL. For Jira Cloud, the two fields that matter are:

The Redirect URLs value must match the entity URL exactly. A trailing slash, a different scheme or a different host is enough to make Jira reject the assertion.

Step 3: NameID and attributes

Atlassian requires the NameID to contain the user's email address, or a user principal name when Entra nested groups are used. In Casdoor, enable Use Email as SAML NameID so the NameID is the user's email, or use the SAML NameID template if your directory needs a different identifier.

Atlassian also expects these attributes:

Casdoor's built-in SAML attribute variables are $user.email, $user.name, $user.displayName, $user.id, $user.phone, $user.roles and $user.groups. There is no separate first-name or last-name variable in the default set, so map givenname and surname to the fields you keep those values in, or to $user.displayName if your directory stores a single display name. The stable identity is the name claim, which should be $user.id.

Add each attribute in Casdoor's custom attribute section with the full claim URI as the Name. The Name format can stay unspecified unless Atlassian tells you otherwise.

Step 4: signing, clocks and logout

• Sign the response. Atlassian requires signed SAML responses. Casdoor signs the response by default. If you enable assertion signing too, check that Jira accepts both signatures; some service providers are picky about double-signed assertions.
• Do not encrypt the assertion. Atlassian's generic guide asks for signed, not encrypted, responses.
• Keep the clocks in sync. SAML assertions have a short validity window. Run NTP on both the IdP and the Jira side; a few minutes of skew produces the classic "assertion expired" error.
• Single logout is optional. Jira Cloud supports SAML single logout with some identity providers. If you configure it, set Casdoor's SAML single logout URL to Jira's logout service URL and test both SP-initiated and IdP-initiated logout.

Step 5: provision users

SSO only handles sign-in. Users still have to exist in the Atlassian organization, and leavers have to be removed. Atlassian Guard Standard supports SCIM for automated provisioning and deprovisioning. Without SCIM, you can use JIT provisioning, but it requires linked domains and enforcement of SAML SSO on the default authentication policy.

With SCIM, an email change in the identity provider updates the Atlassian account automatically. Without it, a changed email can orphan the account or create a second one.

Testing checklist

1. Open Jira in a private window and confirm the redirect to Casdoor.
2. Sign in with a user whose email domain is claimed in Atlassian.
3. Check that the display name and email arrive correctly.
4. Remove the user from the IdP group and confirm that access is revoked, either through SCIM or by disabling the account.
5. Change a test user's email and confirm that the account is updated or that you have a documented manual process.
6. Test with a user outside the claimed domain and confirm the expected denial.

Common failures

• Entity ID mismatch. The value in Casdoor's Redirect URLs must be exactly the service provider entity URL from Atlassian.
• NameID is a username, not an email. Atlassian matches the user by email. Use the email as the NameID.
• Attribute names are shortened. Claims such as givenname and surname must use the full URI, not a friendly name.
• Unsigned response. Jira rejects it. Leave response signing on.
• Clock skew. Use NTP; a small drift breaks the assertion window.

Casdoor is an open-source identity provider that can serve as the SAML IdP for Jira Cloud and for Jira Data Center, and it also speaks OIDC, CAS and LDAP for the rest of the stack. It is self-hostable for free; Casdoor Cloud starts at $9 per month for a dedicated instance.

Related reading: setting up Casdoor as a SAML IdP, SAML attribute mapping, SAML metadata and SCIM vs SAML.