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

Ability to control site/organization access for accounts via user provisioning

    • 49
    • 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.

      Issue summary

      Currently, when the account's product access is removed via provisioning, the site access will remain. 

      The other way around, if the site access is revoked on the site, provisioning will not be able to turn it on based on when product access is provisioned via groups. 

      Suggestion

      In the old admin UI, provide the ability to control site access for accounts via user provisioning.
      In the new admin UI, the ability to suspend and unsuspend the user in the organization via user provisioning

      Workaround

      While the site/organization access cannot be controlled via user provisioning, consider using some other methods to revoke/re-grant access to the products.

      • Use (license) groups to grant and revoke access. This can be configured via provisioning
      • Deactivate/reactivate the Atlassian Account via provisioning. Note that this will also block access to other products such as Trello and Bitbucket.

          Form Name

            [ACCESS-1009] Ability to control site/organization access for accounts via user provisioning

            Note that you also need an APIs to move users between policies as well as list users, and their status (disabled or not) in the policies.

            Davide Trombini added a comment - Note that you also need an APIs to move users between policies as well as list users, and their status (disabled or not) in the policies.

            Ivan Shtanichev added a comment - - edited

            The workaround currently mentioned in description doesn't work, I've come across some accounts which have had their product access and Atlassian account enabled through SCIM provisioning, but despite this their site access remains in revoked state and has to be manually enabled to resolve. The bottom line is that site access seems to work independently of provisioning, product or org access. So users may have product and org access enabled (though provisioning or manually), but their site access is independent toggle which may still be off.

            Ivan Shtanichev added a comment - - edited The workaround currently mentioned in description doesn't work, I've come across some accounts which have had their product access and Atlassian account enabled through SCIM provisioning, but despite this their site access remains in revoked state and has to be manually enabled to resolve. The bottom line is that site access seems to work independently of provisioning, product or org access. So users may have product and org access enabled (though provisioning or manually), but their site access is independent toggle which may still be off.

            I have also encountered this problem and would very much like to see this get resolved. When provisioned users outside verified domains are deactivated in IDP, then their Atlassian Site access should be revoked automatically. When it comes to external (third party and contractor) leavers it is important that user access revoked with promptly (based on user deactivation in the IDP) to prevent unauthorised access. It makes sense that the Atlassian account (of users outside verified domains) should remain active, since it is not managed by the Org which owns the site, but the Site access is entirely under the Org control and should therefore be revoked automatically when those users leave.

            Ivan Shtanichev added a comment - I have also encountered this problem and would very much like to see this get resolved. When provisioned users outside verified domains are deactivated in IDP, then their Atlassian Site access should be revoked automatically. When it comes to external (third party and contractor) leavers it is important that user access revoked with promptly (based on user deactivation in the IDP) to prevent unauthorised access. It makes sense that the Atlassian account (of users outside verified domains) should remain active, since it is not managed by the Org which owns the site, but the Site access is entirely under the Org control and should therefore be revoked automatically when those users leave.

              maho Matthew Ho (Inactive)
              umasih@atlassian.com Ulka
              Votes:
              32 Vote for this issue
              Watchers:
              39 Start watching this issue

                Created:
                Updated: