Atlassian managed accounts and Jumpcloud integration

[Lucas Hornung]

Hi there!

We are considering to integrate our company's Atlassian cloud products with our jumpcloud account using Atlassian access. As this endeavor raises a couple of questions, I was hoping you might be able to help me find answers:

1. Would there be any immediate changes regarding any of the existing access policies within the integrated Atlassian products? E.g. would some or all of the product's access policies be synchronized among each other once they are administered via Atlassian access?

2. Is it possible to manage the Atlassian product's users and policies independently of one another via Atlassian access, or would the same policies apply across all products?

3. Would we be able to define global policies, which would apply for a certain user group across all products using Atlassian access?

4. Is there any way to test the Jumpcloud integration for some of the users first, before regulating all user accesses via Jumpcloud?

5. Will new atlassian users have to be added to Jumpcloud in addition to Atlassian, once the integration is complete?

Please don't hesitate to ask, should any clarification be needed for any of the questions.

[Dave Meyer · Accepted solution]

Hi @RMA ,

A couple points I would make in response to your question:

1. Once a user has logged in, they will have a session cookie, so in the case of an SSO outage most users would be unaffected.
2. We consider login and authentication (including SSO) our most critical service after our infrastructure itself, so we strive for extremely high availability. Here's the incident history for Atlassian Access so you can see for yourself: https://access.status.atlassian.com/history
3. In the case that SSO were to be unavailable for an extended period of time (either because of an error on the Atlassian side or an outage in Azure AD, which is hopefully just as reliable), then yes, you can disable SSO for all users. If you do, login will revert to a standard email address + password. For users that have only ever logged in through SSO, they would need to go through the Reset Password flow to set a local Atlassian password.

Hope this helps.

Dave

[RMA]

Thanks Dave,

On point 3, would we need an account that is not SSO enabled to be able to log in?

So it should not be part of our normal domain? Like a personal email address?

This is if the session cookie expires and somehow the connection between the Azure AD and Atlassian Access fails.

Thank you!

[Dave Meyer]

@RMA yes, we recommend this as a precaution. Usually not because we are worried about the SAML connection failing, but we do see people make mistakes during the initial SAML configuration setup and end up locked out. So it's a good idea no matter what :)