nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Ash Young

Update 15th April 2025:

Today we're announcing our Early Access Program (EAP) for JSM external customer SCIM (System for Cross-domain Identity Management).

You can read more sign up for the SCIM EAP here

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.

image (3).png

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

Subscribe to Atlassian Access for organization.
Make sure you're an admin for an Atlassian organization.
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

Follow the instructions on this page to configure SAML SSO
- Configure settings to authenticate your customers
Use test mode and check your SAML SSO configuration with an account that exists in your IdP
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!

Comments

Vedant Kulkarni_Trundl

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

Regan Marshall_ntw8f1

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_ntw8f1

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_35d5gj

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:

Provision all your "external" user with an Atlassian Account
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_ntw8f1

@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_35d5gj

@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?

Alex Ray

@Tomasz Urbański I didn't find that in an article, I just used trial-and-error on the IDP provider side.

Nick Jones_tuic1l

@Earl Reyes @Ash Young same question here. we use Keycloak and can federate out to the IDPs of our customers. I'm assuming we can connect Keycloak to JSM and all will be well.

Asha Goyal_0i7i5i

@Ash Young Great feature Indeed!!

Alex Ray

What happens if users sign-in initially via SSO, then in the future you disable or remove the SSO? Will they be prompted to sign up for an Atlassian account / will they get the same 'customer account' and see the same tickets so long as their email address is the same?

Ash Young

@Alex Ray SSO is simply a method of authenticating for the help center.

If you choose to remove SSO as an authentication method, JSM will revert to Email + Password. Users will need to use the reset password flow to access the help center.

Turning off SSO does not "deactivate/delete" an account - once a user sets a password they are able to regain access to the help center.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

sso

authentication

saml

identity-provider

scim

jira-service-management-cloud

jira-service-management