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 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 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