This article is Part 5 of a 5-part series on Atlassian Single Sign-On (SSO). Read the rest of the series: Part 1 | Part 2 | Part 3 | Part 4
Praecipio has partnered with our friends at resolution, an Atlassian Gold Marketplace Partner based in Germany that specializes in software development and network security, to bring you a series of blog posts about how to successfully implement single sign-on (SSO) with Atlassian tools. With more than 7 million users from 58 countries, resolution is the market leader for Atlassian Enterprise User Management Apps.
In the last article of our series on the journey to Atlassian SSO, we followed the steps of ACME, a company with large instances of Jira and Confluence on prem, planning a migration from AD FS to Azure AD.
In particular, we had a detailed look at:
- How users from the Atlassian directories can be seamlessly migrated into Azure AD building a no code integration with User Sync
- How users can be mapped between Azure AD and the Atlassian applications even if usernames don’t match
- How to connect users from different organizations (ACME and CU.com, a consultancy firm) each with its own Identity Providers, both for authentication and provisioning purposes.
In order to complete the setup, however, ACME needs to add some restrictions to CU.com users to answer the following questions:
- Who at CU.com must have accounts in ACME’s Jira and Confluence?
- How long should access be retained?
- How should access be revoked?
Let’s look at how to automate the process for onboarding and offboarding consultants so that these are the answers:
- Who should have accounts?
Only contractors assigned to active projects. - How long should access be retained?
Only for as long as the project is active. - How should access be revoked?
Automatically, as soon as the project concludes.
How to provision only contractors assigned to active projects
Let’s quickly recap what ACME needs to set up:
Challenges
- Access to ACME’s Atlassian tools should only be granted to consultants who have been assigned to specific projects.
- Consultants have a quick turnaround. It’s important to give them access quickly and deactivate them as soon as their assignments conclude.
- It’s also vital to ensure that consultants only occupy licenses of the Atlassian products while they're on an active assignment.
Implementation Steps
The approach has four steps:
- The group that gives consultants access will be operated from Contractor’s Okta and filtered in ACME’s User Sync connector.
- Specific project permissions and roles in the Atlassian applications will be managed locally. This has important implications, as the Okta and local group settings must coexist and not overwrite each other.
- The synchronization between Okta and ACME will be scheduled to run every night (but users will also be updated when they log in, eliminating waiting times entirely).
- As a result of the synchronization, consultants who are no longer on active assignments will have both their access and their licenses revoked.
Here’s the walkthrough:
1. In the Okta User Sync connector configured in the section above, ACME adds a filter so that only consultants in a specific group are passed and enabled in Jira- Go to User Sync > Azure AD Connector > Edit > Advanced Settings
- In Groups mandatory to sync a user, create a new entry
- Add the group active-acme-jira-project
- every time the contractor logs in
- with each user sync.
However, we can protect groups in both contexts from the User Sync connector:
- To protect the groups in the connector, we go back to the Advanced Settings and add all the groups used to permit Contractor Unlimited consultants in the Keep these Groups field. Note that you can either include every group, or regular expressions if there are any patterns.
4. Finally, we will tell the connector to deactivate contractors who have finished their assignments so that they don't consume any licenses.
- In the cleanup behavior dropdown, select disable users.
What does this last step mean? Consultants will be automatically deactivated in Jira and Confluence following this process:
- When an assignment concludes, the consultant is removed from the active-acme-jira-project group
- At 3 am, the user sync connector runs
- The user is removed from the active-acme-jira-project group in Jira, together with any other changes.
- As a consequence, the user is deactivated in Jira.
Bonus trick: With the right SAML setting, if the consultant logs into Jira after they have already been removed from the active group, the login will succeed but will also result in deactivation.
We reached our destination!
Congratulations! You have finished the journey to Atlassian Single Sign-On! Hopefully, by this time you are on your way to an implementation that will last for many years to come.
The sample implementation in the last two articles has offered a selection of very popular options among Atlassian on-prem customers. As you have seen, User Synchronization is very often a cornerstone of the implementation, since it permits the use of the Identity Provider as a single source of truth to automate user on- and offboarding. At the same time, it’s compatible with multi-IdP setups and access provision to partner organizations.
However, the example is just that – an example. And it might be very different from what you need to solve.
How can we help you?
If you have any doubts or need help with advanced technical issues, there are several next steps.
- Here at Praecipio, we'd be happy to help you get up and running.
- If you need help configuring the resolution SAML SSO application or the User Sync standalone that can be combined with the Data Center SAML, resolution provides free remote training sessions every day.
