-
Suggestion
-
Resolution: Fixed
-
None
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.
Problem Definition
For unmanaged accounts that are leveraged for purposes similar to add-on accounts, admins have no way of enforcing security policies.
In contrast, for managed accounts, admins have no method to bypass SSO initiated logins.
Suggested Solution
Allow Org Admins the ability the option to configure a managed account to use conventional SSO settings or force authentication against id.atlassian.com but still enforce security policies.
Why this is important
As a Site-admin, its not feasible to establish and maintain local service accounts for a few reasons:
1. Users that login to other Cloud instances wouldn't be redirected to SSO but they would still have security policies applied
2. Atlassian Accounts creates more administrative overhead (now that we have managed accounts it can be viewed as being uncomplimentary)
3. Atlassian Accounts cannot be enforced with security policies
Workaround
No workaround.
- is duplicated by
-
- Closed
-
- Closed
- is related to
-
- Closed
-
- Closed
- relates to
-
- Closed
- mentioned in
-
Page Loading...
-
-
-
-
-
-
-
-
-
-
-
[ACCESS-85] Allow bypassing SSO Authentication for Managed Accounts
| Remote Link | New: This issue links to "Page (Confluence)" [ 552764 ] |
| Description |
Original:
h3. Problem Definition
For unmanaged accounts that are leveraged for purposes similar to add-on accounts, admins have no way of enforcing security policies. In contrast, for managed accounts, admins have no method to bypass SSO initiated logins. h3. Suggested Solution Allow Org Admins the ability the option to configure a managed account to use conventional SSO settings or force authentication against id.atlassian.com *but* still enforce security policies. h3. Why this is important As a Site-admin, its not feasible to establish and maintain local service accounts for a few reasons: 1. Users that login to other Cloud instances wouldn't be redirected to SSO but they would still have security policies applied 2. Atlassian Accounts creates more administrative overhead (now that we have managed accounts it can be viewed as being uncomplimentary) 3. Atlassian Accounts cannot be enforced with security policies h3. Workaround No workaround. |
New:
{panel:title=Release update}
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. {panel} h3. Problem Definition For unmanaged accounts that are leveraged for purposes similar to add-on accounts, admins have no way of enforcing security policies. In contrast, for managed accounts, admins have no method to bypass SSO initiated logins. h3. Suggested Solution Allow Org Admins the ability the option to configure a managed account to use conventional SSO settings or force authentication against id.atlassian.com *but* still enforce security policies. h3. Why this is important As a Site-admin, its not feasible to establish and maintain local service accounts for a few reasons: 1. Users that login to other Cloud instances wouldn't be redirected to SSO but they would still have security policies applied 2. Atlassian Accounts creates more administrative overhead (now that we have managed accounts it can be viewed as being uncomplimentary) 3. Atlassian Accounts cannot be enforced with security policies h3. Workaround No workaround. |
| Resolution | New: Fixed [ 1 ] | |
| Status | Original: In Progress [ 3 ] | New: Closed [ 6 ] |
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.
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.
| Link |
New:
This issue relates to |
| Link |
New:
This issue is duplicated by |
| Remote Link | New: This issue links to "Page (Confluence)" [ 515306 ] |
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.
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.