Is Atlassian Access required for JIRA Cloud if we integrate with Okta?

[Jeanne Howe]

We have JIRA and Confluence integrated with Okta. The integration was established by the previous administrator. I do not know if Identity Manager was used to create this integration.

I just received an email stating that our Access Manager trial was coming to an end. I do now that Access Manager is the "rebranded" Identity Manager. What I do not know is, is it required for the integration between the Atlassian Cloud apps and Okta?

[Rodrigo B. · Accepted solution]

Hi @Jeanne Howe,

If the integration was done using the SAML feature, then it's done through Atlassian Access as this feature is only available on the product, you can check on that by going to your Atlassian organization on admin.atlassian.com and clicking on the SAML single sign-on, if the feature is enabled and there is a configuration there, you are using SAML.

Another way to quickly confirm this is if you go to id.atlassian.com and once you type your email address, it shows the Opening your single sign-on provider message.

Thank you & best regards,

Rodrigo Becker
Atlassian Cloud Support

[Jeanne Howe]

Rodrigo,

When I go to id.atlassian.com I do see the Opening your single sign-on provider message.

So, while I continue to dig into this, I will assume Atlassian Access was used. But that leaves me with a couple of questions.

1. If we do not use the SAML single sign-on feature, does our Okta integration still work?

2. Prior to starting the Atlassian Access evaluation, I do not see any billing for Identity Manager. Is this an indication we were not using it, or is it an indication that, what was once included in our subscription, is now an added cost?

[Rodrigo B.]

The Atlassian Access subscription will be separate from your Cloud site subscription, you can check it on the Billing menu on the admin.atlassian.com as well to see how much is the estimate and when your trial will end.

The SAML integration's scope is to force users to authenticate through your Identity Provider (Okta) as well as sync profile information for full name and email just-in-time (on login), if you disable SAML, both of these features will be lost.

Let me know of your findings!

Rodrigo Becker
Atlassian Cloud Support

[Jeanne Howe]

OK, so i f we are ok to not have the profile sync, is an Okta integration possible without Access Manager?

[Rodrigo B.]

It's not possible, the integration is done using the SAML feature, without that, you would lose both enforced SSO authentication and the profile sync, SAML is the bridge between your Identity Provider and your Atlassian organization.

Okta does provide an unsupported method by using SWA protocol instead of SAML, you would need to seek for their assistance to make this integration though. By standard, it won't enforce the authentication by SSO, but Okta did create a plug-in that would mimic the same behaviour as you can check here:

• https://support.okta.com/help/blogdetail?id=a67F0000000XZeMIAW

Still, it's not the same security policy, the log in will happen using the Atlassian account's credentials, not Okta's, and users without the plug-in will not be prompted to log in through Okta.

Rodrigo Becker
Atlassian Cloud Support

[Adrian Ang]

Hi @Rodrigo B., I am using KeyCloak as my SSO provider. If we integrate with Access, does it means that if a user is disabled from my SSO side, the same user will be:

1. Denied login ability in Jira

2. License seat in Jira is reduced by this user count?

I suspect (2) is not handled and the license will still be consumed in Jira.

[Rodrigo B.]

Hi @Adrian Ang,

Your suspicion is right, unfortunately the user being disabled on the SSO will not cause it to be disabled on Jira as well, the user won't be able to access your Jira anymore through SSO, but the license seat will still be used.

To allow this kind of synchronization, we are developing the necessary means for SSOs to perform these actions, they are the SCIM APIs, these APIs will allow such operations to be done by the SSO/Identity provider, the following feature request is being used to track it:

• Provide SCIM API's for manage Atlassian account users

Once they are available, our supported Identity Providers will be already prepared to use them on the integration, while unsupported ones (like KeyCloak) will need additional configuration effort and their support to see the feasibility of using them as well.

The SCIM APIs project is a high priority for us, since it allows improved capabilities for user management and complements our Atlassian Access product's feature for SAML.

Thank you for bringing this concern to the table,

Rodrigo Becker
Atlassian Cloud Support