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.

[Ash Young]

Hey @Stuart White

Portal-only account are designed to support external service desks. Theres more details on this page

Portal-only accounts should only be used for external service management (e.g. an ecommerce company offering customer support, a public service desks open to members of the public, etc...)

In these scenarios the users you are providing support to are external to your business/company and hence you don't have full control over domains, and users typically self register for your service desk.

SCIM for Portal-only accounts is designed for business that need to provide support to externals that are known to the business (e.g. managed service providers, consultancies, vendors). SCIM offers the ability to provision/deprovision Portal-only accounts based on identities in an IdP.

---

In scenarios where a business is using JSM only for internal service desks (IT support for your business, HR service desks, Finance service desks). We do not recommend the usage of Portal-only accounts.

In these scenarios we recommend using managed Atlassian accounts which also support SCIM/SSO functionality.

---

The account type you use should mirror your service desk purpose and structure.

You can read more about Portal-only accounts & Atlassian accounts here

[Stuart White]

Hi Ash,

yes, that's clear. We're an Enterprise customer with hundreds of international external customers (all with their own IdPs) and use JSM to support them. However the limitation of one IdP connection essentially makes the feature useless - which customer do we connect? 

Perhaps we are misunderstanding the intention of the feature. 

[James Rickards _SN_]

Hi @Ash Young ,

I'm happy to continue online if it helps others as I'll keep information generic.

RE: What is the nature/industry of your business?
The industry is Infrastructure Construction. It is a different domain to Managed Services or Software Engineering. Typically, a central organisation is appointed to manage a project, many tasks are delegated to many separate subcontractors who execute work. e.g. In addition to typical JSM use case of IT Help Desk, Requests may be to engineering teams such as "please provide a survey of this area".

RE: On your service desk - who are your primary help seekers?
- We have both internal and external customers, but we expect all requests to be initiated by internal customers, with external customers involved as participants only.
- Subcontractors are added to Entra as Guests so authentication can be executed via our IDP, which then delegates authentication to the subcontractors IDP (if they also use Entra). This ensure true SSO as subcontractors use their company email address and password (which we don't need to retain), and if they are terminated in their IDP, they loose access to our systems immediately. This is becoming an increasingly common practice in businesses I have worked at.

RE: What is your relationship with your primary help seekers?
- All internal customers are explicitly added as customers via SCIM when onboarded as an employee.
- External customers are typically added to the directory when they are CC'ed on emails and thus added as Request Participants.  Most of these CC'ed users are Guests in Entra. The ones who are not, should not be added as Participants on the request.

With that context out of the way, my main question (that I haven't found an answer for in the documentation) is ...

Does a SCIM'ed "Portal Only" customer (with a domain we haven't claimed) get authenticated via our IDP (the one the user was SCIM provisioned from)?  If so, I need to investigate this functionality more, otherwise if they need to set and remember a unique password for the Portal then this feature adds no value to our use-case.