Hi,

We are excited to announce that we have shipped the Authentication policies feature. Using this feature you can bypass SSO for certain managed accounts. (https://www.atlassian.com/software/access/guide/elements/authentication-policies#why-apply-multiple-authentication-policies). We are still in the last leg of the rollout. If your organization doesn’t have the feature yet, file a support ticket (https://support.atlassian.com/contact/#/) and we will enable the feature for you.

Thanks,

The Atlassian Access team.

The authentication policy feature has been released in early October 2020.
You can use this feature to set an authentication policy for each managed account.

• Authentication policies

However, This feature is only available on new Org that have subscribed to Atlassian access since early October 2020.
If your environment does not meet this requirement, you will need to create a new organization and migrate your organization's products.

I hope Atlassian will apply authentication policies to older organizations as well.

I would like to have a bypass as an emergency measure to avoid a situation where the administrator account becomes unavailable for login due to misconfiguration.

From my perspective, the most critical requirement is that of a group-based, policy-based, or per-user setting to disable SSO in a specific scope.  The purpose being to ensure that privileged administrative accounts (which should already be separate from user-level accounts) are able to be used to access the Atlassian Admin tools in the event of an IdP integration failure - such as to log in and disable SSO, so that users can work until the issue is resolved.  

This should be such a basic feature, to allow integration accounts to be local accounts and still comply with Regulation, 

i also think the  priority should be raised , so this matter will get solved.

We are having the same issue here - moved to Access and now some of our distribution group Atlassian accounts aren't working.

Its sad that they have not provided a fix yet. This is forcing us to evaluate our choice of Project managment tool

In our case, we only need a specific group/dept that has access to our confluence site to use SSO.  users of other units should not be authenticated using our SSO and be able to continue with their local accounts

This is very important, as ISO 27001 regulations demand that you cannot have organisational-level accounts that are not tied to specific human beings.  So if we create a "generic" corporate gsuite account to use for Jira integrations (to avoid having integrations tied to an individual who may leave the company, etc), we would be in violation of those rules.  On the other hand, if we were able to just create a Jira account with a password and NOT tie that to an corporate gsuite account, we would be totally fine.  

So, essentially until this problem is resolved, we're stuck between a rock and a hard place – do we violate ISO 27001 regulations or do we instead tie Jira integrations to an individual account, with all the problems related to that? 

Looking at this I would argue priority needs to be increased from low.  As I think this through this is a security vulnerability.  If you think about it the current architecture it allows anyone to setup an account and if they are able to hack-in to a domain's root site to add the needed code for domain verification they could take over as a domain admin, implement SAML to an endpoint they own, then log-in with any user including admins as they would own authentication.

While it would be hard to achieve the steps for domain verification it would not be impossible, and current security architecture would allow this vulnerability in this scenario.  A similar comment applies to AA-14