mirror of https://github.com/docker/docs.git
iam: clarify enforce sign-in/sso (#21933)
## Description - Kapa returned an uncertain and incorrect response when a user asked `How does sign-in enforcement work when using the command line?` - Added a callout to enforce DD sign-in doc that clarifies that CLI login experience is not impacted - Clarified CLI login experience is only impacted for enforce SSO - Other nits while I was in these files, including removing mention of service accounts since they are no longer offered after Dec. 10 2024 ## Related issues or tickets - [ENGDOCS-2401](https://docker.atlassian.net/browse/ENGDOCS-2401) ## Reviews - [ ] Editorial review [ENGDOCS-2401]: https://docker.atlassian.net/browse/ENGDOCS-2401?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
This commit is contained in:
parent
1a75c30b20
commit
477606d2c2
|
@ -8,14 +8,10 @@ aliases:
|
|||
- /faq/security/single-sign-on/enforcement-faqs/
|
||||
---
|
||||
|
||||
### We currently have a Docker Team subscription. How do we enable SSO?
|
||||
### I currently have a Docker Team subscription. How do I enable SSO?
|
||||
|
||||
SSO is available with a Docker Business subscription. To enable SSO, you must first upgrade your subscription to a Docker Business subscription. To learn how to upgrade your existing account, see [Upgrade your subscription](../../../subscription/change.md).
|
||||
|
||||
### How do service accounts work with SSO?
|
||||
|
||||
Service accounts work like any other user when SSO is turned on. If the service account is using an email for a domain with SSO turned on, it needs a PAT for CLI and API usage.
|
||||
|
||||
### Is DNS verification required to enable SSO?
|
||||
|
||||
Yes. You must verify a domain before using it with an SSO connection.
|
||||
|
@ -26,9 +22,9 @@ When SSO is enforced, [passwords are prevented from accessing the Docker CLI](/s
|
|||
|
||||
Each user must create a PAT to access the CLI. To learn how to create a PAT, see [Manage access tokens](/security/for-developers/access-tokens/). Users who already used a PAT to sign in before SSO enforcement will still be able to use that PAT to authenticate.
|
||||
|
||||
### How does SSO affect our automation systems and CI/CD pipelines?
|
||||
### How does SSO affect automation systems and CI/CD pipelines?
|
||||
|
||||
Before enforcing SSO, you must create PATs for automation systems and CI/CD pipelines and use the tokens instead of a password.
|
||||
Before enforcing SSO, you must [create PATs](/security/for-developers/access-tokens/). These PATs are used instead of passwords for signing into automation systems and CI/CD pipelines.
|
||||
|
||||
### What can organization users who authenticated with personal emails prior to enforcement expect?
|
||||
|
||||
|
@ -38,26 +34,17 @@ Ensure your users have their organization email on their account, so that the ac
|
|||
|
||||
Yes, you can choose to not enforce, and users have the option to use either Docker ID (standard email and password) or domain-verified email address (SSO) at the sign-in screen.
|
||||
|
||||
### SSO is enforced, but one of our users is able to sign in through username and password. Why is this happening?
|
||||
### SSO is enforced, but a user can sign in using a username and password. Why is this happening?
|
||||
|
||||
Guest users who are not part of your registered domain but have been invited to your organization do not sign in through your SSO Identity Provider. SSO enforcement only requires that users which do belong to your domain, must go through the SSO IdP.
|
||||
|
||||
### Is there a way to test this functionality in a test tenant with Okta before going to production?
|
||||
|
||||
Yes, you can create a test organization. Companies can set up a new 5 seat Business plan on a new organization to test with (making sure to only enable SSO, not enforce it or all domain email users will be forced to sign in to that test tenant).
|
||||
|
||||
### Once we enable SSO for Docker Desktop, what's the impact to the flow for Build systems that use service accounts?
|
||||
|
||||
If you enable SSO, there is no impact. Both username/password or personal access token (PAT) sign-in are supported.
|
||||
However, if you enforce SSO:
|
||||
|
||||
- Service Account domain email addresses must not be aliased and must be enabled in their IdP
|
||||
- Username/password authentication [won’t work](/security/security-announcements/#deprecation-of-password-logins-on-cli-when-sso-enforced), so you should update the build system to use a PAT instead of a password
|
||||
- Those who know the IdP credentials can sign in as that Service Account through SSO on Hub and create or change the personal access token for that service account.
|
||||
Yes, you can create a test organization. Companies can set up a new 5 seat Business plan on a new organization to test with. To do this, make sure to only enable SSO, not enforce it, or all domain email users will be forced to sign in to that test tenant.
|
||||
|
||||
### Is the sign in required tracking at runtime or install time?
|
||||
|
||||
At runtime for Docker Desktop if it’s configured to require authentication to the organization.
|
||||
For Docker Desktop, if it's configured to require authentication to the organization, it tracks at runtime.
|
||||
|
||||
### What is enforcing SSO versus enforcing sign-in?
|
||||
|
||||
|
@ -65,7 +52,5 @@ Enforcing SSO and enforcing sign-in to Docker Desktop are different features tha
|
|||
|
||||
Enforcing SSO ensures that users sign in using their SSO credentials instead of their Docker ID. One of the benefits is that SSO enables you to better manage user credentials.
|
||||
|
||||
Enforcing sign-in to Docker Desktop ensures that users always sign in to an
|
||||
|
||||
account that's a member of your organization. The benefits are that your organization's security settings are always applied to the user's session and your users always receive the benefits of your subscription. For more details, see [Enforce sign-in for Desktop](../../../security/for-admins/enforce-sign-in/_index.md).
|
||||
Enforcing sign-in to Docker Desktop ensures that users always sign in to an account that's a member of your organization. The benefits are that your organization's security settings are always applied to the user's session and your users always receive the benefits of your subscription. For more details, see [Enforce sign-in for Desktop](../../../security/for-admins/enforce-sign-in/_index.md#enforcing-sign-in-versus-enforcing-single-sign-on-sso).
|
||||
|
||||
|
|
|
@ -27,8 +27,7 @@ There are multiple methods for enforcing sign-in, depending on your companies' s
|
|||
|
||||
## How is sign-in enforced?
|
||||
|
||||
When Docker Desktop starts and it detects a registry key, `.plist` file, or `registry.json` file, the
|
||||
following occurs:
|
||||
When Docker Desktop starts and it detects a registry key, `.plist` file, or `registry.json` file, the following occurs:
|
||||
|
||||
- A **Sign in required!** prompt appears requiring the user to sign
|
||||
in as a member of your organization to use Docker Desktop. ![Enforce Sign-in
|
||||
|
@ -41,10 +40,13 @@ following occurs:
|
|||
- When a user signs out, the **Sign in required!** prompt appears and they can
|
||||
no longer use Docker Desktop.
|
||||
|
||||
> [!NOTE]
|
||||
>
|
||||
> Enforcing sign-in for Docker Desktop does not impact accessing the Docker CLI. CLI access is only impacted for organizations that enforce single sign-on.
|
||||
|
||||
## Enforcing sign-in versus enforcing single sign-on (SSO)
|
||||
|
||||
[Enforcing SSO](/manuals/security/for-admins/single-sign-on/connect.md) and
|
||||
enforcing sign-in are different features. The following table provides a
|
||||
[Enforcing SSO](/manuals/security/for-admins/single-sign-on/connect.md#optional-enforce-sso) and enforcing sign-in are different features. The following table provides a
|
||||
description and benefits when using each feature.
|
||||
|
||||
| Enforcement | Description | Benefits |
|
||||
|
|
|
@ -211,6 +211,10 @@ Enforcing SSO requires users to use SSO when signing into Docker. This centraliz
|
|||
|
||||
Your users must now sign in to Docker with SSO.
|
||||
|
||||
> [!NOTE]
|
||||
>
|
||||
> When SSO is enforced, [users can't use passwords to access the Docker CLI](/security/security-announcements/#deprecation-of-password-logins-on-cli-when-sso-enforced). Users must use a [personal access token](/manuals/security/for-admins/access-tokens.md) (PAT) for authentication to access the Docker CLI.
|
||||
|
||||
## More resources
|
||||
|
||||
The following videos demonstrate how to enforce SSO.
|
||||
|
@ -223,3 +227,4 @@ The following videos demonstrate how to enforce SSO.
|
|||
|
||||
- [Provision users](/manuals/security/for-admins/provisioning/_index.md)
|
||||
- [Enforce sign-in](../enforce-sign-in/_index.md)
|
||||
- [Create access tokens](/manuals/security/for-admins/access-tokens.md)
|
||||
|
|
Loading…
Reference in New Issue