You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
Is there a solution for the following scenario?
We use CROWD, but I don't have to use CROWD for the SSO SAML login.
Solution Option 1:
Currently, I can add AD directory to CROWD, but when the users are redirected, they are asked for login. This is last resort solution. We would prefer if the users can login automatically.
Solution Option 2:
I was wondering if this JIRA app might be the solution.
I would use SAML as secondary login, hoping that users accessing JIRA directly being in CROWD directly would login as normal, and users coming from the LANDING PAGE would login with SAML.
Would that work?
Is there any other solution?
Chris, thank you for the detailed answer.
One more question regarding the new CROWD data-center version. Not sure if you are aware, but that new version seems to provide SSO capabilities.
How that new CROWD SSO is different from your SAML plugin? Would I be able to do the same with the CROWD data-server version?
Hi Jiri, (autocorrect always wants to turn your name into Jira :-))
yes I know about that functionality and it's not really going to help you in your scenario.
The feature you describe is that Crowd will act as a "basic" SAML 2.0 Identity Provider. It does that to show a single Login Page across all the Atlassian Applications.
So the functionality is still really there that you login into the Atlassian Application once, not to federate towards a AD FS or other SAML IdP.
Just on a side note, our plugin can handle multiple IdPs so should you need to use Crowd for any other User Groups (not in your AD for example), then we can connect to the SAML 2.0 functionality of Crowd as well (on top of AD FS for example).
But from your description it doesn't sound that that would be necessary in your case.
Have a great weekend!
That's great - feel free to give some of the others a spin too if you like.
The Setup you need is documented in this Step-by-Step Guide with our plugin: https://wiki.resolution.de/doc/saml-sso/latest/all/setup-guides-for-saml-sso/microsoft-ad-fs/ad-fs-with-ldap-user-directory
Or if you just want to have a quick look there is also a Video Tutorial, which would give you a impression: https://youtu.be/CiOAO0vGyzE
Consider to accept the answer if that gives you what you need & the community moderators are always happy if threads get marked as closed once they are complete.
Chris one more question in regards to step:
Is it possible to configure it that unauthenticated users will be presented with login.
We have some users in CROWD directories and these users should use their CROWD login. We would like to have the SSO/SAML from AD FS only for the users who are redirected from the Landing Page.
it's not that simple.
Seen from Jira every User is unauthenticated in that case when the User hits Jira for the first time. There is no simple Way to indicate to Jira that the User is already authenticated by AD FS.
It means regardless if the User is authenticated via AD FS already or if it's a User that is supposed to login via Username/Password - it'll look the same to Jira (unauthenticated).
There are multiple Ways you could deal with this:
One Way is to create a special link that you publish on the Portal you mentioned.
If you use a link like
then the User gets redirected to AD FS & redirected straight back with the SAML response to be logged in.
If a User to just your JIRA URL he sees the Username / Password login.
The downside of this Solution is that it doesn't work well for deep links. So if you are 100% sure your AD FS Users only login via the Portal Link (as opposed to deep links in eMail or Bookmarks or typing the base URL in the Browser) - then this could be a Solution.
You can also do the reverse - everyone by default get redirected to AD FS unless he is using a special link like:
So if you only have very few crowd Users and the vast majority is on AD / AD FS then this may be a resonable solution.
If you have many Users on AD FS & and many in crowd, then using somthing like an IdP Selection Page would probably the best solution.
So instead of automatically redirecting the User to AD FS, we will show them a selection Page. Where the User can choose to be redirect to AD FS or login with Username / Password.
This Page is fully customisable so you can put it into a language/verbage that makes sense to your Users.
The Selection will get saved in a cookie, so that you can automatically redirect the User to the same choice in the future.
We actually have a short Video Tutorial showing some of these methods (and some others) that our Plugin can do. Maybe worth having a look at this - https://youtu.be/DoNir7eN87o
Hey Chris. Thanks a lot for the help.
I am happy with a solution:
Users will either login through the 3rd party portal or through JIRA login interface.
If they login through 3rd party portal, they will be able to use SSO/SAML to JIRA using the redirection link.
I think that is possible, right?
Yes that is possible.
Just think through all the Situations how people could try to access your Jira, so that you don't miss any paths. In particular for example Servicedesk Mail notifications. You don't want the Users clicking on the EMail notification ending up on the Login prompt & not knowing what to do.
Hi @Jiri Kanicky ,
As stated above, SAML will be one of the best solutions for your use case. In this case, the user doesn't need to reauthenticate themselves to access JIRA Service Desk as they've already authenticated by ADFS while accessing the landing page.
There are multiple SAML SSO plugins on the Atlassian Marketplace, which you can use to achieve your use case. Here is one of them from miniOrange(one of the top SSO vendor in Atlassian Marketplace).
Is it possible to configure it that unauthenticated users will be presented with login? We have some users in Crowd directory and these users should use their Crowd login
==>Yes you can use SAML's Passive SSO concept here. With the Passive SSO, If an unauthenticated user tries to access JIRA, will be redirected to IDP and if his IDP session already exists, he will be logged in to JIRA and if not, then instead of staying on the IDP's login page for authentication, he will be redirected back to the JIRA's login page, where he can authenticate himself with his JIRA/Crowd credential.
Feel free to reach out through our customer portal for more details.
Hi @Jiri Kanicky
Another option that can be relevant here is to apply two step login where the login screen ask unauthenticated users for the username only (not password). Then based on the user directory the user belongs to, the authentication mechanism is chosen. Users in a Crowd directory can be asked for password (login as normal), while others are redirected to a SAML idp to complete the authentication there.
The figure below shows how two step login can look in Jira.
If you have ADFS, you can also apply kerberos to automatically authenticate users give them a login-free access to Jira / JSD. You can combine kerberos with both SAML and traditional login to optimize the login experience for all users.
As mentioned by @Lokesh Naktode_miniOrange and @Christian Reichert _resolution_ , there are many good SSO apps on the marketplace. Full discosure: I work for Kantega SSO, and our app supports both two step login (with user directory redirection to SAML providers) and kerberos.
How does you add-on works with CROWD?
Where are the users created when using SSO/AD+FS?
The Kantega SSO Enterprise app is compliant with CROWD user directories.
With SAML SSO and AD FS you can provision users in two ways
1) Just-in-time provisioning - Allows you to add, update and activate users on the fly when they log in. This approach requires that the users exist or can be added to the Jira internal directory.
2) Synchonized user directories (i.e. AD sync in CROWD Directory as you mentions). There are several advantages of this approach, including that users are removed from CROWD / Jira when they are removed from AD (less duplicate user record maintenance).
Note also that if you have AD FS you can also benefit of setting up Kerberos to AD. This works well together with SAML and allow users on trusted networks to be logged in automatically without being exposed to any login dialog at all. We are happy to discuss your case and help you configure the right setup for your needs, and you can book such a screen sharing session with us here: https://kantega-sso.youcanbook.me/