Upcoming SSO capabilities for external customers in Jira Service Management

[#1]

Released to General Availability (Update as at 2nd November 2023)

SSO for external customers is now available for all customers. You can find the announcement here

Product settings for authenticating portal-only customers via SSO (aka external customer SSO)

Jira Service Management and Atlassian Access are extending their capabilities to support single sign-on for portal-only customers. This solution is designed to help users outside of your business leverage the authentication credentials you already have for them.

This project is a commitment on our public roadmap for delivery in Q3 of 2023. We are aiming to start an Early Access Program (EAP) in Q3 2023 which will provide access to a small group of customers to provide feedback on the experience. Please reach out to your account representative if you are interested in participating in the EAP. Unfortunately, we cannot guarantee a place for all customers who express interest in the EAP.

Our first release will bring SAML SSO capabilities for Jira Service Management portal-only accounts, followed by a future release of SCIM user provisioning for Jira Service Management portal-only accounts. The SAML-based solution will allow organizations to connect a separate identity provider (e.g. Okta) through Atlassian Access. The users in that directory can be used to authenticate access to the associated Jira Service Management Help Centre. Administrators will have the option to enforce SSO for external customers.

You may be familiar with the domain verification and user claim steps to successfully set up Atlassian Access for your managed users. To support SAML SSO for Jira Service Management portal-only accounts, you do not need to verify any domains or claim any users. This means users with public email domains (e.g. gmail.com) will be able to authenticate and sign-in.

Your customers visiting the Help Centre will be prompted to enter their email address. They will then be redirected to your connected identity provider for authentication before returning to the Help Centre. If a customer already has an authenticated session with the identity provider (e.g. following a link from within an authenticated environment), they can be recognised by the Help Centre and bypass the login experience.

The solution will be packaged as a part of Atlassian Access. This is how it will work:

• If you do not have Atlassian Access, you need to subscribe to Atlassian Access to use SSO for portal-only customers. Portal-only customers are free and do not count toward licensed users for Jira Service Management. You only pay for licensed users (Atlassian account with product access). See support documentation for more information.

• If you have Atlassian Access already, you don’t incur extra costs adopting SSO for portal-only customers.

[Kalin U]

@Benjamin Paton , I'm interested in the EA program, but I'm also concerned whether the proposed solution would work for us.

In our JSM instance we serve both internal and external customers where almost all of our internal customers have Atlassian accounts to make use of SAML-based SSO through Azure AD, whereas the majority of external users are portal-only customers. One of our desks is intended for mixed customers - inside and outside of the organisation.

The proposed setup is confusing to me. The following questions need some clearance:

1. What if some (new) external customers don't have an identity provider? Will they be able to log into our portal?

2. Do we have to configure the identity provider(s) for each (new) customer? Our customers are added manually,  without a self sign-up option.

[Benjamin Paton]

Hey Kalin,

Thanks for reaching out. In answer to your questions

1. You can continue to create an authenticate external customers as you do today. You will be able to add an option identify provider if you want customer to have the freedom to login, or SSO.
2. If you want to use an SSO directory you will only need to configure it once. Any new customers added to that directory will automatically be available to authenticate into the help centre.

I hope this help, let me know if I have misunderstood.

Cheers, 

Ben.

[David Drong-Reisch]

Hi, sounds great! I would participate in EAP. We have 400 Users and Atlassian Access with MS ADFS already in use.

[Huw Evans]

We would also like to be part of this EAP. I'll also reach out to our enterprise advocate. 

[Nina Vehovec]

Hi, we would also like to participate in EAP.

Best regards, 

Nina Vehovec

[Greg D]

We are interested in the EAP.  Hopefully we will be able to layer our customer's auth platform into the portal to unlock the use of forms on existing issues and other customer-facing features that have been blocked in our use-cases.

[Jason Freeze]

Will this work for our scenario?

All our users are in Azure AD.  We have about 2000 total users.

Of those users, 20 have agent licenses. 1980 users are portal-only.

We want only these 2000 users to be able to login.  We don't want any other users to be able to sign up or login.

All of our users are "internal" but they are mostly only portal users.  But every user must use SSO from Azure AD.

We want only one admin account to be able to login without SSO.  That ensures that we can fix SSO if it breaks.

We have two email domains: example.com and example2.com

There is no rhyme or reason why someone has one domain over another.  They just kept whatever email domain they had before the two companies merged.  But they are still all in the same Azure AD tenant.

So should the SSO solution work for us?

[Yatish Madhav]

This sounds super! But I am sad that we need an Atlassian Access subscription for it. Thank you

[Leon Oud]

Hi, we would like to participate in the EAP.

We are looking for an SSO solution for our customers to be able to use their portal account in our software solution. As they can sign up with any domain it is essential that we do not have to do domain verification for customer users for the JSM portal.

[Frederik Krogh]

Hi @Benjamin Paton

Please reach out if you need test subjects for EA or ealier tests. I have a fairly small org which are ready to test this out and provide feedback.

Best,
Fred.

[Ian Bekker]

Also interested in EAP.

[Marta Mita]

Hi @Benjamin Paton 

we would like to participate in EAP. SSO is a crucial topic in our organization. Please let me know if you need anything from my end to provide you with before the start of EAP. 

Thank you and kind regards,

Marta

[Benjamin Paton]

Thanks everyone. If I have liked your comment I have added you to the EAP list. Please understand that we cannot extend the EAP to everyone, but we will do our best to include as many as possible.

@Jason Freeze it sound to me you should be using straight Atlassian Access for all your users. Check out this article and use the Internal Use Case. This SSO solution targets external customers.

@Yatish Madhav it's important to note that you will only pay for your licensed users with Atlassian Access, any portal only customers you connect won't incur cost.

[Wim Abts]

Hi @Benjamin Paton 
We would also like to be in the EAP.
We also have our internal users connected via Azure AD and Atlassian Access.
Our customer accounts (5000) are now provisioned via Azure AD but they all have local passwords, this solution could allow them to use there password in our Azure AD environment.

Also, we also have a large number of our portal only users that logon using their Microsoft account (they're also registered in our Azure AD as guests), will this also still be possible? 

[Benjamin Paton]

Hey @Wim Abts

By the sounds of it yes. You should be able to connect your Azure AD accounts via SAML and have them authenticate via your Identity Provider. 

We do not yet support Microsoft accounts for Portal-only Customers, unless they are authenticated via your IDP first.

Cheers, 

Ben.

[Federico Scheu]

Hi @Benjamin Paton 

We have a ticket open with a related issue to this functionality. I tried to mention you on it but I couldn't. I hope that you can take a look at it.

Cheers,

Fede.-

[Wim Abts]

Hi @Benjamin Paton 

'We do not yet support Microsoft accounts for Portal-only Customers, unless they are authenticated via your IDP first.'

Currently those customers who have a Microsoft account (everyone using Office 365) are invited as guests in our Azure AD and provisioned to Atlassian Access via the Azure AD Sync option.
They log on to the Portal using the option 'Microsoft' and this way have SSO with their own Microsoft tenant.
Will this option still be available when we activate the this option now? 
Or will all users be send to out MS tenant to do SSO (which will be ok I guess because then they should also be authenticated against their own tenant)...

Other customers that don't have a MS subscription are now created as a new Atlassian account and have seperate accounts on our MS environment and Jira.
For those this option would allow us to have a link between both accounts (which would be super).

[Federico Scheu]

Hi @Wim Abts,

We are implementing a JSM Portal with the same scenario that you described here and I wanted to ask you a couple of questions because we are having problems with SSO for guest users in Azure AD.

In our case, we could provision the Azure AD guest users to Atlassian Access but they can't sign in with their Microsoft accounts. They are asked by Atlassian Access to create an account. To understand what could be different, in your case: 

• Do your Azure AD guest users belong to "claimed domains" in Atlassian Access?
• Did you have to configure the Atlassian Cloud App in the Azure original tenants of the guest users? 
• What external identity do your guest users have in Azure AD (link)? We don't know if this could affect the SSO, we are investigating it yet
  • B2B collaboration
  • B2B direct connect
  • Azure AD B2C

We are reviewing all this with Atlassian support, but knowing an organization that already implemented it is very useful to us. Thank you in advance for your reply.

Please @Benjamin Paton, any feedback on this will be appreciated.

Regards,

Federico 

[Leon Roth]

Hey, we are also interested in the EAP!

[Wim Abts]

Hi @Federico Scheu , 
Just to be clear, we're also not live yet, our goal is to migrate to cloud  end of 10/2023.
We do have a migration trial running and have been testing the user provisioning etc for quite a while now.
Our customer accounts are B2B collaboration users, we create them as invited guests in our tenant when they also use Azure AD (non Microsoft users are invited as well but will have a regular guest account = email address in our tenant).
We use the 'Azure AD' Sync' option to provision our internal accounts to Atlassian Access (= claimed domain), not SCIM (we tested it before the new option 'Azure Ad Sync' was added.

Last year the option to provision guest accounts was added to this 'Azure AD sync' so that we now also have an automated provisioning for these guest accounts.
They don't belong to a claimed domain as the username in Atlassian Access = email address and as these guest users all have their own email addresses, so we can't claim these domains.

What we tested with several invited guest accounts is the logon process.
When their account is an Microsoft account, they should use the 'Continue with Microsoft' on the logon screen.
They are then presented with the logon procedure of their tenant and use their own password and if configured in their tenant, MFA as well.

Users that don't have a MS account just continue the logon process as a normal Atlassian user with a local Atlassian password.
We did not have to configure the Atlassian Cloud App in the tenants of the guest users.

[Federico Scheu]

Thank you @Wim Abts for your thoughtful response!

It's extremely useful for us and gave us several points to check and try. Maybe I come back later with more questions ;-). Thanks again.

Fede.-

[Geoff Mether _Togetha Group_]

@Benjamin Paton we would love to join the EAP. We would use for our service desk, but also to support customers to use when it is available for all.

Geoff

[DIrk Grobler]

@Benjamin Paton We are also keen to join the EAP. We are planning to release the service portal in the second half of the calendar year and the timing of the SSO for external customers seems to be right on the money.

Cheers,

 Dirk

[Oliver Nash]

@Benjamin Paton Keen to join the EAP when available!

[Matthew_Kent]

@Benjamin Paton We're also interested in joining the EAP as well given that this is a feature requested by some our clients.