Can Crowd be used to SSO Customers (domains not owned by us) into Service Desk from our SaaS App?

[Audra Webster]

We are trying to implement Service Desk but we have hit a brick wall in that we cannot figure out how we can SSO our customers into Service Desk. 

Our Use Case:

1. We are a SaaS web application

2. Our users are employees of businesses who have purchased our application

3. Our users already have accounts logging them into our web application

4. We want to offer service desk as our "contact support" tool

5. We do not want our customers to have to login again to service desk after they have already logged into our application (we already know who they are)

Ideal Workflow:

1. User logs into our application

2. User clicks on "Contact Support" link

3. Service Desk opens allowing them to submit a support request

We originally thought we could use SAML for this but it appears that Atlassian requires that we own the domains of the email addresses of all users signing into Service Desk. We do not own these domains since they are owned by our customers. It would not be scalable for us to work with every customer's IT department to try to get certificates for each of their domains so that we can do SAML. Thus, I'm researching alternatives.

Can Crowd be used to SSO from our application into Service Desk without us having to own the domains of the email addresses being used by our customers?

Thanks in advance!

[Bruno Vincent · Accepted solution]

Hi @Audra Webster,

Yes, Crowd would be fine for this but as @Christian Reichert (resolution) stated you would need Jira Server or Data Center edition, not Cloud.

[Christian Reichert (resolution)]

@Bruno Vincent - however crowd doesn't support SAML and the Way I understand her Question is that they have the Users already on their own SaaS application, which acts as an Idp. So unless I misunderstand her, I don't think Crowd is a good solution here.

[Bruno Vincent]

@Christian Reichert (resolution), Crowd would be just fine. No need for SAML here. The workflow would be:

1. User logs into the Saas application

2. Saas application asks the Crowd server for a Crowd SSO token for the user: https://docs.atlassian.com/atlassian-crowd/3.1.1/REST/#usermanagement/1/session

3. Saas application sets the Crowd SSO token in a cookie

4. User clicks on "Contact support" link, Crowd SSO token is sent and SSO magic occurs.

The only requirement is that the Saas application and Jira are on the same domain (e.g. saasapp.whateverdomain.com and jira.whateverdomain.com)

[Christian Reichert (resolution)]

@Bruno Vincent - Fair point.

@Audra Webster So if you are going for Server, you should have two possible routes now.

One via Crowd (you need to add some REST calls to your Application, to create/update Users & the SSO Token) or one via SAML where you can do authentication & just in time provisioning of Users during login.

Pricing wise there shouldn't be much of a difference between either, so it's probably more of a Question of what is easier for your team to implement.

But all on Server/datacenter, not on Cloud.

[Audra Webster]

Thanks, @Christian Reichert (resolution) and @Bruno Vincent

This was hugely helpful!

We initially were going to go with the Cloud version of Jira/ServiceDesk, but we are open to switching to the on-prem version if needed in order to get SSO working.

[Christian Reichert (resolution)]

Hi Audra,

you never explicitly mentioned if you are using Jira Cloud or Jira Datacenter (probably not Server due to you referring to Atlassian SAML). Both support SAML out of the Box.

At least for Server & Datacenter there are App available on the Marketplace, like ours - which don't have the "Domain" requirement.

So if SSO is essential to you (and I don't know of a Way to achieve what you need on cloud) you may want to consider Jira Server/Datacenter. There are also hosting companies around, which at least take the hassle away of you running your own Jira. Not the exact same as Jira Cloud, I appreciate that but maybe a "good enough" solution to your requirement.

Cheers,
Christian