Portal-only account - SCIM available now!

[#1]

SCIM for Portal-only accounts

Learn about how to configure SCIM for Portal-only accounts here

Today we're leaving a quick note that SCIM (System for Cross-domain Identity Management) for Portal-only accounts is now available for all sites.

What SCIM functionality is available for Portal-only accounts?

SCIM for Portal-only accounts will allows you to seamlessly provision/update/de-provision as required to ensure the right people have the right access.

SCIM for Portal-only accounts also allows for syncing of IdP groups with customer organizations so you can ensure your grouping are reflected and always in sync.

Who should use Portal-only account SCIM?

To use Portal-only account SCIM you'll need the following:

1. Your organizations is subscribed to Atlassian Guard Standard or Premium
2. You use Portal-only accounts for external service management on JSM
3. You use an IdP (Identity Provider) which can be used to set up SCIM/SAML SSO

Note: Portal-only accounts do not contribute to your Atlassian Guard bill - SCIM for Portal-only accounts is available for any sites where the organization has an active Atlassian Guard subscription.

A quick refresher on whether your should use internal vs external customers for your site

---

Leave a comment here with any questions or suggestions - we’re always looking for feedback from the community!

[James Rickards _SN_]

Does this finally allow us to auto-provision portal access for guest accounts registered in Microsoft Entra that do not belong to our claimed domain?  (e.g. if we claim asdf.com and the customer belongs to fdsa.com but is registered as a Guest in our Entra). It would be great to finally prevent random emails from creating a customer account and creating dodgy requests.

Also, can we allow our JSM staff to see the email address of these guest users to help minimise the risk of a "customer" raising a request via email emulating an internal employee's name.

[Ash Young]

Hi @James Rickards _SN_ 

I can't comment on how your IdPs are set up without getting on a call with you.

I can comment on "prevent random emails from creating a customer account". In this scenario you should be using "allowlist" functionality in conjunction with "prevent users from creating accounts".

When both of these features are configured - you will have full control of who can access your support site.

Portal-only accounts should always display a user's email.

You may be referring to some Atlassian accounts that have been configured to hide emails? If so - it'll be up to the owner of the account to configure visibility settings. (either the owner of the domain or the user that owns the Atlassian account).

You can read more here

[James Rickards _SN_]

Hi @Ash Young ,  Thank you for the reply.

Allow lists do work, and we used them one point, but a complete lockdown was not viable in our situation. As a workaround we use Automations to check Entra and add a big warning to any requests logged from an unknown user, allowing our vendors to still log requests for our agents to action, but providing sufficient warning to reduce the chance of a successful Social Engineering attack.

There is too high a turnover of the domains from the many companies that we work with, hence why it is desirable for all SaaS products to delegate all authentication. including guests (i.e. not a "claimed domain"), via our single source of truth (our IdP).  All other SaaS products we use can do this without complex configuration.  Atlassian has the most complex implementation of Identity Management.

Our agents are never able to see the email address of users outside of our domain, they all seem to be Atlassian accounts set to hidden, and as a result I need to manually add their email to the description of the ticket along with the warning. As this is not a consumer to business situation (but B2B), it is never appropriate for email addresses to be hidden. See: https://jira.atlassian.com/browse/JSDCLOUD-16624 as an example of one of the many requests from other people complaining about this.

[Stuart White]

Hi Ash,

Our company is also very keen on this feature. 

One problem we have is that the email address can not be changed but it can be changed in the IdP. A sample scenario is that the user gets married. Currently this doesn't seem supported at all which is a blocker for us. In our tests this caused the user sync to be broken. 

We are also hoping that we can connect multiple IdPs as we have many different customer IdPs. A single one is pretty much useless. 

Finally, it is not clear who the SSO affects if we activate it - only the synced users or all portal customers? 

[Ash Young]

Hi @Stuart White 

We currently don't support changing emails on Portal-only accounts. On your note about changing Portal-only account emails - you can follow along and vote here

We currently don't support multiple IdPs for Portal-only accounts. On your note about multiple IdPs - you can follow along and vote here

This SCIM/SSO functionality only affects your Portal-only accounts (external accounts). Atlassian offers equivalent SCIM/SSO functionality for Atlassian accounts (internal accounts).

You can find more details on configuring SCIM/SSO for Atlassian accounts here

[Ash Young]

@James Rickards _SN_ 

Thanks for the additional details on how you use JSM. I've got some more questions about how you operate and structure your service desks.

1. On your service desk - who are your primary helpseekers?
   • Are they internal employees or external individuals? Any more information about who you serve with JSM will help me with my understanding of your end users.
2. What is your relationship with your primary helpseekers?
   • How do individuals gain access to your service desk? Do you grant everyone access explicitly or do they self register in their own time?
3. What is the nature/industry of your business?
   • Are you a managed service provider or consultancy? How do you typically interact with your customers?

I'm also open to discussing via email or in person if you'd like to take the conversation off the forums (ayoung3@atlassian.com).

[Stuart White]

Hi Ash, 

Thanks for sharing the links. Could you clarify the intended use case for this feature? We are enthusiastic about its potential, but based on our review it appears to be applicable only under the following conditions:

There is a single customer with a single IdP to integrate.

User attributes—particularly names and therefore email addresses—never change. In practice, changes such as a surname update after marriage are common. When an email address changes in the IdP, it is neither updated in JSM nor does a new account get created. The only workaround seems to be manually creating the account, which undermines the purpose of the synchronisation.

As an enterprise customer, we rely extensively on SCIM for internal accounts across approximately 15 IdPs, and it functions as expected. The new customer SCIM feature does not appear to offer equivalent behaviour in this regard.