Jira Service Management - Portal-only account Single Sign-On (SSO) - Now Available!

[#1]

Jira Service Management external customer SSO is here!

You asked for it - Single Sign-On (SSO) for your external customers is now here!

Starting today you are now able to set up Jira Service Management to allow your external customers to authenticate with SSO into your Help Center.

Here is also a quick refresher on whether your should use internal vs external customers for your Jira Service Management site.

---

How does external customer SSO work?

We’ve created the ability to connect an Identity Provider (IdP) with Jira Service Management. We’ll then use your connected IdP to authenticate your external customers when they access your Jira Service Management Help Center. We use the standard SAML 2.0 protocol and rely on your IdP to verify your external customer’s credentials.

With an IdP connected - you’re able to choose which authentication methods are applicable for your end users when they authenticate into your Help Center

• SSO
• Email + Password
• SSO & Email + Password

How do I setup external customer SSO?

Adding an IdP to your Jira Service Management site

1. Subscribe to Atlassian Access for organization.
2. Make sure you're an admin for an Atlassian organization.
3. Follow the instructions on this page to add an IdP to your Jira Service Management site
   • Add an identity provider to Jira Service Management.
   • Note: This is separate and different to adding an IdP for internal users

Selecting SSO as an authentication method

1. Follow the instructions on this page to configure SAML SSO
   • Configure settings to authenticate your customers
2. Use test mode and check your SAML SSO configuration with an account that exists in your IdP
3. Disable test mode and allow your users to authenticate with SSO

---

FAQ

1. How many IdPs can I connect?

You will be able to connect 1 IdP for each Jira Service Management site you have for your external customers. This is in addition to the existing IdP you use for your internal users.

We recommend using 1 IdP for your internal users and 1 IdP for your external customers (2 in total).

2. Will SSO for external customers cost extra for existing Atlassian Access subscriptions?

No. But you’ll need an active Atlassian Access subscription to add an IdP to Jira Service Management.

Atlassian Access is billed based on the existing number of managed accounts you have (e.g. Jira Service Management agents) - external customer accounts don’t incur an additional cost.

3. Do you support SAML Just-In-Time (JIT) provisioning?

Yes! If your external customer exists in your IdP but does not have an account on Jira Service Management yet - they will be provisioned a new account when they authenticate into your Help Center via SSO.

4. Can I sync external customers (Portal-only accounts) with SCIM?

Not yet! But we’re starting active development of SCIM syncing for external customer accounts.

If you’re interested in shaping this feature by providing feedback or testing in the coming months please send an email to jps@earlyaccessprogram.atlassian.net with your contact details and feature requests you’d like to see included.

You can follow our public roadmap here

---

Leave us a comment with any questions or feedback - we’d love to hear from you and how SSO is working!

[Vedant Kulkarni_Trundl]

Finally, I can onboard external users for my customer, thanks.

[Regan Marshall]

This is great. Thanks.

[Mathieu Truchot]

So no need to verify customer's accounts  domain(s) to apply SSO ? If so this is a great news!

[Stacy Clarke]

Yes!

[Brian Simonsen]

That is great. Just what we have been looking for.

[Ash Young]

@Mathieu Truchot correct, no need to verify the external customer account domains.

We continue to recommend you keep your internal verified domain users in one IdP and your external customers in another (two in total).

[Daniel Winter]

@Ash Young is this also supported for the Data Center version? Does this also work in conjuction with confluence. Meaning if a user of our customers is logged in via SSO to JSM are they are also able to access Confluence.

Currently we use JSM and confluecne only internally and we are evaluating options for a Knowlede Base + Help Center for our Customers. 
We are currently favouring Zendesk but with this, it might make sense to evaluate our options. 

[JG Meillaud]

Hi,

ℹ️ Context:

Our external users are in the same Active Directory as our internal users, for us the difference between external and internal is the license for Jira/Confluence.
We do not have Access licenses for our external users.

❓ Questions:

1 - We already have and IDP set up with Azure AD for our licensed users, can we use the same for our licensed and unlicensed users? (and not have to pay Access licenses for unlicensed users)

2 - Can we set up another IDP with the same Azure AD?

3 - If we set up another IDP for our external users and they want to use other Atlassian Cloud product (such as Trello, or be Confluence guests), how is it going to work?

Thanks for your help,
JG

[Regan Marshall]

Howdy JG, 

I have two IDPs setup, one for agents and one for portal only users both in the same AAD. I followed the instructions provided and didn't do anything special.

This works well for us as the two enterprise applications in AAD have different roles applied, ie specific users vs everyone. 

-Regan

[Earl Reyes]

Question. 

We use Auth0 for our application to authenticate our users. Today we administer the accounts manually in Autho, but in the future we want to delegate SSO to our customers so that they can use their access management system.

I am interested in having our auth0 IDP provide single sign on to Jira Service Management's Portal, but am wondering if it will support our future plans to have our clients manage their own access. Is this scenario something that is supported? 

[Ash Young]

Hi @JG Meillaud 

The Jira Service Management "Customer" role for Atlassian accounts does not make an account "billable" for Atlassian Access.

You are able to use Atlassian Access SSO for all your - as you describe "internal" & "external" users.

You do not need to use a Portal-only customer account for your "external" users.

---

You simply need to:

1. Provision all your "external" user with an Atlassian Account
2. Grant your "external" users the: Jira Service Management "Customer" role

After completing these steps - your "external" users will be able to SSO into Jira Service Management and raise tickets in your helpdesk.

These "external" users will not be charged for Atlassian Access if they only have access to Jira Service Management in the "Customer" role.

If in future they are granted paid licences (e.g. Jira Software, Confuence), they will become billable for Atlassian Access.

---

Thanks,

Ash

[Ash Young]

Hi @Earl Reyes 

I'm not clear on your specific scenario. Would you mind providing a more detailed example of how you and your clients use Jira Service Management and what functionality you're looking for?

Thanks,

Ash

[Murthy A M]

@Ash Young 

I see you have mentioned that if we provide customer with JSM Customer role then it would not count for the billable in Atlassian access. 

How does it work in below scenario?

• Lets say if Customer 1 has below, will be considered as billable?
  • Has Jira software access in site 1 - No atlassian access
  • Has Jira service management customer role in site 2 - Has atlassian access

In most cases customer will have access to various other sites and multiple Atlassian products with same email ID, and may not be part of SSO in all sites due to various reasons and limitations. Adding to JSM customer role with SSO should not make him billable in Atlassian access.

Happy to discuss over a meeting if possible.

Regards,

Murthy

[David Conifer Healthcare Solutions]

@Ash Young were running into a situation with this - where we are migrating from Server to Datacenter. The team is applying the new licenses in the current environment to ensure that we have no issues. When doing so - this did create an issue as we went from unlimited licenses to the amount we purchased. 

1. We definitely need to clean up our user base. (in flight)

2. We have MANY "customer" role users - that only open tickets via the portal - these are internal customers - that we give access to the application via interface with our security system. Right now we use Crowd - but will move to OKTA.

The issue is that these customer role users are taking up licenses. My understanding is that these are and should be unlicensed  users. Suggestions on what we can do to resolve this issue. How do we align these users so that they can access the portal to open tickets but remain unlicensed - still using the integration for user administration?

In our case we are very time constrained to make this work.

UPDATE: 

We see using the query  to identify licensed users it's returning 398  - however the UI on the users page  - is showing 1075 users and not allowing us to load the new license keys saying we don't have enough licenses - this seem to be a bug 

@Ash Young Not sure if you can see ticket that was raised...but we opened this given our need to make this happen sooner than later. PSSRV-87026

[Ste404]

Can someone clarify if I am not understanding this correctly or not.

External Portal only customers are generally people outside of the organization who can put in a request to the portal.  Does that mean when I get a new customer putting in a request jack@gmail.com then that would get onboarded to our AD and then Jack uses SSO to log in whenever he needs to check in or comment on his issue/s

Maybe I am missing something with this but just trying to understand the wider benefit to this.

Thanks (sorry for sounding dumb)

[Regan Marshall]

@Ste404 I'm not confident the @gmail will work. We have internal staff as our customers. So there is a small IT and HR team that are the agents, the rest of the organisation are the customers. We leverage our internal identity (Entra) to provide SSO to the customer portal. 

[Ste404]

yeh internal customers are coming through Azure so they are picking up the SSO side of things already.  I was just confused about the SSO for portal only customers side of it and how if differs from using Atlassian Access for customer currently.  Poeple who are customers are sync'd via a 'JSM-Customers' AD group and that group is in the JSM Customer access section.

Can't put the pieces together for true external customers.

[Jason Shawn]

This is a great feature. Thank you!!

Can we customize the SSO login screen (the second screen after the customer puts in their email address)? 

We would like to have the ability to add some text to assist our customers logging in. We are using OKTA as our SSO provider. 

[Ash Young]

@Ste404 @Regan Marshall 

In your example "jack@gmail.com" would be added to your IdP.

When you have your IdP connected to your JSM site - you're able to refer to your IdP to authenticate "jack@gmail.com" then redirect to your help center after authentication is successful.

An ideal configuration would have all your customers like "jack@gmail.com" in an IdP connected to JSM - your internal employees should be in a separate IdP.

You can add any user/domain you wish (e.g. outlook.com, live.co.uk). This SSO feature will check if the email entered should be granted access "authenticated" and redirected to the help center.

[Earl Reyes]

@Ash Young sorry for the late response. 

So today we use Auth0 and we manage the accounts for our clients to our own application. We would create an account in our auth0 instance, and as I understand it could use Auth0 as the primary IDP for JIRA Service Desk, so that clients could have single sign on capabilities to JIRA where they could log their own tickets and view knowledge base articles without having to create a separate JIRA Portal Account.

In the future, instead of managing the accounts in our Auth0 instance (creating/modifying/deleting client accounts), we want to delegate the IDP to the client's own authentication system. So let's say some use Okta, or Microsoft Azure, etc.... their provider would authenticate to our application with uses Auth0. If our Auth0 was configured to enable SSO with JIRA Service, would it support this sort of daisy chained authentication process? 

[Tomasz Urbański]

I've tried to enable this feature for my client for one month. Its users still receive a message like 'You cannot authenticate with SSO. Try again later.'. First, I assumed I did something wrong in the SAML configuration. Finally, I found the info you're rolling out the feature gradually, and I've sent the email requesting to enable the feature for my site faster.

QUESTION: How long does it take to enable the feature when you get the email request?

REQUEST: Can you consider publishing the info about the gradual feature rollout somewhere in the admin IDP forms? (Such a simple message can save time on ineffective troubleshooting.)

REQUEST: Can you add a GUI element in the admin dashboard informing if the feature has been enabled for the site? (Such an element can save time on ineffective troubleshooting.)

[Alex Ray]

@Tomasz Urbański I think I might be having the same problem, I get "You can’t continue with single sign-on. Try again." when trying to use a 3rd party SAML IDP, I've spent a while trying to find any kind of debug log, didn't occur to me that maybe the feature wasn't turned on!

What email did you send to / how did you find out?

[Tomasz Urbański]

@Alex Ray Please, take a look at SSO integration with JIRA Service Management 

[Alex Ray]

@Tomasz Urbański  Actually I figured it out, it wasn't that the integration was disabled, I had to do two things on the IDP side:

• Enable signed SAML assertions
• Change the NameID format to "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"

[Tomasz Urbański]

@Alex Ray Thank you. I'll investigate the direction. Have you found it in any Atlassian article?