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

      Currently the authentication policies do not support automatic assignment which requires manual action to assign users to policies when they are created.

      Suggestion:

      • Make SCIM synced groups be able to assign authentication policies.
      • Also consider, automatically switching an (existing) account to an SSO policy when they are provisioned and non-billable when they are not. 

      The use case I can share for this is:
      We want only a group of people to be enforced SSO so we make the default authentication policy to be one that is not enforced with SSO but now the need to manually add users to that group of people that should have enforced SSO arises.

            [ACCESS-1041] Automatic assignment of authentication policies

            Can you please provide a reference on how to activate the corresponding EAP? We would like to evaluate the changes to Authentication Policies for our Org.

            Christof Cuypers - Abano added a comment - Can you please provide a reference on how to activate the corresponding EAP? We would like to evaluate the changes to Authentication Policies for our Org.

            Can you please provide a reference on how to activate the corresponding EAP? We would like to evaluate the changes to Authentication Policies for our Org.

            Eleanor Young added a comment - Can you please provide a reference on how to activate the corresponding EAP? We would like to evaluate the changes to Authentication Policies for our Org.

            We are currently in EAP for this feature . Once we have garnered all the feedback - we are planning to release this in Oct'25. 

            Kunwardeep Singh added a comment - We are currently in EAP for this feature . Once we have garnered all the feedback - we are planning to release this in Oct'25. 

            Can we have an update from Atlassian on this one? It has been around for 4 years. Its killing us really. Not all cohorts in our domain use the same tenant. Some use SSO, some dont. Every single new user is a manual process of moving to one auth policy or another. Linking to an automatically maintained group would resolve our issue immediately.

            Anthony Williams added a comment - Can we have an update from Atlassian on this one? It has been around for 4 years. Its killing us really. Not all cohorts in our domain use the same tenant. Some use SSO, some dont. Every single new user is a manual process of moving to one auth policy or another. Linking to an automatically maintained group would resolve our issue immediately.

            Are there anyone looking at this currently? The person who is assigned this task is "Inactive".

            This is a real problem for companies with many users, and the administration of this task takes alot of time to manage for new users.

            The solution of allowing the usage of groups instead of individual members/bulk entry would increase the security of the tenant for the company, since the authentication policy is directly applied to new users being synced in with SCIM provisioning.

            Anders Bratberg added a comment - Are there anyone looking at this currently? The person who is assigned this task is "Inactive". This is a real problem for companies with many users, and the administration of this task takes alot of time to manage for new users. The solution of allowing the usage of groups instead of individual members/bulk entry would increase the security of the tenant for the company, since the authentication policy is directly applied to new users being synced in with SCIM provisioning.

            Any updates? I see that the assignee is no longer with Atlassian.

            Nick E Buono added a comment - Any updates? I see that the assignee is no longer with Atlassian.

            We have actively started investigating this feature and will provide more updates as we have them.

            Holly Makris (Inactive) added a comment - We have actively started investigating this feature and will provide more updates as we have them.

            Mohan Rao added a comment -

            use case can be sorted

            Mohan Rao added a comment - use case can be sorted

            funny, I was just setting up Atlassian Guard with authentication policies. I was wondering, how can I auto assign these policies to users? After 2 sec google search, found this ticket.
            That this is not a basic feature is beyond me. Please implement this asap.

            Eelke van der Nat added a comment - funny, I was just setting up Atlassian Guard with authentication policies. I was wondering, how can I auto assign these policies to users? After 2 sec google search, found this ticket. That this is not a basic feature is beyond me. Please implement this asap.

            I don't understand how this is not a basic feature of Atlassian Access SSO. Do they really expect admins of thousands of users to manually juggle authentication policies?

            Hunter Britton added a comment - I don't understand how this is not a basic feature of Atlassian Access SSO. Do they really expect admins of thousands of users to manually juggle authentication policies?

            It's funny that everytime I look for a feature that should clearly be integrated in Jira, I end up on a ticket like this, some even from over 10 years ago. I am also adding my interest in this.

            André Blum added a comment - It's funny that everytime I look for a feature that should clearly be integrated in Jira, I end up on a ticket like this, some even from over 10 years ago. I am also adding my interest in this.

            Hi all,

            Thank you for your votes and comments on this ticket.  We are conducting further research into security policy assignment and want to understand how Admins are managing this process.

            We are inviting admins to participate in an upcoming customer research study.

            What’s involved:

            • Sessions will be 1 hour and conducted over Zoom.
            • During the session, we’ll get to know your general setup and ask about your experience with this feature request.
            • We may also explore conceptual diagrams and designs.
            • As a token of our appreciation, you’ll receive an e-gift card worth $100 USD after completing the session.

             

            If you’re interested in participating, please contact me at pzamuco@atlassian.com to schedule a time that works for you.

            If you have any other questions, please reply to this message or email me directly. We look forward to meeting you!

            Thank you,

            Patrick Zamuco

            Atlassian Product Designer

            Patrick Zamuco added a comment - Hi all, Thank you for your votes and comments on this ticket.  We are conducting further research into security policy assignment and want to understand how Admins are managing this process. We are inviting admins to participate in an upcoming customer research study. What’s involved: Sessions will be 1 hour and conducted over Zoom. During the session, we’ll get to know your general setup and ask about your experience with this feature request. We may also explore conceptual diagrams and designs. As a token of our appreciation, you’ll receive an e-gift card worth $100 USD after completing the session.   If you’re interested in participating, please contact me at pzamuco@atlassian.com to schedule a time that works for you. If you have any other questions, please reply to this message or email me directly. We look forward to meeting you! Thank you, Patrick Zamuco Atlassian Product Designer

            Nayem Reza added a comment -

            How this isn't already implemented is crazy. All my users will be SSO so why can't the default authentication policy that is applied to all users already be modified to enforce SSO??

            Nayem Reza added a comment - How this isn't already implemented is crazy. All my users will be SSO so why can't the default authentication policy that is applied to all users already be modified to enforce SSO??

            When users create accounts under our verified domain, we need them to be automatically assigned to either our non-billable or default billable security policy.
            Moving non-billable users out of the default security policy is at best unnecessary overhead for smaller organizations and at worst an untenable manual process for large organizations.
            Please consider the feature suggested here.

            Evan Mulloy added a comment - When users create accounts under our verified domain, we need them to be automatically assigned to either our non-billable or default billable security policy. Moving non-billable users out of the default security policy is at best unnecessary overhead for smaller organizations and at worst an untenable manual process for large organizations. Please consider the feature suggested here.

            @ a.vig   it took them 20 years to allow the renaming of groups in the admin portal. (2003 feature request)   so probably in 20 years.

            Gavin Teichman added a comment - @ a.vig   it took them 20 years to allow the renaming of groups in the admin portal. (2003 feature request)   so probably in 20 years.

            a.vig added a comment -

            When will this be fixed or added a feature? 

            a.vig added a comment - When will this be fixed or added a feature? 

            Ahhhh, I just realized this. So I have to manually maintain over 400 users and cross check to a group which is automatically updated now and then? This is crazy Please fix this!! 

            Cornelia Jeppsson added a comment - Ahhhh, I just realized this. So I have to manually maintain over 400 users and cross check to a group which is automatically updated now and then? This is crazy Please fix this!! 

            ridiculous that this doesnt exist.

            Gavin Teichman added a comment - ridiculous that this doesnt exist.

            I totally agree with everything above. We just implemented Atlassian Access and it's dumb that something like this isn't part of the tool in the first place.

            Unfortunately there isn't any other way how to implement SSO enforcement for the Atlassian tools. I hope new features are coming soon especially with automatic policy assignment.

            Matej Laucik added a comment - I totally agree with everything above. We just implemented Atlassian Access and it's dumb that something like this isn't part of the tool in the first place. Unfortunately there isn't any other way how to implement SSO enforcement for the Atlassian tools. I hope new features are coming soon especially with automatic policy assignment.

            Simon added a comment -

            We have just begun testing Atlassian Access and our SSO implementation for our company of 10k+ users, which operates globally in studios across 60 different domain.

            A number of the Atlassian accounts created within our organisation, whether they were invited by a client or set up an instance of their own are not associated with a user identity, but a distribution group or shared mailboxes and so cannot be used with an SSO Enforced authentication policy.

            In our assessment, we completely agree with Krista above. The first question that arose in our evaluation was on how we may automate or optimize the assignment of users and authentication policies within Atlassian Access.

            We would wish to ideally have the ability to assign Authentication policies to domains, or better yet through group membership, as this would give our administrators flexible and granular control directly through Active Directory, without having to use the Atlassian interface, which they are likely to not be familiar with.

            These challenges have held us back from implementing Atlassian Access across our organisation, we had reviewed it initially 2 years ago and found it not fit for purpose. Even though the Authentication Policies are a great step forward, we have to remain hesitant to make the move until the use of groups becomes possible, due to the administrative overhead that would result from claiming the accounts.

            Simon added a comment - We have just begun testing Atlassian Access and our SSO implementation for our company of 10k+ users, which operates globally in studios across 60 different domain. A number of the Atlassian accounts created within our organisation, whether they were invited by a client or set up an instance of their own are not associated with a user identity, but a distribution group or shared mailboxes and so cannot be used with an SSO Enforced authentication policy. In our assessment, we completely agree with Krista above. The first question that arose in our evaluation was on how we may automate or optimize the assignment of users and authentication policies within Atlassian Access. We would wish to ideally have the ability to assign Authentication policies to domains, or better yet through group membership, as this would give our administrators flexible and granular control directly through Active Directory, without having to use the Atlassian interface, which they are likely to not be familiar with. These challenges have held us back from implementing Atlassian Access across our organisation, we had reviewed it initially 2 years ago and found it not fit for purpose. Even though the Authentication Policies are a great step forward, we have to remain hesitant to make the move until the use of groups becomes possible, due to the administrative overhead that would result from claiming the accounts.

            Agree this is a surprise that it doesn't exist. I find there is a disconnect between the external ID sync (which is based upon groups), and product access (again, based upon groups), and authentication policies (which require you to specify members individually.... and yes you can bulk load, but still).

            Would be far better to be able to map a group to an authentication policy. I can see the subtleties here in that users can belong to multiple groups but only one authentication policy, so, yeah, there are details to figure out. But still, why can't I bulk load members by selecting a group?

            And better still, why can't I create a mapping so that the right users are automatically allocated to a specified policy?

            Krista Stellar added a comment - Agree this is a surprise that it doesn't exist. I find there is a disconnect between the external ID sync (which is based upon groups), and product access (again, based upon groups), and authentication policies (which require you to specify members individually.... and yes you can bulk load, but still). Would be far better to be able to map a group to an authentication policy. I can see the subtleties here in that users can belong to multiple groups but only one authentication policy, so, yeah, there are details to figure out. But still, why can't I bulk load members by selecting a group? And better still, why can't I create a mapping so that the right users are automatically allocated to a specified policy?

            I am a bit surprised that this functionality does not exist, we are also missing it from our setup.

            Rafal Binkowski added a comment - I am a bit surprised that this functionality does not exist, we are also missing it from our setup.

            WPG added a comment -

            Would like to have a Group or Sync Azure AD Group that can be added to Authentication policies (policy) in lieu of having to identify users manually. Should be some automated way of applying users to the correct policy.

            WPG added a comment - Would like to have a Group or Sync Azure AD Group that can be added to Authentication policies (policy) in lieu of having to identify users manually. Should be some automated way of applying users to the correct policy.

            We are using JSM for our company and have configured SSO via Authentication policies synching our AAD.

            We want to configure that not only agents but also each one one having an account on <ourdomain>.atlassian.net can access and authenticate via SSO to our JSM portal page. 

            With actual functionality we need to assign user per user or via bulk assignement. New employees are coming continously, we want to have automatic assignment support for assigning members to the policy (for new employees) for this scenario either by group or other settings (like in "Customer permissions" for JSM).

             

            Thomas Lorenzi added a comment - We are using JSM for our company and have configured SSO via Authentication policies synching our AAD. We want to configure that not only agents but also each one one having an account on <ourdomain>.atlassian.net can access and authenticate via SSO to our JSM portal page.  With actual functionality we need to assign user per user or via bulk assignement. New employees are coming continously, we want to have automatic assignment support for assigning members to the policy (for new employees) for this scenario either by group or other settings (like in "Customer permissions" for JSM).  

            In Authentication policies, we should support automatic assignment using both groups and user based.

            Consider a scenario where I have users from two domain i.e. abc.com & xyz.com. I should be able to apply default authentication policy for abc.com & separate policy for xyz.com, automatically.

            If any new user synced, then respective policy should be applied to the user, automatically, based on any filtering pattern.

            Gaurav Agrawal added a comment - In Authentication policies, we should support automatic assignment using both groups and user based. Consider a scenario where I have users from two domain i.e. abc.com & xyz.com. I should be able to apply default authentication policy for abc.com & separate policy for xyz.com, automatically. If any new user synced, then respective policy should be applied to the user, automatically, based on any filtering pattern.

              5cd8def7e384 Kunwardeep Singh
              6048cd401523 Felipe Oliveira
              Votes:
              377 Vote for this issue
              Watchers:
              271 Start watching this issue

                Created:
                Updated:
                Resolved: