Yes, we did get it sorted. Our Atlassian Cloud app registration within AzureAD was created a long time ago so it didn't have the correct appRoles for the provisioning to work. Our app only had the msiam_access role available, and not the "User" role. The User role is what is filtered on for the provisioning to work. We ended up patching our application registration using the graph api to include an additional appRole called User which then allowed the provisioning to start working once the User role was assigned to the users. 

@s.mahood did you get a response from Jira or Microsoft on the NotEffectivelyEntitled error. We have the same issue 

akilunov there is SCIM add-on available on Marketplace for Jira Server. Not sure it is Data Center compatible though but certainly works for Server.

Hi mharley1059103882, and alex.zia, I've emailed you with the hope that I could interview you and understand your setup and requirements better. Our support of SCIM is very new and we are actively looking for enhancements we should consider making; your input would be super valuable for us. – Best, Lingbo (Product manager for SCIM at Atlassian)

Hi akilunov, this ticket is only for Atlassian's cloud applications (Jira Software Cloud, Jira Service Desk Cloud, and Confluence Cloud, with support for Bitbucket Cloud and Trello coming in the future). We do not currently support SCIM provisioning with Atlassian's Server and Data Center products. However, these products do have several options for LDAP integration.

@Dave Meyer just to confirm - has this already been implemented for Okta in the latest Jira/Confluence Datacenter release? Or is it still in the pipeline?

Hi Dario. The issue isnt related to migrating from on prem to Cloud. It's moving from not using an identity provider for provisioning to using one.

PSCLOUD-20188 is the issue we have raised. Your colleague Claudiu is investigating.

There seems to be an issue whereby once a user account is created, there is a unique link to the Azure AD entry, even after completely removing all trace and starting again. We have a fundamental issue where duplicate accounts were created due to mismatching UPN and emails. We have a potential fix to this by changing the attributes in Azure AD for the Atlassian email field from mail to UPN but as the accounts are already created i fear this will only work for new accounts created moving forward. We have about 27 accounts that have managed to duplicate themselves because of this issue and, currently, have no way of resolving it.

reiss.snooks1831337561, the behavior you are describing reminds me of ID-6789. Can you let us know the ticket number you have submitted so that we can further look into this?

s.mahood please raise a support ticket in support.atlassian.com to have your issue further investigated.

We are having some strange issues as well. All our users are listed as NotEffectivelyEntitled if they are assigned to the application through the Users + Groups in AzureAD and the provisioning is set to sync only assigned users and groups. I've raised a ticket with Microsoft who have now passed it to the backend engineering team as they've confirmed that it's all configured correctly. 

There seems to be some strange issues with the AzureAD user provisioning. It appears it tries to sync accounts that failed even after they are no longer in scope to be synced anymore every 30 minutes. There are also issues with duplicate accounts being created if UPN doesn't match Email address. I've logged this with Atlassian but was told to raise it with MS 

@micah Harley, Thanks for this info, but the way Atlassian created this provisioning is real complicated.

We have many thirdy parties in our Jira, and with this domain validation thing we can't provision thirdy-parties

So if we recreate a group like support has told you, it may work, but all thirdy-parties will loose access to these groups, which is still a no-go for us.

We have Identity providers and we have to deal with thirdy-parties in our side, Atlassian should just accept what identity provider is provisioning, it's our decision who we would like to add in our site not Atlassians.

After I put in a support request for the same group issue, the advice I got was to delete the existing Jira group. Then re-create it as a SCIM group with the same name, and add the same members into it. Since Jira uses the name as a unique ID (why you cannot change a group name), the lookup of group members happens real time, and will find the new SCIM group without adjusting Jira permissions. Seems risky to me, which is why I haven't tried yet.

@Dario Bonotto, no I think it's totally different

@Dave Meyer, yes this is the issue

Hi alex.zia,

You're correct – unfortunately if you want to fully manage permissions with groups managed in your identity provider and you already have groups configured in our products, it can require quite a bit of modification. We're definitely aware of the issue and investigating how we can address it. We are tracking this at ACCESS-608.

Cheers,
Dave
Atlassian Access Product Management

alex.zia, The bug you are describing seems to have a similar root-cause as ID-6789. Do you have a support ticket created in order to have this further investigate? If you don't, can you kindly create one in support.atlassian.com?

Our company have over 1200 accounts in Jira, testing Atlassian Access now.
We are using Evolveum Midpoint as IDM (Identity Management solution )  https://wiki.evolveum.com/display/midPoint/Home this is our identity provider
So we have created a connector using Atlassian SCIMv2 API and it's working as expected, we can create users, create groups, add users into groups, etc.

However, now there's another issue we are trying to figure out how to resolve...
All our projects in Jira have permissions set by already existing groups, that we can't manage through SCIMv2 API.
Idp creates new distinct groups,
In order to be able to grant projects permissions through Idp groups, we have to edit all our projects permissions and add these new groups into them.

It this the only way to achieve this?
That would be a huge work to do and to keep

reiss.snooks1831337561, if you remove a user from the group and disable their account in Active Directory, the user will be de-activated on the Atlassian side, i.e. the user wouldn't be able to log in to any Atlassian products and services with the account. 

If the user is only removed from the group, then the access to an Atlassian product (e.g. Jira Software) granted via this group will be revoked from the user. But if the user is also a member of other groups, then the access granted via the other groups would still be retained. Hope that helps!

This is great news @Lingbo!

Can I just confirm how the user provisioning functionality handles accounts of people who have left the company? We would remove the user from the group and disable their account in Activity Directory. Would Jira know to disable the account (after removing access via the Azure AD synced group automatically) or would this still be a manual task?

Hi everyone, 

Yes, the Atlassian Cloud app in Azure AD has been updated to include the User provisioning functionality – it supports both user and group sync. 😁I'm waiting for the documentation to be published in the Azure AD documentation set before I put out an update on this issue. 

Regards,

Lingbo

Actually, our users are syncing but we had to sync all users and then scope them using the scope filters on the provisioning rather than assigning users and groups

Interestingly groups are syncing through for us and are being created in Atlassian but users are not. 

We're seeing the same thing @Stephen.

Looks like we can configure the automatic user provisioning within the AzureAD app however when the provisioning attempts to run I'm getting that none of my users are effectively entitled to be provisioned however it looks like the syncing from the Atlassian side appears to be working. 

Do you have any updates lingbo?

Any update/estimation when this will be available  ? 

@lingbo

Is this just for getting users into the system, or will the Azure AD side of things also allow us to manage product / group access via Azure AD Groups?

We need to replicate the same functionality that User Directories on premise / Server supports. Otherwise maintaining user permissions in a 500+ user company continues to be a full time job.

Thanks for the update, it's very much appreciated!

We'll have some more patience...

Hi all, 

My team has been have been working with Microsoft on updating the Atlassian Cloud app in Azure AD to support user provisioning via SCIM. It's now in the process of releasing, and I'll update this issue when it's available for use. I don't have a concrete date at this point because there's a deployment process to go through on the Microsoft side and while we hope it'd be all smooth, there might be minor issues that could delay the planned timeframe slightly; it's software development life cycle after all.   I hope to share the good news with you all very soon! 

Cheers,

Lingbo

Product manager

Can you please give us any idea when this feature will be available ? we desperately need it ASAP 

I have a feeling Azure support is never going to come and even if it does, it'll be very limited and means continued manual management of accounts for things like group access etc.

Hi guys, we are going live in April with ERP and also desperately awaiting Azure provisioning support because we want to start using Jira SD.

We desperately need the Azure provisioning support. Going live with a internal Servicedesk setup shortly and since just.in-time provisioning is not supported for Jira Servicedesk the provisioning is a crucial. When do you think it will be ready? 

Yvo, same problem over here.  We desperately need a way via API to sync our customers and other vendors that are on many different domains that we do not control (some in Okta and some stored in other Identity Management systems).  Please provide a way to automatically provision any user that we want (same as how you can manually add them in the UI as portal only customers outside of Atlassian accounts with their own name and password).

I was sent here in the way of a support ticket (PSCLOUD-18510) to share feedback on how Atlassian currently implements SCIM and how it requires validated domains. I genuinely think that Atlassian's approach on "validated domains" to do a sync from an IDP (which is where that trust belongs) is a misstep for Atlassian. The domain to establish this trust is at the IDP (Okta in this case), not Atlassian. Atlassian should merely accept the user accounts I chose to provision into my tenant. Regardless of whatever solution you have.

While I understand some of the reasons that Atlassian has chosen this way of implementing SCIM, it is a huge step back in the flexibility that the previous integration (under Okta's "Jira-On-Demand" OWA) offered. With the "Jira-On-Demand" OWA we weren't required to have all domains validated in Atlassian. 

My use case is as follows. I have an Okta tenant setup where we provision accounts for all users – those users are customers, vendors, subcontractors, their end users. What this entails is that we have a wide variety of email domains (both company and personal) that are provisioned in our source of truth - Okta. In our situation, we don't care if someone has domainA or domainB, nor do we intend to provide them with an email address with our domain. That type of thinking belongs in the 2000s, with the advent and maturity around OpenID, someone's own trusted identity - their mail address - should be considered. Not an entire domain. 

The old Jira-On-Demand OWA, which required a service account in the specific Atlassian cloud tenant, didn't have this opinion either. 

Given our ecosystem configuration as described above, in addition to the documentation that Okta puts out regarding provisioning of the Jira cloud (https://saml-doc.okta.com/Provisioning_Docs/Jira_Cloud_Provisioning\), where it clearly states that Atlassian does not support the currently implemented method regarding user credential sync, what is Atlassian's proposed (attainable) solution.

Hi reiss.snooks1831337561 and all (for those who are using Azure AD): We are working with Azure AD closely on getting the official Azure AD support ready and are ironing out the last few issues. Thanks for your patience! I hope to come here and share the good news very soon. 

Lingbo 

Atlassian Access

A good step in the right direction but we are desperately in need of the official Azure AD support. Manually managing user access after enabling SSO is a nightmare for us with over 500 end users.

Gotcha and thanks for your response Dave.  We have the internal service desk customer portion figured out through the method you described.  But we are struggling with external users.

I understand the global Atlassian login issue, but if you do not migrate your service desk customers to an Atlassian account and you leave them as portal-only accounts in your instance, you have the ability through the UI to edit their "Full name" (displayName) and password for your instance.

We would love to have the ability to tap into that and link it to our existing customer directory.  Right now we run into huge problems trying to keep our customer information synced and we do not want to use the service desk portal because it would mean making our customers maintain multiple logins.  At the very least, it would be great to be able to update those by hitting an API endpoint when we see an update in the directory on our side (which we cannot), but would be even better to establish a direct connection that is in sync in a similar way to G Suite and Okta now.

Sorry to clog up this issue with this commentary, but it seems very relevant and is a huge gap right now.  Would love to find a place to work towards that solution.

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

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. 

Would appreciate an update on this as well.

No updates on this?