Starting a discussion thread to see how people are using SAML SSO -
Hi, we are in the process of switching from Jira LDAP with Microsoft ADFS to Jira SSO with Azure AD and wanted to use the out of the box SAML SSO provided by Atlassian.
Initial testing shows a rather large shortcoming for us, for anyone probably, that is the fact that names of users and groups are not returned, but rather IDs and this is not useful for us.
We are currently evaluating third party add-on "User Sync for Jira" from vendor re:solution, because the vendor has the highest ratings and most downloads for their products and it seems to be doing the job for us. We are still evaluating how to deal with 'service accounts' we inherit from LDAP and how to do this with the new setup and I had some weird experience where I was kicked out of the sys-admin group and had to request another sys-admin to add me back; possible related to logging in sometimes via SSO and other times with LDAP still as we have them next to each other.
We also have to check and see if we can disable or hide LDAP login completely and we use the Atlassian SSO together with re:solution's User Sync so we are not completely dependent on a third party solution.
So we have our users login via SSO from Atlassian's SAML SSO and we enrich the user and group data with re:solution's add-on. Does that make sense?
So yes there are benefits to using a third party add-on and yes we prefer to do that because of the additional features which we really require for our setup.
On a side-note I have worked with the Insight Azure module to import users and groups from Azure AD as well and this works nicely.
I was able to set up a periodic import from our Azure AD and this way we can retrieve additional information about our users (such as location, department, manager, etc), but I am still unable to apply this in the way I would like: I was hoping to enrich the user fields (mainly reporter and assignee) to show a hover-over panel with additional details like we do now with the User Profiles add-on from Communardo Products GmbH. I'm still reading up on Inisght's possibilities but so far don't see how this can be used in a way that will help us much. Tips are appreciated for this by the way ;)
Cheers
Interesting discussion, @Kishan Sharma! It'd be really nice to get some first-hand experiences from Data Center customers on this matter.
Our experience in resolution as the marketplace partners behind the most sold SAML SSO plugin for Jira, Confluence, Bitbucket etc. is that most of our Server customers are sticking to our product as they transition to Data Center. There are multiple reasons for this and it’s never easy to generalize. But let me give some pointers to start the discussion. We’ve recently published an article with Frequently Asked Questions gathered in partner and customer trainings on the comparison between our SAML SSO plugin and Atlassian’s.
Often times, it’s simply a matter of trust and efficiency. Customers have interacted with us in support calls, know what the product can do, and don’t want to go through the pain of replacing it, even if they could potentially save a couple thousand dollars. For a big corporation, a small saving like that can be of little value, and even procurement folks are starting to accept that as part of their vision.
Very frequently, customers don’t really have much of a choice. — They have very specific requirements in their configuration, and they know that the Data Center SAML SSO can’t accommodate them. These can be related with security, with matching their existing identity infrastructure, or with customizations that are required in order to make Atlassian applications work as expected. For example, they may need to synchronize information about who is the supervisor of each user from the Identity Provider to have a proper validation process in place.
SAML SSO is not only about having a single, secure password to authenticate across applications. It’s also about putting in place robust user management processes that rely as much as possible in automation and deflect manual work. Our plugin becomes irreplaceable when you start looking at the entire user lifecycle (as opposed to simply provisioning users). Want to design a simple process to deactivate inactive users? Don’t look at Data Center.
Of course, sometimes the customer is happy with a simple SAML SSO implementation, and in those cases, the Atlassian native version works out of the box and we lose. But those simple implementations are relatively rare in the Data Center world, where we’re looking at thousands of users and complex architectures.
That’s my two cents, I’m looking forward to more personal, individual use cases! By the way, this might be an interesting discussion for the Enterprise group!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thank you @Capi [resolution] for your response, some interesting points there.
Small/Large organizations can both benefit from a third party plugin if they don't want to take overhead of setting up identity infrastructure and configuration part themselves.
A plugin is obvious choice if there are certain requirements that cannot be accommodated by the Data Center SAML SSO. And having complete user management lifecycle in place comes in very handy for managing new joiners/leavers etc. which otherwise could be a manual and time consuming process in some cases.
The Atlassian native SAML SSO is relatively easy to setup/implement and most customers are happy using it depending on their requirements.
You are right, I should post something similar in Enterprise Group as well :)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.