Uploaded image for project: 'Atlassian Guard'
  1. Atlassian Guard
  2. ACCESS-604

Grant users synced from identity providers via SCIM application access by default

    • 812
    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      Problem Definition

      When User Provisioning is enabled in the identity provider, created users through push group from the IdP are just added to the synced group in the Cloud site and not to the default application access group(s).

      This creates a problem when the Cloud instance has a lot of existing projects/spaces with access already granted to default app groups.

      Workarounds

      There are currently a few possible workarounds for admins:

      1. The admin(s) would need to manually grant synced IdP groups access to existing Jira projects / Confluence spaces OR manually add the users to the default app group on Atlassian side. Which is a time-consuming process if there are a lot of projects/spaces in the instance.
      2. RECOMMENDED: The admin(s) would need to configure the synced group from the IDP to grant product licenses and permissions with the same configuration as the default group (can be time-consuming depending on how many places the default group has been given access to).
      3. The admin(s) can configure the Approved Domain settings (see the Approved Domain support doc), to allow users with their email domain to get access to the necessary products as needed. These users will be put into the default product access groups.
      4. The out of the box default groups (such as jira-software-users-sitename) can be taken over by the IdP.
        1. Create a new group, e.g. default-jira-software-users-sitename, and make it the default group for your product.
        2. For the standard default group (e.g. jira-software-users-sitename), remove it as the default group for your product.
        3. Create a group in your IdP with the standard default group name (e.g. jira-software-users-sitename) and sync your users who need product access into this group.
        4. The group will be 'taken over' by your IdP, the users will sync from your IdP, but the project/space settings will be kept as is.

       

      In case additional support is required, please raise a ticket with Atlassian Support.

          Form Name

            [ACCESS-604] Grant users synced from identity providers via SCIM application access by default

            vv this is the exact same problem we're having.   +1!  

            sean.stephenson@tundraoilandgas.com added a comment - vv this is the exact same problem we're having.   +1!  

            +1 on this feature or grant the ability to have nested groups.  Our synced groups could be children of the default built in groups.

            The current behavior is problematic because folks can 'onboard' themselves without being provisioned into the proper groups.  Our permission schemes are linked to the groups that sync.  So, when a user joins a product without being added to the correct company groups, their account sits in Atlassian default groups with no permission and we have to manually re-arrange group members.  THANKS!

            Jessica Hart added a comment - +1 on this feature or grant the ability to have nested groups.  Our synced groups could be children of the default built in groups. The current behavior is problematic because folks can 'onboard' themselves without being provisioned into the proper groups.  Our permission schemes are linked to the groups that sync.  So, when a user joins a product without being added to the correct company groups, their account sits in Atlassian default groups with no permission and we have to manually re-arrange group members.  THANKS!

            Sami Shaik added a comment -

            As usual another long awaited "Gather Interest" ticket.

            Sami Shaik added a comment - As usual another long awaited "Gather Interest" ticket.

            Isai Navarro added a comment - https://getsupport.atlassian.com/browse/CES-62798

            Kieren _SmolSoftware_ added a comment - - edited

            We've released an app to fix this issue, Admin Automation, and to solve other challenging and time consuming admin tasks. The app will sync users from any groups (e.g. a group from an IdP) into the default product access groups.

            Hopefully it can help some of the people on this thread!

            -Kieren
            Co-Founder @ Smol Software | Ex-Atlassian

            Kieren _SmolSoftware_ added a comment - - edited We've released an app to fix this issue, Admin Automation , and to solve other challenging and time consuming admin tasks. The app will sync users from any groups (e.g. a group from an IdP) into the default product access groups. Hopefully it can help some of the people on this thread! -Kieren Co-Founder @ Smol Software | Ex-Atlassian

            #3 (Adding to Approved Domains) will NOT work unless the user logs into the portal.

            We really need to have default Customer access for all synced accounts and shouldn't rely solely on a synced group to provided access. We manage over 250,000 accounts and highly limited by the group and user limits in Access. Our Atlassian support person has been awesome working with us so far on this, but we really need default access for all users synced from a directory. 

            Brandon Viertel added a comment - #3 (Adding to Approved Domains) will NOT work unless the user logs into the portal. We really need to have default Customer access for all synced accounts and shouldn't rely solely on a synced group to provided access. We manage over 250,000 accounts and highly limited by the group and user limits in Access. Our Atlassian support person has been awesome working with us so far on this, but we really need default access for all users synced from a directory. 

            I'm working with support on this issue right now. Workaround #3 listed above does NOT work (it actually broke BEFORE I implemented SCIM)... users in approved domains are NOT being added to the default groups, nor are they granted access to the products.

             

            Greyson Mitchem added a comment - I'm working with support on this issue right now. Workaround #3 listed above does NOT work (it actually broke BEFORE I implemented SCIM)... users in approved domains are NOT being added to the default groups, nor are they granted access to the products.  

            Dan Goren added a comment -

            Can we get an ETA on this "feature"?

            Dan Goren added a comment - Can we get an ETA on this "feature"?

            Calvin Lee added a comment -

            +1 this needs to be a feature. I don't understand why we can't sync push groups to the built-in / existing groups to begin with. We are currently implementing Atlassian Access and because we had to create a new SCIM group for Confluence, we now have to figure out how we're going to add this new group to all our existing Spaces...

            Calvin Lee added a comment - +1 this needs to be a feature. I don't understand why we can't sync push groups to the built-in / existing groups to begin with. We are currently implementing Atlassian Access and because we had to create a new SCIM group for Confluence, we now have to figure out how we're going to add this new group to all our existing Spaces...

            I'm trying to implement scim and want to make sure I'm understanding this point support told me. So I want to have IDP groups that I drop people in that would give access to each product separately as some users don't need access to Jira, or Confluence. 

             

            So if I'm understanding correctly, I could create a new default group for each and leave them empty, and have the same name on the IDP side as Atlassian for the actual group I want them added to even if it's not the default on the Atlassian side anymore.

            Would that work correctly? Users that have the Jira group would get Jira Access and Confluence group would have access to Confluence, just automating the access to remove human tasks a bit more.

            Ahmed Karam added a comment - I'm trying to implement scim and want to make sure I'm understanding this point support told me. So I want to have IDP groups that I drop people in that would give access to each product separately as some users don't need access to Jira, or Confluence.    So if I'm understanding correctly, I could create a new default group for each and leave them empty, and have the same name on the IDP side as Atlassian for the actual group I want them added to even if it's not the default on the Atlassian side anymore. Would that work correctly? Users that have the Jira group would get Jira Access and Confluence group would have access to Confluence, just automating the access to remove human tasks a bit more.

            Can we get an ETA on this "feature"?

            Michael Gutierrez added a comment - Can we get an ETA on this "feature"?

            This Feature is available in Jira Data Center but it is lacking in Jira cloud. It makes the user management and user provisioning complicated. Also, this feature is required for site admins and org admins.

            Dibyandu Roy added a comment - This Feature is available in Jira Data Center but it is lacking in Jira cloud. It makes the user management and user provisioning complicated. Also, this feature is required for site admins and org admins.

            @Kieren, you are correct.   I did figure it out.

            Harold Price added a comment - @Kieren, you are correct.   I did figure it out.

            Meghashrita Kashyap added a comment - https://getsupport.atlassian.com/browse/JST-909795#

            Hi 53f97136ab50 , You are able to have two default groups for the same role. See screenshot below. What issue/error occured when you tried this?

            Kieren (Inactive) added a comment - Hi 53f97136ab50 , You are able to have two default groups for the same role. See screenshot below. What issue/error occured when you tried this?

            Workaround #4 sounded the most promising. 

            "1. Create a new group, e.g. default-jira-software-users-sitename, and make it the default group for your product." 

            Unfortunately, you can not have more than one default group per role type (ie "User") for Confluence.  So the second part of step 1 can not be completed

            Harold Price added a comment - Workaround #4 sounded the most promising.  "1. Create a new group, e.g. default-jira-software-users-sitename, and make it the default group for your product."  Unfortunately, you can not have more than one default group per role type (ie "User") for Confluence.  So the second part of step 1 can not be completed

            Not having this ability adds a great deal of complexity into what should be a simple onboarding process for new users. Please can we haz? 

            Joshua Kochelek added a comment - Not having this ability adds a great deal of complexity into what should be a simple onboarding process for new users. Please can we haz? 

            migrating from on-prem Jira Server to Jira Cloud.  Lost native LDAP integration, need to pay $$$ to get Atlassian Access for directory integration.  OK, set up Access to SSO+SCIM from Azure AD, only to hit this 4 year old bug.  Yes, it's a bug, enabling Access breaks default Jira Cloud behavior.  Really have to wonder about Atlassian's priorities. 

            Clint Bowen added a comment - migrating from on-prem Jira Server to Jira Cloud.  Lost native LDAP integration, need to pay $$$ to get Atlassian Access for directory integration.  OK, set up Access to SSO+SCIM from Azure AD, only to hit this 4 year old bug .  Yes, it's a bug, enabling Access breaks default Jira Cloud behavior.  Really have to wonder about Atlassian's priorities. 

            We are also seeing this same issue in OneLogin. The biggest pain point for us is the confluence-users default access group as it was scoped to MANY spaces as having view rights, so if users do not have this group when they're provisioned they are missing out on a lot of content. This requires manual intervention which should not be necessary when using SCIM. 

            Would love to see a fix for this asap as this is impacting a huge portion of our users. 

            Katie Sanders added a comment - We are also seeing this same issue in OneLogin. The biggest pain point for us is the confluence-users default access group as it was scoped to MANY spaces as having view rights, so if users do not have this group when they're provisioned they are missing out on a lot of content. This requires manual intervention which should not be necessary when using SCIM.  Would love to see a fix for this asap as this is impacting a huge portion of our users. 

            This should be at or near the top of the list of functionality that the integration/provisioing team at Atlassian should be working on. Using SCIM provisioning has been a standard for years and the fact that Atlassian is only partially able to perfomr these processes without admin intervention is absurd.

            Thomas H Edwards added a comment - This should be at or near the top of the list of functionality that the integration/provisioing team at Atlassian should be working on. Using SCIM provisioning has been a standard for years and the fact that Atlassian is only partially able to perfomr these processes without admin intervention is absurd.

            Is anyone really taking a look at this issue? It has been created in 2018 & is still in "Gathering Interest" status!! Can Atlassian please get this implemented at the earliest so as to relieve the admins of the pain they have to go through for manually assigning products to individual users.

            Pradeep Nene added a comment - Is anyone really taking a look at this issue? It has been created in 2018 & is still in "Gathering Interest" status!! Can Atlassian please get this implemented at the earliest so as to relieve the admins of the pain they have to go through for manually assigning products to individual users.

            Agreed, why is this taking so long?  Considering that we have to pay extra for Atlassian Access this is extremely annoying.  We pay for a provisioning tool that doesn't actually allow you to give access to users...classic.

            Joe Doperalski added a comment - Agreed, why is this taking so long?  Considering that we have to pay extra for Atlassian Access this is extremely annoying.  We pay for a provisioning tool that doesn't actually allow you to give access to users...classic.

            Why is this taking so long to action and resolve? It would seem pretty fundamental to user provisioning that we can actually sync them to the default groups that manage product permissions. At least let us change the default groups to our own if we can't sync them to Atlassian's default user groups. This is going on long enough now and is just extremely frustrating.

            Susan Hickey added a comment - Why is this taking so long to action and resolve? It would seem pretty fundamental to user provisioning that we can actually sync them to the default groups that manage product permissions. At least let us change the default groups to our own if we can't sync them to Atlassian's default user groups. This is going on long enough now and is just extremely frustrating.

            Poat added a comment -

            found out late in the game this wasn't happening after setting up product access across the board for okta.  anyone have a workaround instead of manually correcting users?

            Poat added a comment - found out late in the game this wasn't happening after setting up product access across the board for okta.  anyone have a workaround instead of manually correcting users?

            Dan Tombs added a comment -

            I cannot believe this is not already functionality. Having to manually add people to groups or manually update every space and project is not really an appropriate solution.

            Dan Tombs added a comment - I cannot believe this is not already functionality. Having to manually add people to groups or manually update every space and project is not really an appropriate solution.

            Is there any way to sync confluence-users members of the SCIM pushed group so that confluence-users reflects the membership of the push group?

            Mike McCollum added a comment - Is there any way to sync confluence-users members of the SCIM pushed group so that confluence-users reflects the membership of the push group?

            Two apps: conversing
            Or talking past each other?
            Should be of one mind.

            Please implement this so groups can suck a little less

            Haddon Fisher added a comment - Two apps: conversing Or talking past each other? Should be of one mind. Please implement this so groups can suck a little less

            +1

            as per Atlassian support April 2021 ......  "It is definitely being worked on priority by our identity team however we do not have an ETA for the same"

            Martin.Ocallaghan added a comment - as per Atlassian support April 2021 ......  "It is definitely being worked on priority by our identity team however we do not have an ETA for the same"

            +1

            Brad Hosking added a comment - - edited

            Okta user here and on premise with Mini-Orange app integration in confluence we could do this. We could provision crudely using SAML/OKTA/RegEx to these default groups. Now migrated to Atlassian Access and we can't link? Manually having to change the default group is seriously not fun and you can't just copy/paste one spaces settings in Confluence to another as they are all different.

            Please prioritise this for the next users who don't have to go through my pain.

            Brad Hosking added a comment - - edited Okta user here and on premise with Mini-Orange app integration in confluence we could do this. We could provision crudely using SAML/OKTA/RegEx to these default groups. Now migrated to Atlassian Access and we can't link? Manually having to change the default group is seriously not fun and you can't just copy/paste one spaces settings in Confluence to another as they are all different. Please prioritise this for the next users who don't have to go through my pain.

            allow ability to link imported groups with built-in ones or at least to be able to nest them somehow

            sergey.nikolaev added a comment - allow ability to link imported groups with built-in ones or at least to be able to nest them somehow

            Mike Naik added a comment -

            eric.gardner: I think I did exactly what you are considering doing and it worked fine, see my comment here: https://jira.atlassian.com/browse/ACCESS-604?focusedCommentId=2820988&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-2820988

            Mike Naik added a comment - eric.gardner: I think I did exactly what you are considering doing and it worked fine, see my comment here: https://jira.atlassian.com/browse/ACCESS-604?focusedCommentId=2820988&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-2820988

            having a picklist on the okta application admin side would be great. We have a large org and all employees have access to Confluence and Jira. I ran into this issue and thought ok maybe if I push confluence-user or jira-software-users or jirs-service-management but honestly at this point I am too scared to do so.

            eric.gardner added a comment - having a picklist on the okta application admin side would be great. We have a large org and all employees have access to Confluence and Jira. I ran into this issue and thought ok maybe if I push confluence-user or jira-software-users or jirs-service-management but honestly at this point I am too scared to do so.

            We are also having this problem.  Just switched to Access to make our lives easier and remove manual work, but it's not any easier.

            Carina Gerry added a comment - We are also having this problem.  Just switched to Access to make our lives easier and remove manual work, but it's not any easier.

            Jennifer Hecht added a comment - - edited

            We recently enforced OneLogin via Atlassian Access and are also struggling with this limitation. Syncing SCIM groups to default access groups or support of nested groups would fix this. Please prioritize.

            Jennifer Hecht added a comment - - edited We recently enforced OneLogin via Atlassian Access and are also struggling with this limitation. Syncing SCIM groups to default access groups or support of nested groups would fix this. Please prioritize.

            +1. As a fast growing org that extensively uses Atlassian products we recently implemented Okta to help manage our identity, only to find that this part of our setup is horribly broken without manual admin.
            Please fix this ASAP  

            David Baverstock added a comment - +1. As a fast growing org that extensively uses Atlassian products we recently implemented Okta to help manage our identity, only to find that this part of our setup is horribly broken without manual admin. Please fix this ASAP  

            +1

            +1 for all above ^

            KK Campbell added a comment - +1 for all above ^

            Mike Naik added a comment -

            We use G-Suite and migrated to Atlassian access late last year and it took me a while to come up with a workaround for this.  I came up with this a few months ago and haven't seen any issues yet.  The issue does need to be fixed but if anyone else is struggling, here's the workaround I used (it may not work in more complex configurations but it worked for us), it assumes there's a single group in your SCIM/Google Groups that granted access to Atlassian:

            1. Create a new group in Atlassian that has access to nothing and make that the new Default Access Group for Atlassian
              • Any users added outside of SCIM/G-Suite would get no access by default (this wasn't an issue for us)
              • Note the existing Default Access groups as you'll be replicating the names below
            2. Create new groups in your SCIM application or G-Suite with the exact same names as your previous Default Groups in Atlassian (such as "jira-software-users" and "confluence-users" if you are using the default groups)
              • You can remove any visibility into these groups, they'll basically just be shadow group meant for this workaround
            3. Add your existing Atlassian Access group as the only child member of each our new shadow groups so that anyone in those groups will immediately be members of the shadow groups that have the identical name as your already-configured Jira groups
              • If you used more than 1 group to enable Atlassian Access, you can likely add additional groups here to get the workaround to work for multiple sets of users.
            4. Configure Atlassian to sync those shadow groups from your SCIM/G-Suite in addition to the default group
            5. Trigger a sync
            6. Any existing permissions that the users had via the default access groups are now provided by the shadow groups synced from your SCIM/GSuite and the Atlassian configurations rather than the Default Group
            7. You can continue adding new users to your existing Atlassian Access group and they'll get added to the shadow groups, which will sync via Atlassian Access and all of your legacy permissions using those groups will now allow these new users to have access

            Note: Since it's a synced group, you won't be able to make any modifications to it inside of Atlassian.

            Hope someone out there finds that useful.

            Mike Naik added a comment - We use G-Suite and migrated to Atlassian access late last year and it took me a while to come up with a workaround for this.  I came up with this a few months ago and haven't seen any issues yet.  The issue does need to be fixed but if anyone else is struggling, here's the workaround I used (it may not work in more complex configurations but it worked for us), it assumes there's a single group in your SCIM/Google Groups that granted access to Atlassian: Create a new group in Atlassian that has access to nothing and make that the new Default Access Group for Atlassian Any users added outside of SCIM/G-Suite would get no access by default (this wasn't an issue for us) Note the existing Default Access groups as you'll be replicating the names below Create new groups in your SCIM application or G-Suite with the exact same names as your previous Default Groups in Atlassian (such as "jira-software-users" and "confluence-users" if you are using the default groups) You can remove any visibility into these groups, they'll basically just be shadow group meant for this workaround Add your existing Atlassian Access group as the only child member of each our new shadow groups so that anyone in those groups will immediately be members of the shadow groups that have the identical name as your already-configured Jira groups If you used more than 1 group to enable Atlassian Access, you can likely add additional groups here to get the workaround to work for multiple sets of users. Configure Atlassian to sync those shadow groups from your SCIM/G-Suite in addition to the default group Trigger a sync Any existing permissions that the users had via the default access groups are now provided by the shadow groups synced from your SCIM/GSuite and the Atlassian configurations rather than the Default Group You can continue adding new users to your existing Atlassian Access group and they'll get added to the shadow groups, which will sync via Atlassian Access and all of your legacy permissions using those groups will now allow these new users to have access Note: Since it's a synced group, you won't be able to make any modifications to it inside of Atlassian. Hope someone out there finds that useful.

            This is a huge issue for essentially anyone that has migrated to Cloud, or has implemented Access after using Atlassian products for some time. It's totally unrealistic for organizations to swap out the existing jira/confluence-users group with a new synced group on all projects and all spaces just to get basic provisioning going from our identity providers.

            nbiddle@eventbrite.com added a comment - This is a huge issue for essentially anyone that has migrated to Cloud, or has implemented Access after using Atlassian products for some time. It's totally unrealistic for organizations to swap out the existing jira/confluence-users group with a new synced group on all projects and all spaces just to get basic provisioning going from our identity providers.

            Agree with the comments above. Still having to grant product access via the default group when we've already created a Google group which by default, we want the members of it to have access to the tools, is a missed opportunity to have a fully streamlined onboarding (and offboarding) experience as admins. I would really like to see this rectified asap. Thanks

            Susan Hickey added a comment - Agree with the comments above. Still having to grant product access via the default group when we've already created a Google group which by default, we want the members of it to have access to the tools, is a missed opportunity to have a fully streamlined onboarding (and offboarding) experience as admins. I would really like to see this rectified asap. Thanks

            We view this as critical as well.  There's really no point in having automated user provisioning if we still have to go and touch each user to place them in the needed group.

            Mark Tancil added a comment - We view this as critical as well.  There's really no point in having automated user provisioning if we still have to go and touch each user to place them in the needed group.

            Adding for context this is a huge issue for us aswell. Default access groups have been added and configured across a huge range of our jira/confluence footprint.

             

            thomas britton added a comment - Adding for context this is a huge issue for us aswell. Default access groups have been added and configured across a huge range of our jira/confluence footprint.  

            Ugh, not a great experience!  We have to pay extra for security features (Access) so we an use our IDP for SSO and SCIM, however it doesn't actually allow us to assign users to the appropriate groups to allow access in our already mature, highly configured org??  Really? Every time we provision a user we still have to manually go to Jira and add them to the existing groups.  What are we paying for??

            Joe Doperalski added a comment - Ugh, not a great experience!  We have to pay extra for security features (Access) so we an use our IDP for SSO and SCIM, however it doesn't actually allow us to assign users to the appropriate groups to allow access in our already mature, highly configured org??  Really? Every time we provision a user we still have to manually go to Jira and add them to the existing groups.  What are we paying for??

            What is the status and ETA of this being fixed? Atlassian forced us into a trial of Acess which we did not request, this broke how users were onboarded into default groups, and are then going to charge us for this "service".

            Honestly, securing your product should be included with Atlassian and not a separate product. If you are going to charge for security, you should damn well make sure it works. Access is broken.

            How do we request to get out of this trial and revert back to the free version of Gsuite Oauth that worked fine for us?

            Trey Bornmann added a comment - What is the status and ETA of this being fixed? Atlassian forced us into a trial of Acess which we did not request, this broke how users were onboarded into default groups, and are then going to charge us for this "service". Honestly, securing your product should be included with Atlassian and not a separate product. If you are going to charge for security, you should damn well make sure it works. Access is broken. How do we request to get out of this trial and revert back to the free version of Gsuite Oauth that worked fine for us?

            This is a huge issue for us! Since "jira-users" and "confluence-users" group is baked into so many pages and projects, manually locating all of those places and adding the new directory group is laborious and painstaking.

            My suggestion to resolve this is actually to allow the nesting of groups. Then you don't need Okta to take over a default group and cause issues for users who aren't in Okta but still need this access.

            Marisa Guarino added a comment - This is a huge issue for us! Since "jira-users" and "confluence-users" group is baked into so many pages and projects, manually locating all of those places and adding the new directory group is laborious and painstaking. My suggestion to resolve this is actually to allow the nesting of groups. Then you don't need Okta to take over a default group and cause issues for users who aren't in Okta but still need this access.

            Chris added a comment - - edited

            We have the same hurdle but the solution should not be to grant application access by default. In our case we have over 900 provisioned users, a majority of them being Service Desk customers which have no application access, and only around 150 Jira/Confluence users.

            There are other places in Jira to specify the default groups added to new projects/spaces, and unfortunately it is a process to go and add the new provisioned groups to all existing projects and spaces, there needs to be a better solution for this.

            Chris added a comment - - edited We have the same hurdle but the solution should not be to grant application access by default. In our case we have over 900 provisioned users, a majority of them being Service Desk customers which have no application access, and only around 150 Jira/Confluence users. There are other places in Jira to specify the default groups added to new projects/spaces, and unfortunately it is a process to go and add the new provisioned groups to all existing projects and spaces, there needs to be a better solution for this.

              e902c0832f88 Sudesh Peram
              vvisanakarrala Veera (Inactive)
              Votes:
              314 Vote for this issue
              Watchers:
              298 Start watching this issue

                Created:
                Updated: