@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.
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
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?
Atlassian Team members are employees working across the company in a wide variety of roles.
April 3, 2024 edited
@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.
Atlassian Team members are employees working across the company in a wide variety of roles.
April 3, 2024 edited
@Nick Jones Our SSO feature is SAML 2.0 compatible. As long as Keycloak is able to connect to JSM via SAML 2.0 and treat JSM as the "service provider" you should have no issues.
@Ash Young It is a great feature, I have one question - will we have portal-only customers at our IDP? In your article, you wrote that we will authenticate portal-only customers on IDP.
Hi all, question I'm hoping someone could help me with. We are live with JSM with our external customers already (no SSO for them, email and password only). We're looking to enable SSO for external portal only users. I have two questions:
I think I've read we have the option of enforcing SSO only, or allowing people to authenticate via SSO or via email and password, is that right?
As we already have thousands of external portal only users in JSM authenticating with a password, when we enable this feature, will all those same accounts be automatically added / made available for SSO authentication? We obviously wouldn't want to create new (duplicate) accounts!
Great to hear you're planning to adopt SSO for your portal only customers. In answer to your questions:
1. Yes. At a site level you can configure authentications methods to allow password only, SSO only, or both. Your portal only users, after entering their password, will see a "Login with password" button, or a "Continue with SSO" button, or both buttons, depending on your configuration.
2. Existing customers will log in to their existing accounts, regardless of the authentication method. Logging in with SSO may update some of the account fields, such as display name or preferred language, but if the user's email address is the same they'll keep their existing account. SSO logins will only create new accounts in JSM if a user is in your IdP but NOT in JSM, and uses SSO to login.
Thanks Oliver, it does, much appreciated! One other query - the documentation indicates that you configure one IDP for portal only users for the site. Does that mean that our external customers can only use the SSO method to authenticate to the JSM portal with one provider (Microsoft vs. Google vs. etc) as per the IDP we configure JSM with?
I guess it was a little confusing because normally when you use SSO on the Internet as an "external customer" you get to choose Google, Microsoft and SAML as well as username/password options, which covers most situations. Does that make sense?
We only support one IdP for portal only users per site at the moment. If you're looking for multiple IdP support for portal only users I would encourage you to watch https://jira.atlassian.com/browse/JSDCLOUD-13241 and vote on it.
You can still configure your site to allow your portal only users to log in with their password as well as with SSO.
If you are after "Social login" such as the "Sign in with Google", "Sign in with Slack", or "Sign in with Apple" options available for licensed users, I'm afraid that is not available for portal only customers at this time. I would encourage you to watch https://jira.atlassian.com/browse/JSDCLOUD-1964 and vote on it.
Thanks again Oliver, that's useful - I'll certain vote for those features as it seems like an enhancement that most organisations would expect as table stakes in an SSO solution.
I've been working with our IT team to test this out (opting for Microsoft IdP) but they are struggling - I'm not sure if it's our understanding of the feature:
As I mentioned earlier in the thread, we're trying to setup JSM portal-only SSO. Naturally we have lots of businesses we work with, each company naturally has their own email domain.
The desire is that the customer contacts will enter their corporate email address on the JSM portal login, then automatically be signed in via SSO (accepting this would work for Microsoft provisioned email addresses / businesses only).
The question is what would be the best way for us to achieve it, without having to create the users in our AD, the key point being they don't exist in our MS Entra environment and we don't want to create them in there?
Thanks for your ongoing help - I'm sure others will find this a useful reference as well!
I am not an expert in IdPs, but it might be possible to create a single IdP connection that passes through accounts and auth from multiple other IdPs. Failing that you would have to sync all of the accounts from each of the companies you work with into a single IdP and connect that one to JSM.
Once you have connected an IdP, end-users will enter their email into the login screen of your JSM help centre and, as long as their e-mail doesn't match an existing internal user account and isn't from an approved domain configured to have internal user access to your site, they will be prompted to "Continue with SSO". Depending on your config, they may _also_ have a "Continue with Password" button. When they click the "Continue with SSO" button, they will be re-directed to your IdP, where they log in, and then are returned to the help centre. JSM will create a user for them on the fly if this is their first time logging in.
I hope this helps. I am sorry if I didn't quite understand your question.
If you need specific help setting up your site or configuring the connection to your IdP, I would ask you to contact Atlassian support at https://support.atlassian.com/contact/#/, who can help you with specifics.
Thanks for taking the time to reply with these details Oliver, it is helpful.
We have restricted out JSM portal, meaning people can't self sign up - we will invite new users to the portal only. In that scenario, if SSO was enabled, I presume that JSM would not create a user for them on the fly - the portal restriction would still be respected? In the event a new user is invited to the portal by a customer service desk agent and SSO is enabled, would they still need to reset their password on first access to the portal (as they do today), or could they simply access via SSO from their very first login?
The limitation on a single IdP we thought was around needing to choose between Microsoft, Google, etc. Naturally for a portal only external customer JSM scenario, we will have our external customers trying to access the portal from many different email domains, although many will use MS365 as we are B2B. We thought the single IdP limitation was around choosing a technology provider, so perhaps we could only support SSO for customers who are themselves using Microsoft.
Our intention was to setup 1 separate IdP for all our external JSM customers (portal only). Since we already have those accounts in native JSM as portal only users, we were thinking the process of enabling SSO would sync those email addresses into the IdP we've specified. Then moving forwards whenever we invite a new portal only user to JSM, the email address/account would be synced into that IdP, so if that user attempted to use SSO to gain portal access, their email address would exist in the IdP.
Hopefully that clarifies our goals slightly? Gamal
> In that scenario, if SSO was enabled, I presume that JSM would not create a user for them on the fly - the portal restriction would still be respected?
No, in terms of self sign-up, users in the IdP are considered to already have an account. If an IdP is configured for SSO, the "Continue with SSO" button is offered to all users (unless they're in the approved domains for internal users); we delegate authentication to the IdP and if the IdP accepts them so do we. Although we technically create an account on the fly, we consider it a login, not a sign-up if the user is already in the IdP.
> would they still need to reset their password on first access to the portal (as they do today), or could they simply access via SSO from their very first login?
No. If they use the "Continue with SSO" button they will login on the IdP. There is no need to set a password with Atlassian unless you disconnect the IdP or it is not working for some reason.
> Naturally for a portal only external customer JSM scenario, we will have our external customers trying to access the portal from many different email domains
External customers from many different email domains is not a problem. As long as the user logging in is not part of an approved domain for internal users, _any_ user will be offered the "Continue with SSO" button regardless of their domain.
However, we currently on support connecting one IdP for portal only accounts. As I mentioned in an earlier comment, it may be possible to somehow funnel all your customer's IdPs through a single relay IdP.
JSM doesn't natively have the functionality to sync portal only accounts to an IdP. You may be able to find a marketplace add-on that does that, or script a solution with the APIs.
43 comments