SSO integration with OneLogin

[Marco Cuentas]

I'm creating an action plan to configure and enable SSO for Atlassian (Jira). My IDP is OneLogin. I'm reading through a bunch of documentation and it all makes sense, hoping the UX is not as bad as others mentioned. However, we have an internal self-evaluation before we proceed with SSO integrations. Some of these questions are not 100% clear to me so I would love it if someone could guide me and even validate if these Q's are relevant during this process:

Questions to Research Yourself:

1. User Management:
   • How are user identities and roles managed within the application?
     • Understand how the application handles user roles and permissions and how these will map to OneLogin’s identity management.
2. Testing and Rollout:
   • What are the best practices for testing SSO integration with the application?
     • Research best practices for testing SSO integrations to ensure a smooth rollout.
3. Fallback and Recovery:
   • What fallback mechanisms are in place if SSO integration fails?
     • Investigate how the application handles SSO failures and recovery options.

Questions to Ask the Support:

1. Admin/Account Owner Identification:
   • Who is the Admin or Account Owner who can assist with the SSO integration?
     • Identify the person responsible for administrative tasks related to SSO.
2. SSO Testing and Enforcing:
   • Can we enable SSO for testing before fully enforcing it?
     • Verify if it’s possible to enable SSO in a testing environment or for a subset of users before full deployment.
3. Selective Enforcement:
   • Can SSO be enabled and enforced initially for only a few users?
     • Check if you can roll out SSO to a small group of users before a broader implementation.
4. Enforcement Authority:
   • Who can enforce SSO: the account manager, account owner, or IT team?
     • Clarify who has the authority to enforce SSO settings and changes.
5. Fallback Plan for Issues:
   • What is the fallback plan for SSO integration issues?
     • Discuss procedures for handling integration problems and who has the authority to reverse or modify settings.
6. External Users Access:
   • Are there any external users who need access to the application?
     • Confirm if external users are involved and if additional configurations or collaboration emails are required.
7. Integration Support:
   • What kind of support is available during and after the integration process?
     • Inquire about the types of support offered, such as technical assistance, troubleshooting, and post-deployment help.

[August Heltne - Kantega SSO]

Hello @Marco Cuentas,

I'll do my best to answer the questions here. I am familiar with SSO, but I am not very familiar with Atlassian Guard so I would recommend double-checking Authentication policies within your Atlassian Guard to ensure that they work as I believe they do.

1. How are user identities and roles managed within the application?
   • I would recommend reading this page for more information about how users and permissions are handled in Jira: https://www.atlassian.com/software/jira/guides/permissions/overview#what-are-users-and-groups
2. What are the best practices for testing SSO integration with the application?
   • This one is really depends on what Atlassian Guard offers for testing the SSO implementation, but both question 5 and question 6 are examples of good practice when it comes to testing and rollout of the SSO integration.
3. What fallback mechanisms are in place if SSO integration fails?
   • An SSO login can fail for any number of reasons. For example, if a user logins in with SSO, but lacks the permission to access Jira, how do you handle this? Do you have a fallback mechanism like logging in with traditional password or another way to ensure that Atlassian users are not prevented from working?
4. Who is the Admin or Account Owner who can assist with the SSO integration?
   • When configuring an SSO for Atlassian in a larger organization, you will commonly have two teams interacting, the identity provider team and the Atlassian product team. Since the question is for OneLogin's point of view, the answer should be the person in charge of the SSO integration in the Atlassian product.
5. Can we enable SSO for testing before fully enforcing it?
   • I believe Atlassian Guard supports testing Identity providers with Authentication policies as mentioned on this page: https://support.atlassian.com/security-and-access-policies/docs/configure-saml-single-sign-on-with-an-identity-provider/
6. Can SSO be enabled and enforced initially for only a few users?
   • Similarly to the question above, this is about mitigating risk when starting to use an SSO. For example, if you turn on SSO authentication for a few users in the IT team, a few users in Marketing, and a few users in R&D, then they will likely encounter any permission issues and similar that you were unable to discover during testing, while still letting the majority of users use Jira without issue. Like with question 5, I believe that this can be achieved with Authentication policies.
7. Who can enforce SSO: the account manager, account owner, or IT team?
   • Who is in charge of the SSO configuration? As mentioned in question 4, configuring an SSO is commonly a task where two teams cooperate, so it is helpful to have a person in charge that both teams are aware of. Given that the SSO configuration primarily affects the Atlassian users, I would suggest giving this responsibility to the IT team in charge of the Atlassian instance.
8. What is the fallback plan for SSO integration issues?
   • If you run into issues with the SSO configuration, how do you solve them? For example, if your SSO stops working one day, who has the authorization to modify the SSO configuration to get it working again, and how do you ensure that your users have access to your Atlassian instance in the meantime so that users are not hindered in their work?
9. Are there any external users who need access to the application?
   • External users are a challenge when using SSO as your primary authentication solution since they do not exist within your organization, so you'll have to handle it another way. If you expect that external users require access to your Jira, then you should also make a plan for how you grant them access to your Atlassian instance.
10. What kind of support is available during and after the integration process?
    • I believe that when using Atlassian Guard, this would be Atlassian support. You can find more information here: https://confluence.atlassian.com/support/atlassian-support-offerings-193299636.html