I'm admin on a Jira Data Center instance with several hundred users. So far we've gotten away with manually provisioning users in the Jira Internal Directory and using G-Suite for SAML/SSO.
We've decided to move to Okta for SSO and Universal Directory. We've already spun that up and gotten all of our employees into Okta, and connected Slack and G-Suite to it. The next step is to connect Jira to it. The implementation/setup of this seems straightforward, but I have some questions about how things will work one it's all set up, mostly in regards to groups, roles, etc. I think I know how it will work, but I'd like some confirmation if anyone has gone though this before. Also I think these are mostly the same questions I would have connecting with any kind of LDAP, but Okta might have it's own peculiarities. What's the best way to ensure that when everyone starts logging in through, for lack of a better term, their Okta managed user account, they retain all of the group/project role membership they had from their Internally managed user account?
Based on this doc: https://confluence.atlassian.com/adminjiraserver/connecting-to-an-ldap-directory-938847052.html
We will be connecting Jira to Okta as an OpenLDAP, using 'Read Only with Local Groups', and we will place this connection ABOVE the Jira Internal Directory. This does mean that users will exist in both directories, if I understand things correctly. So, lets say a user bsmith tries to log in. He logs into Okta, then clicks on the Jira application and is signed into Jira via SSO. When this happens:
Hi @Taylor Huston,
Congratulations for moving to Okta, we have a lot of customers at resolution and it's a fantastic solution for managing users.
Before giving a final answer, can you please confirm that you are using the preinstalled SAML SSO capabilities of Jira Data Center to connect to Jira?
If that were the case, the answers would generally be:
1. No, whichever groups are sent from Okta will overwrite local group memberships. That´s just how the Data Center Just in Time provisioning works. It will remove any groups in the local users that don't appear in the SAML response, and add all the groups in the response, creating them if necessary.
2. You need to make sure that you match the username coming from Okta exactly with the local Atlassian username. Otherwise, you will have duplicate users. If there is a match, you won't have to worry.
3. Provided that there's a match and you don't have a duplicate bsmith, assignments mentions etc will work perfectly.
Again, consider these answers provisional.
For full disclosure, I work at resolution, a Gold Marketplace Partner and manufacturer of the leading SSO solution for Server and Data Center applications (here is the link for Jira). If you feel that the DC functionality does not cut it for your needs, feel free to schedule a support session with us to explore your use case.
You can also see the Okta configuration guide with our product here.
And here you have some more info on attribute transformation and deciding if the local groups should be overwritten.
Catch up with Atlassian Product Managers in our 2020 Demo Den round-up! From Advanced Roadmaps to Code in Jira to Next-Gen Workflows, check out the videos below to help up-level your work in the new ...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events