Hi greg.draper310998593,

Good question. We currently do not support the ability to provision accounts for domains you have not verified, so if your JSD customers are external, unfortunately this won't help right now. This is because Atlassian Cloud accounts are unique per email address, but shared across all Atlassian Cloud properties. So if one of your customers is using the same email address to log into Confluence Cloud (for example) at their own company, their account needs to be managed by their own admin.

However, if your JSD customers are simply users at your company that are creating requests in Jira Service Desk but don't need access to any other Atlassian products, this should be relatively straightforward. You can create a group in your identity provider for customer-only users, then use SCIM to sync this group to Jira Cloud. By default, these users will be added to your site but won't receive access to any products by default. This means they will have an account provisioned for them and will be able to create requests in the Jira Service Desk portal, but you won't be billed for them (and portal-only customers are not billed for Atlassian Access either).

Hope this helps.

Dave

Hi everyone,

First off, thank you for working on all of this.  Will this be expanded to provide a way to sync a customer directory with Jira Service Desk customers?  The focus seems to be on internal Identity Management and that has made great progress, but there is a huge need with a customer directory sync so that active customers can use a shared login between systems.

Hi everyone,

We're pleased to announce that documentation for the User provisioning (SCIM) API is now available on developer.atlassian.com. The API is an implementation of the SCIM specification and is intended to be used to sync users and groups from an identity provider to an Atlassian organization. Once you have linked an Atlassian Cloud site (like example.atlassian.net) to your organization, users and groups will be synced to your site and you can use them to control access to Jira and Confluence Cloud as well as permissions within those products. Learn more about how automatic user provisioning works with Atlassian Cloud.

There are several key benefits to automating user provisioning for Atlassian Cloud:

• It saves you time as an administrator by automating the process of creating and removing Atlassian accounts for your users
• It improves security by reducing errors in the provisioning/deprovisioning process
• It can help reduce costs by ensuring you are not billed for users who are no longer active

The SCIM API is intended for customers who are not already using one of our supported identity providers. We currently support Okta and are actively working on support for Azure Active Directory and Onelogin. If you are using one of these identity providers, we recommend using the supported Atlassian app for these identity providers as this will simplify the configuration process.

We're actively working in this area and will share another update when support for additional identity providers is available.

Regards,
Dave Meyer
Atlassian Access Product Management

Hi @dave and thanks for the good news! Looking forward to test out the Azure beta when it is released. Where can i sign up for it?

Another question. just-in-time provisionsing does not currently work when user access the service desk portal. Will there be support for this added shortly as well? 

Cheers

Per

I have 2 questions

1)

 I'm wondering how the nested group works when it comes to provisioning. It seems inconsistent in my case. 

For example, I have users in group A which are nested in group B and group C.  I expected user A will be in both group A, B, and C, but I see some users are in only A but not B and C while some users are in group B and C but not in A. 

2) 

User provisioned to Atlassian are not put into a pre-existed group (like jira-users), which were set as `default group` in Atlassian apps.  Is this expected behavior?

Still waiting on full Azure support. I was able to get user provisioning working by keying in the API details from Atlassian Access in a custom SSO application in Azure, but group provisioning is not working out-of-box from the Azure side and this is required to push users in to Jira itself without them having to go through the sign-up flow.

Any estimation on when user provisioning for Azure will be supported?

Hi Dave,

Got it. I agree, the current approach makes perfect sense now that you explain it.

Thanks for the prompt response.

Cheers,

Enes K.

Hi ekarahasan,

That's a good question. Most of the largest identity providers have a dedicated Atlassian Cloud "application" that is used to simplify setup on the identity provider side. SCIM is more complex than SAML because in addition to configuring the endpoints, we need to ensure the mapping of fields from the IdP to Atlassian and behavior of different types of actions on the identity provider side correspond to the expected behavior in Atlassian products.

That said, we absolutely plan to release documentation for the SCIM API for experts that would prefer to set up their own configuration or are using an identity provider that doesn't have built-in support that we've certified. We're actively working on this and expect to make it available very soon.

Regards,
Dave

My familiarity with SCIM is minimal but, is there a reason why the SCIM configs have to be pre-configured by the dev/product team for each identity provider (okta, centrify etc..)?

The whitelisting of individual SCIM identity providers becomes a limiting factor when you consider how many have sprung up in recent times.

Why can’t account admins just get access to a generic SCIM config page and set up the integrations themselves with whichever provider they’re using? If both parties are SCIM compliant it should just work. This approach already works well for SAML integrations so I’m not sure why it’s not possible for SCIM.

Cheers,

Enes K

+1 for centrify SCIM integration as well.

+1 for Centrify

Can you please add user provisioning support for Centrify Identity provider as well for SSO ?

Thanks,

Rakesh

lucas972554040, here's the SCIM documentation for Okta: User provisioning with Okta.

ian.moroney, group support is available at the same time. You can learn about the supported features here: User provisioning in Atlassian Cloud.

@Dave Meyer, this issue is related to the same SCIM provisioning for groups for Azure AD. 

Will groups be available at the same time as users?

Now that this is rolling out, can anyone from Atlassian confirm up-to-date documentation on enabling SAML and SCIM for Okta?

Is the documentation currently shown on Okta's website no longer accurate?

Thank you.

Hey folks, just want to reiterate that we are actively working with Microsoft to update the Azure AD app for Atlassian Cloud to include user provisioning support. We'll share an update as soon as we can.

Cheers,
Dave Meyer
Atlassian Access Product Management

+1 for Azure AD, this is integral to implementing Jira for us!

+1 for Azure AD!

Still would like to see this +1 +1 +1 +1

Would like to also add that that we are really looking forward to seeing this progress

I'd love to see this with Azure AD. We really need to be able to manage our users and groups via AD just like the on-prem solution. It's way too manual at the moment when we have 500 employees in the system.

That beings said, what's the ETA on getting this implemented in Jira?

The blog aside, any updates on progress for Azure AD?

akilunov, we put out updates on this blog: https://confluence.atlassian.com/cloud/blog. If you watch it (by clicking the Watch button at the top), you'll get email updates.

akilunov unfortunately as a rule we don't provide specific release estimates for upcoming features, but we did make the announcement at Summit because we expect this feature to be available imminently. Given that this feature will be available for Atlassian Cloud and the Atlassian Cloud apps for Okta and Azure AD, I don't believe there is any software to upgrade. Feel free to email me at dmeyer (at) atlassian (dot) com if you have any questions.

martin.vandiemen we plan to work with additional identity providers immediately after the release for Okta and Azure AD. We also expect to make the SCIM API publicly available to write custom integrations.

@Dave Meyer,

How about OneLogin?

-Martin

Hi @Dave Meyer,

Thanks for the update!! Could you at least confirm in which Month or Quarter to expect it? It takes a while for us to upgrade software so I need to start the process early...

Unless I'm mistaken, I believe I've already filled out that form. Not sure what more there is to say, but do you have an RSS feed or something that you update when new releases come out?

Thanks,

Alex

Hi akilunov,

We announced at Atlassian Summit last week in Barcelona (see 46:00) that support for Okta and Azure AD with SCIM provisioning will be coming very soon. If you have a few minutes, fill out your info here and we will contact you directly when it's ready.

Regards,

Dave

Atlassian Access Product Management

@Helena Lu - Could you please say at least approximately when (year/quarter/month) will this feature be released? We've been anxiously awaiting it for over a year now so just wanted to get an update...

Hi peter.lambrechtsen,

Disabling a managed accounts will be supported in the SCIM implementation and enable you to manage employees that leave your company. 

Kind regards,

Helena Lu 
Atlassian Cloud Platform Design 

Just confirming that disabling or deleting users WILL be supported in the SCIM implementation?

As today there doesn't seem to be any automated way to bulk disable users via API for Cloud, referring to this issue: https://jira.atlassian.com/browse/JRACLOUD-44801

https://community.atlassian.com/t5/Jira-questions/Disable-a-user-in-JIRA/qaq-p/75786

I understand that disabling users impacts the number of licenses you can sell but it's 2018 after all.

Very much so, thank you Rodrigo.

Hello ianwalsh,

It's indeed feasible to have auto-provisioning being done by SAML when you have a set up with a single application integrating with the Identity Provider without much complexity, but it's not the cause with a micro services oriented Cloud environment as well as with applications that are not a simple "Grant access" routine, the user accounts are not on your Cloud site, for example, they are on our micro service called the Identity Platform, which allows users to use this single Atlassian account to access multiple Atlassian services, not limited to Jira/Confluence Cloud sites but also My Atlassian, Community, Developers' Community, SAC, etc and when talking about Jira/Confluence Cloud sites, there are internal access groups involved as well.

Below is an hypothetical scenario, excluding services other than Jira/Confluence:

Simple standalone application architecture

• Identity Provider -> SAML -> Standalone Application
• NameID attribute
• Name/UPN attribute (Unique identifier)
• Firstname attribute
• Lastname attribute

Once the user authenticates, this information is sent to the application, which creates the user account there and the user can start using the application depending on specific access requirements.

Atlassian architecture

Identity Provider -> SAML -> Identity Platform -> All Atlassian services

• (Identity Platform) NameID attribute
• (Identity Platform) Name/UPN attribute (Unique identifier)
• (Identity Platform) Firstname attribute
• (Identity Platform) Lastname attribute

Once the user authenticates, an Atlassian account is auto-provisioned on the Identity Platform (so yes, we have auto-provisioning by SAML, but it's not what our customers want), the user can access everything that does not need specific in-application access requirements and in these cases you can still do a simple "Access grant" on the Cloud site (Jira or Confluence) by enabling Self-sign up by restricted domain which will use the default access groups to grant access, but it wouldn't allow control over specific groups other than the default groups set and de-provisioning is not possible. In theory (we are not discussing actual architecture), to make it possible, the SAML response would have to contain additional information, like:

• (Cloud site specific) Cloud site identifier attribute (Example)
• (Jira/Confluence specific tied to the specific cloud site) Group attribute (Example)

So imagine that each XML envelope could contain a long list of all of a user's access and on cases there are multiple Cloud sites involving groups, all groups would need to be mapped and this information would only be sent at the moment of the log in (how SAML responses are exchanged on our architecture now), so if the user receives or gets removed from specific access groups on a single Cloud site or multiple, they wouldn't replicate until the next log in, so it's highly complex and not flexible, besides it's highly prone to configuration failures and/or creation of templates, you can see many people having problems with such setups on the internet. Additionally, the Identity Platform, which is a micro service with scope only related to the user account (Not application access) would receive complexity that goes beyond it's scope in order to pass down application specific information, that's really not what anyone wants in a micro services oriented Cloud world.

The struggle was real for us and we are happy that we found a good solution for Cloud based architectures and it's in progress, the SCIM APIs which are way more flexible for the current way things are as well as how they may become in the future, read more on this documentation:

The System for Cross-domain Identity Management (SCIM) specification is designed to make managing user identities in cloud-based applications and services easier. The specification suite seeks to build upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. Its intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model, as well as binding documents to provide patterns for exchanging this schema using standard protocols. In essence: make it fast, cheap, and easy to move users in to, out of, and around the cloud.

We hope this clarifies what is going on Ian! Sorry for the big text.

Thank you & best regards,

Rodrigo Becker
Atlassian Cloud Support

 From your comment it would appear you're suggesting that your supported IdPs will be the ones implementing auto-provisioning:

> once the SCIM APIs are available, our supported Identity Providers are prompt to offer auto-provisioning to customers.

However, the identity providers aren't the ones which need to offer this feature - instead it'll need to be developed and offered by Atlassian. Are you saying that you're not planning on doing that? Why does the ACCESS-33 work depend on the SCIM APIs when most other cloud services which utilize SAML offer auto-provisioning using the attributes returned in the SAML response?

Hello ray.williams,

Thank you for your feedback, you are partially right, having the SCIM APIs won't mean having auto-provisioning but these SCIM APIs are indeed a requirement to have auto-provisioning and once the SCIM APIs are available, our supported Identity Providers are prompt to offer auto-provisioning to customers. The SCIM APIs will work together with the SAML protocol to make a complete Identity experience.

So once this feature is delivered, the feature on ACCESS-33 will be unblocked, so to speak. I've updated the relationship between the issues to better clarify this state.

Let us know if you still have any questions or need more clarifications on the subject!

Best regards,

Rodrigo Becker
Atlassian Cloud Support

This issue has been linked to ACCESS-33, but is actually unrelated. Adding a new rest api would not be equivalent to allowing auto-provisioning as a part of SAML authentication. 

LOL, No wonder, I kept refreshing and never saw my comment about paying for SSO feature, but I did get the email too.

Agreed with you Wilson. I also commented about having to pay for Atlassian Access a few weeks ago and Atlassian either deleted or didn't approve my comment. Looks like this just happened again with Pedro's second response that I got an email for but don't see now. Very unprofessional especially since this feature is well over a year overdue.

Any update? Will this be updated before the end of August? With Atlassian Access becoming a paid subscription, the price would be easier to accept if provisioning was finally working.

Very interested on this, hopefully soon, can't wait.

@Vlad Thanks for working on this.. how many votes would it require to get this moved up on the priority list? 

Yes – when will this be in place?  Causing lots of pain...

An ETA on this would indeed be helpful.

We would like to have an ETA for this issue as well, please.

Hello, any estimated ETA on this?

Thank you.

Thanks for the update Ardash.

Echoing previous comments, there is a huge community need for this feature. Looking forward to a better experience for both users and admins.

We are building a standard SCIM based REST API's for auto provisioning users into Atlassian cloud. This feature is in progress and we will update the ticket once we are ready for Beta roll out.

• Cheers,
  Adarsh
  Atlassian Product Management

Echoing for updates. We automate provisioning/deprovisioning heavily and this is a huge hurdle for us to maintain as we move our whole company into Confluence/Jira.

Have there been any updates on this issue? My company would like to be able to push password updates. 

No updates on this?