In October 2016, we launched an add-on that would allow our Jira Service Desk Data Center offering to support SAML single sign-on. We've worked hard to bundle this with Jira Service Desk so that it works straight out of the box. From Jira Service Desk 3.3, you can now link your Data Center licensed instance to your existing supported Identity Provider (IdP), and provide your users with a single sign-on experience. This reduces the number of passwords a user needs to remember, and provides extra security for your instance.

Please note that this is only available for Jira Service Desk Data Center, not Jira Service Desk Server.

SAML SSO for JIRA Data Center applications & Release notes

Didn't work for us.

Thanks Matt Zuba, I just applied your modification on our instance and it worked. awesome work !

I've been able to mostly solve this for our Server implementation that is using Okta's Jira Authenticator.  Here are the basic steps:

1. Edit  JIRA_INSTALL/conf/context.xml
2. Add the following line to this file. Place this above the line containing </Context>

<Valve className="org.apache.catalina.valves.rewrite.RewriteValve" />

1. Create a file named rewrite.config and place it in the JIRA_INSTALL/atlassian-jira/WEB-INF directory.
   1. The final path should be JIRA_INSTALL/atlassian-jira/WEB-INF/rewrite.config
   2. The user that JIRA runs as must be able to read this file. This file should have the same permissions as the other files in WEB-INF directory.
2. Add the following lines to this file:

RewriteCond %{REQUEST_URI} ^/servicedesk/customer(/.*)?/user/login [NC] 
RewriteCond %{QUERY_STRING} ^destination=(.*)$ 
RewriteRule .* /okta_login.jsp?RelayState=\%2Fservicedesk\%2Fcustomer\%2F%1 [NE,R=307,L] 

RewriteCond %{REQUEST_URI} ^/servicedesk/customer(/.*)?/user/login [NC] 
RewriteRule .* /okta_login.jsp?RelayState=\%2Fservicedesk\%2Fcustomer\%2Fportals [NE,R=307,L]

The first rewrite cond/rule pair captures requests that have a destination parameter and the second captures requests without.  Both redirect to the okta_login.jsp page with the RelayState set so that when okta_login.jsp does the POST over to Okta, it will carry the relay state and return the user to the proper page after login.

For those not using Okta and/or their authenticator, maybe this will give some ideas.

I'll caveat this with the fact that my org's Jira instance is in its infancy, barely into production use, so I'm not sure if this covers any edge cases that might crop up in URLs, but I'd love any feedback or corrections if anyone has them.  For why we're using Okta's integration and not others on the Marketplace, the reason is simple - I prefer Okta's method of provisioning and assigning groups over some of the other solutions out there (User Sync, for example).  I don't mind having to modify files during upgrades, it's very little and the above will just be added to those steps.

There are requests for SAML integration dating back to 2007. Atlassian will never add it.
Atlassian recommends to use Third-party Plugins.

Is there any workaround that we an perform for this ? 

We are redirecting any service desk portal url requests to the base Jira url so users get single signed on, but we need to send them back to their initial request url after being signed on. How can we do this ?

@Avinash Singh

We have in our 7.13 Datacenter instance Settings - System - SAML Authentication. It used to be a separate free Atlassian add-on, but now it is ootb as far as I know. I googled and found https://confluence.atlassian.com/enterprise/adding-saml-integration-to-your-existing-user-management-infrastructure-861244976.html. Looks like it is datacenter only.

hth

Thanks @Martina Riedel, where is this setting that you are referring to ? Or is it through a plugin ?

We have Jira Software and Jira Service Desk on the same instance. We have integrated with OKTA to provide SAML and SSO capabilities.  Users accessing a service desk url when unauthenticated bypasses the Okta authentication and provides a services desk portal login, which is a security problem for us.  

This functionality is critical and will move us away from Atlassian.  I don't understand why it has not been done yet.

The Resolution SAML-Addon (DISCLAIMER: I'm working for Resolution) (https://marketplace.atlassian.com/plugins/com.resolution.atlasplugins.samlsso.Jira/server/overview) supports SAML SSO for both agents and customers.

The solution from Kantega (https://marketplace.atlassian.com/plugins/no.kantega.kerberosauth.kerberosauth-plugin/server/support) also provides support for this.

MiniOrange just updated their SSO product... it now appears to have the option to turn SSO only for Agents.  Might be worth trying.

Like others, this was a show stopper for us. I tried hard to choose JSD + Confluence over competing alternatives, but the lack of simple SSO/JWT integration was a deal breaker and we ended up choosing a competitor's product. I look forward to the day we can reevaluate JSD and choose it!

(Oh, and the inability to have anonymous users view the KB articles in the portal which JSD Cloud does offer)

Adding my $.02 that this functionality is critical for today's business-class/secure environments. 

One of the primary value propositions for Service Desk, is to handle customer requests and issues. This is a significant gap in functionality that I would expect out of the box for this kind of system. This forces us to consider other products as the solution.

We need SSO for Service Desk also. We were partially set up on the Jira cloud service but now we are having to start over looking at other software solutions because SSO is not available for Service Desk in the cloud version or the on-prem version. We cannot use SAML because we don't own our customer's domains (obviously).

This seems to be getting traction again and I wanted to make sure I added my vote for this. I don't understand why I can't connect JSD with the seraph for JIRA since it is loaded as a plugin for JIRA not even it's own application. This needs to happen!

Chiming in on a nearly, year old ticket, any reply would be appreciated. SSO throughout Atlassian's repertoire is a no brainer. We're paying a small fortune for Data Center, and this is what we get?

This is a huge pain point for our customers. I wish this issue and the issue of customer phone numbers and locations would be addressed. These are deal breakers for a lot of organizations. I can't believe that they're not being addressed.

Guys,

we really need this. It's a important feature to our company. 

Please make this integration a bigger priority for you guys. [2]

Regards.

SSO for JSD is very crucial to our company. We recently implemented JSD and expected it to be built in. After completing the integration we found out that it was not. We are in the process of determining whether or not to move again to another ticketing system because of the lack of SSO.
Please make this integration a bigger priority for you guys.

Really? It seems to me that Crowd is another, much newer, issue that is blocking this one somehow, but Crowd wasn't brought up in this issue (JSD-630) until you just mentioned it. We too would have very much liked to have integrated our own authorization with Service Desk. Specing LDAP would be out of scope for a lot of implementations and certainly not required by this issue whereas the JWT method highlighted by Amy is actually the one I think most people here are asking for. I suppose if Atlassian is going to favor Microsoft platforms over anything else, LDAP makes sense, but that's rather limiting. Imagine an app written in Ruby and deployed on Heroku using OAuth2 for authentication. LDAP would be entirely unwarranted.

This issue was actually the deal breaker for us when we were deciding on a customer support platform two months ago. If a user had an issue on our site and we redirected them to another login, the would likely try their credentials from our site users being users. That would fail and raise frustration levels. Then they'd have to sign up for ServiceDesk and wonder why they have to sign up again just to ask a question, and actually we had the same reaction. After much deliberation, our org chose to go with Zendesk for pretty much only these reasons. We still use Jira and love it, we'd just love it more if we would have had JSD integrated.

jussi.saren1966833000 JSD works out of the box with external logins if you connect it to an LDAP source – This issue is specifically about the lack of support for Atlassian Crowd's SSO feature. If you use SSO, you cannot use additional directories attached to JIRA – But using Crowd for JSD customers is a non-starter for my clients, as they don't care for SSO or to pay for their account via Crowd licensing.

This is also something that we really need. We are currently evaluating different options for a service desk system. JSD looks and feels great. And because we have used other Atlassian products (SourceTree, JIRA, Confluence, Bamboo and Bitbucket) earlier that guides us to append JSD to our tool arsenal.
Almost the only lack (that JSD has in our point of view) is to allow our customers to use the service desk without having an extra log in. If that ability existed, then JSD would probably be our choice.

SSO for Jira Service Desk please!

We are also looking to get Service Desk SSO (with Okta) working for our environment.
I'm pushing for this feature to be developed.

That JIRA Servicedesk doesn't respect a custom seraph is blocking the use of resolution's SAML SSO Plugin https://marketplace.atlassian.com/plugins/com.resolution.atlasplugins.samlsso.Jira - A major Problem for us.

Here's how Zendesk provides this functionality:
https://support.zendesk.com/hc/en-us/articles/203663816-Setting-up-single-sign-on-with-JWT-JSON-Web-Token-

If JIRA Service Desk allowed us to setup SSO with our SaaS application, it could completely replace Zendesk at our company.

Requirement: My customers can access JIRA Service Desk by authenticating against our application's credentials - when they have an active session in our application, they are therefore also logged into JIRA Service Desk.