SCIM for User Provisioning: We Need Your Feedback

[#1]

Hi everyone!

We’re exploring ways to simplify user management setup in our Data Center products, and we’d love to hear your thoughts on our idea.

Implementing SCIM in Atlassian Data Center

An increasing number of enterprise organizations are adopting cloud Identity Providers (IdPs) such as Entra ID and Okta, not only for Single Sign-On (SSO) but also for user provisioning through the SCIM protocol. SCIM 2.0 has emerged as a standard for user provisioning due to:

• Seamless automation by instant user provisioning and deprovisioning

• Open standardization, widely used

• Security and compliance alignment

Consequently, more Data Center customers are inquiring about SCIM provisioning support.

We are considering prioritizing this feature, but we need to enhance our confidence:

• Will you, our customers, be willing to adopt it?

• What issues could the implementation of SCIM address within your organization? Would it reduce the necessity for utilizing other tools?

• What factors could influence your decision not to use SCIM?

💬 Please leave your feedback either:

• In the comments on this post

• By voting or commenting directly on tickets:
  https://jira.atlassian.com/browse/JRASERVER-71737
  https://jira.atlassian.com/browse/CONFSERVER-82407
  https://jira.atlassian.com/browse/CWD-5675

Thanks in advance for your time and input 🙏

[Rafael Corredor]

Hi,

I am a little confused..  Is it not already implemented for Confluence (at least with Azure AD)? 

https://confluence.atlassian.com/doc/confluence-9-1-release-notes-1431966396.html?#Confluence9.1releasenotes-MicrosoftEntraIDintegration

We are waiting for this feature for Jira.

Thank you

[Keimpe de Jong]

• Willing to adopt
• Would reduce the need for SSO apps
• Necessity of Crowd could influence the choice

[Phill Pafford]

+1 for Crowd, this has been something I have been watching for a while now https://support.atlassian.com/provisioning-users/docs/configure-user-provisioning-with-okta/

[Morten Stensgaard]

HI @Olga Springer .

Both SAML SSO and SCIM user provisioning should be supported natively in the whole Atlassian Stack and should be the prefferred way of provisioning and authenticating - Atlassian is ridicuosly behind on this in DC, hence this should be a base requirement for ANY enterprise company. And left me just mention OIDC.......where is that in Atlasssians suite. But nice to see you finally look into this as "late movers".

Personally I HATE the "Just-In-Time" provisioning as an admin - Because it still generates the manual cleanup after the user have left the organization(And you would never know, unless you look ALL users up in HR!) - Anyone using JIT should actually stop, unless they have manual controlling activities of all their users - Why? It will cost you heavily in inactive licensing.

We are currently paying for 2 x Resolutions SAML SSO and User sync(SCIM) + 2 x Manage inactive users for Jira & Confluence - But it was worth the investment - we saved 700 user licenses in Confluence on automating the usage process and it prevented us from bumping another DC license tier on Jira

We would defintely consider adopting/migrating....but there are some fundamental and underlying  decisions and designs that needs to take place before SCIM should be supported - Else you will tend to release a feature, which no-one will actually adopt.

1) Automated provisioning/de-provisioning with SCIM.......requires support for automated licensing/de-licensing in Atlassian.

A HUGE factor which would stop us from adapting = Lack of automated/proper license management.

We will not SCIM provision a user, which is to be licensed for something they then don't ACTIVELY use or only use for a single view of data.

Reason: We page huge amount of money for inactive licensing - And don't get me started on currently funding 2000 Gliffy users, when only 50 users actually uses the product. :-(

ANY user account in Atlassian products should NOT be product licensed or payable if the user don't use the product! - Hint! Please reach out to Slack(Salesforce).......they actually got it implemented right.

• SCIM provision the user, but do not enforce a license on them, untill they SSO authenticate or actually use the product
• Auto un-license a user after x days of inactivity(based on last logged in)
• Support to manually override as Jira/confluence Admin

How it works with us today:

• We SCIM provision the user into Jira/Confluence without any licensed group.
• We add license group(jira-users) to a user when they SSO authenticate into Jira(via Resolution SAML SSO addon)
• We un-license a user after 90 days of activity (daily run via Manage Inactive users by ILA solutions)

Lack of proper automated license management in Atlassian products is really bad.......like REALLY bad - So bad, that I once had to fight of C-level Management, hence they were are about to select a different vendor solution because it was a cheaper offer/budget in Excel. A few hours of manual license management prevented us from leaving Atlassian altogether..........But Atlassian don't see that root cause - They know they earn a LOT of money on the lack of providing cusotmer an automated license management solution.

It's the same problem with any other SaaS providers(Except Slack) for collaboration Tools - Miro,  Lucid, Adobe, Figma etc..........First fix is free, then you consume a license indefinitely untill you leave the company,  while the vendor just hopes you don't have people to do user controlling with a regular user interval.

To keep it short: SCIM will not solve your license management issues - It might even worsen it!

2) Groups - both centrally and de-centrally supported

You should both be able to centrally SCIM provision groups AND also manage it decentrally - A lot of permissiong within Jira/Confluence is managed via groups.

If you ONLY support enfroced group management from SCIM, you will risk user frustration by the lack of quick reponse to a user request of getting a permissions(Time-to-market)

Resolution addon provides multiple solutions to this - also ungrouping user accounts(cleanup) 

3) Lack of attributes support in Jira/Confluence

Entra ID contain a of valuable atttribute  - Ex. whether they are Employee or Consultant, their Company name(as consultant), Office loacation, Country etc. - But their are no simple way of storing this information on a Jira or Confluence account - You actually need to use either a combination of user AND entity properties........User properies works on the Profile page(UI), and the other attribute is exposed only on the REST API(for automation and groovy usage)

Profile picture is not supported and Autoamtion for Jira also lack support for users(and their attributes)

Today we map multiple attributes from Entra to support assigning users to certain groups, permisisoning, logic etc.

Summary:

If the 3 bullets above is not adressed as part of an Atlassian SCIM implementation, you will most likely causes more frustration than resolution, because the license management and permissioning will become a fuzz - I'm guessing the whole native SAML SSO authenticate is also lacking some of these features here(And that why we customer continously needs to buy the addons)

Fun fact! We actually have numerous users that pay a Full Jira license for just being able to registerering their Tempo time on a Non-IT Projects(Single Jira work item)......100% waste of license money and budget

Kind Regards

Morten Stensgaard

Technical Domain Manager

Nuuday A/S