mirror of https://github.com/docker/docs.git
SSO restructuring
This commit is contained in:
Jerae Duffin
parent
24158cc3c2
commit
90e69cb85c
|
|
@ -1673,11 +1673,17 @@ manuals:
|
|||
- sectiontitle: Single-Sign-on
|
||||
section:
|
||||
- path: /single-sign-on/
|
||||
title: Overview
|
||||
- path: /single-sign-on/requirements/
|
||||
title: Requirements
|
||||
- path: /single-sign-on/configure/
|
||||
title: Configure
|
||||
- path: /single-sign-on/manage/
|
||||
title: Manage
|
||||
- path: /single-sign-on/faqs/
|
||||
title: FAQs
|
||||
- path: /docker-hub/scim/
|
||||
title: System for Cross-domain Identity Management
|
||||
title: SCIM
|
||||
- path: /docker-hub/image-access-management/
|
||||
title: Image Access Management
|
||||
- path: /docker-hub/registry-access-management/
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
description: System for Cross-domain Identity Management
|
||||
keywords: SCIM, SSO
|
||||
title: System for Cross-domain Identity Management
|
||||
title: SCIM
|
||||
---
|
||||
|
||||
This section is for administrators who want to enable System for Cross-domain Identity Management (SCIM) 2.0 for their business. SCIM is a provisioning system that lets you manage users within your identity provider (IdP). You can enable SCIM on organizations that are part of the Docker Business subscription. To upgrade your existing account to a Docker Business subscription, see [Upgrade your subscription](../subscription/upgrade.md){:target="blank" rel="noopener" class=""}.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,158 @@
|
|||
---
|
||||
description: SSO configuration
|
||||
keywords: configure, sso, docker hub, hub
|
||||
title: Configure
|
||||
---
|
||||
|
||||
To configure SSO, sign in to [Docker Hub](https://hub.docker.com){: target="_blank" rel="noopener" class="_"} to complete the IdP server configuration process. You can only configure SSO with a single IdP. When this is complete, log back in to [Docker Hub](https://hub.docker.com){: target="_blank" rel="noopener" class="_"} and complete the SSO enablement process.
|
||||
|
||||
> **Important**
|
||||
>
|
||||
> If your IdP setup requires an Entity ID and the ACS URL, you must select the
|
||||
> **SAML** tab in the **Authentication Method** section. For example, if your
|
||||
> Azure AD Open ID Connect (OIDC) setup uses SAML configuration within Azure
|
||||
> AD, you must select **SAML**. If you are [configuring Open ID Connect with Azure AD](https://docs.microsoft.com/en-us/powerapps/maker/portals/configure/configure-openid-settings){: target="_blank" rel="noopener" class="_"} select
|
||||
> **Azure AD** as the authentication method. Also, IdP initiated connections
|
||||
> aren't supported at this time.
|
||||
{: .important}
|
||||
|
||||
The following video walks you through the process of configuring SSO.
|
||||
|
||||
<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/QY0j02ggf64" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
|
||||
### Configuring your IdP
|
||||
|
||||
<ul class="nav nav-tabs">
|
||||
<li class="active"><a data-toggle="tab" data-target="#SAML 2.0">SAML 2.0</a></li>
|
||||
<li><a data-toggle="tab" data-target="#Azure AD (OIDC)">Azure AD (OIDC)</a></li>
|
||||
</ul>
|
||||
<div class="tab-content">
|
||||
<div id="windows" class="tab-pane fade in active" markdown="1">
|
||||
|
||||
#### SAML 2.0
|
||||
|
||||
1. Sign in to [Docker Hub](https://hub.docker.com){: target="_blank" rel="noopener" class="_"} as an administrator and navigate to **Organizations** and select the organization that you want to enable SSO on.
|
||||
2. Select **Settings** and select the **Security** tab.
|
||||
3. Select an authentication method for **SAML 2.0**.
|
||||
|
||||
{:width="500px"}
|
||||
|
||||
4. In the Identity Provider Set Up, copy the **Entity ID**, **ACS URL** and **Certificate Download URL**.
|
||||
|
||||
{:width="500px"}
|
||||
|
||||
5. Sign in to your IdP to complete the IdP server configuration process. Refer to your IdP documentation for detailed instructions.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> The NameID is your email address and is set as the default.
|
||||
> For example, yourname@mycompany.com. We also support the optional `name` attribute. This attribute name must be lower-cased. _The following is an example of this attribute in Okta._
|
||||
|
||||
{:width="500px"}
|
||||
|
||||
6. Complete the fields in the **Configuration Settings** section and select **Save**. If you want to change your IdP, you must delete your existing provider and configure SSO with your new IdP.
|
||||
|
||||
{:width="500px"}
|
||||
|
||||
7. Proceed to **add your domain** before you test and enforce SSO.
|
||||
|
||||
<hr>
|
||||
</div>
|
||||
<div id="Azure AD" class="tab-pane fade" markdown="1">
|
||||
|
||||
### Azure AD (OIDC)
|
||||
|
||||
>**Note**
|
||||
>
|
||||
> This section is for users who only want to configure Open ID Connect with
|
||||
> Azure AD. This connection is a basic OIDC connection, and there are no
|
||||
> special customizations available when using it.
|
||||
|
||||
1. Sign in to [Docker Hub](https://hub.docker.com){: target="_blank" rel="noopener" class="_"} as an administrator and navigate to **Organizations** and select the organization that you want to enable SSO on.
|
||||
2. Select **Settings** and select the **Security** tab.
|
||||
3. Select an authentication method for **Azure AD**.
|
||||
4. In the Identity Provider Set Up, copy the **Redirect URL / Reply URL**.
|
||||
|
||||
{:width="500px"}
|
||||
|
||||
5. Sign in to your IdP to complete the IdP server configuration process. Refer to your IdP documentation for detailed instructions.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> The NameID is your email address and is set as the default.
|
||||
> For example: yourname@mycompany.com.
|
||||
|
||||
6. Complete the fields in the **Configuration Settings** section and click **Save**. If you want to change your IdP, you must delete your existing provider and configure SSO with your new IdP.
|
||||
|
||||
{:width="500px"}
|
||||
|
||||
7. Proceed to **add your domain** before you test and enforce SSO.
|
||||
|
||||
## Domain control
|
||||
|
||||
Select **Add Domain** and specify the corporate domain you’d like to manage with SSO. Format your domains without protocol or www information, for example, yourcompany.com. Docker supports multiple domains that are part of your IdP. Make sure that your domain is reachable through email.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> This should include all email domains and sub-domains users will use to access Docker.
|
||||
> Public domains such as gmail.com, outlook.com, etc aren't permitted.
|
||||
> Also, the email domain should be set as the primary email.
|
||||
|
||||
{:width="500px"}
|
||||
|
||||
<hr>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
## Domain verification
|
||||
|
||||
To verify ownership of a domain, add a TXT record to your Domain Name System (DNS) settings.
|
||||
|
||||
1. Copy the provided TXT record value and navigate to your DNS host and locate the **Settings** page to add a new record.
|
||||
2. Select the option to add a new record and paste the TXT record value into the applicable field. For example, the **Value**, **Answer** or **Description** field.
|
||||
|
||||
Your DNS record may have the following fields:
|
||||
* Record type: enter your 'TXT' record value
|
||||
* Name/Host/Alias: leave the default (@ or blank)
|
||||
* Time to live (TTL): enter **86400**
|
||||
|
||||
3. After you have updated the fields, select **Save**.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> It can take up to 72 hours for DNS changes to take effect, depending on
|
||||
> your DNS host. The Domains table will have an Unverified status during
|
||||
> this time.
|
||||
|
||||
4. In the Security section of your Docker organization, select **Verify** next to the domain you want to verify after 72 hours.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> Once you've verified your domain, you can move forward to test your
|
||||
> configuration and enforce SSO, or you can [Configure your System Cross-domain Identity Management (SCIM)](/docker-hub/scim.md).
|
||||
|
||||
## Test your SSO configuration
|
||||
|
||||
After you’ve completed the SSO configuration process in Docker Hub, you can test the configuration when you sign in to Docker Hub using an incognito browser. Login using your domain email address and IdP password. You will then get redirected to your identity provider’s login page to authenticate.
|
||||
|
||||
1. Authenticate through email instead of using your Docker ID, and test the login process.
|
||||
2. To authenticate through CLI, your users must have a PAT before you enforce SSO for CLI users.
|
||||
|
||||
## Enforce SSO in Docker Hub
|
||||
|
||||
Before you enforce SSO in Docker Hub, you must complete the following:
|
||||
Test SSO by logging in and out successfully, confirm that all members in your org have upgraded to Docker Desktop version 4.4.2, PATs are created for each member, CI/CD passwords are converted to PAT. Also, when using Docker partner products (for example, VS Code), you must use a PAT when you enforce SSO. For your service accounts add your additional domains in **Add Domains** or enable the accounts in your IdP.
|
||||
|
||||
Admins can force users to authenticate with Docker Desktop by provisioning a registry.json configuration file. The registry.json file will force users to authenticate as a user that's configured in the allowedOrgs list in the registry.json file. For info on how to configure a registry.json file see [Configure registry.json](../docker-hub/image-access-management.md#enforce-authentication)
|
||||
|
||||
1. On the Single Sign-On page in Docker Hub, select **Turn ON Enforcement** to enable your SSO.
|
||||
2. When SSO is enforced, your users are unable to modify their email address and password, convert a user account to an organization, or set up 2FA through Docker Hub. You must enable 2FA through your IdP.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> If you want to turn off SSO and revert back to Docker’s built-in
|
||||
> authentication, select **Turn OFF Enforcement**. Your users aren’t
|
||||
> forced to authenticate through your IdP and can sign in to Docker using
|
||||
> their personal credentials.
|
||||
|
||||
{:width="500px"}
|
||||
|
|
@ -13,11 +13,11 @@ Docker Single Sign-on (SSO) is only available with the Docker Business subscript
|
|||
|
||||
### Q: How does Docker SSO work?
|
||||
|
||||
Docker Single Sign-on (SSO) allows users to authenticate using their identity providers (IdPs) to access Docker. Docker currently supports Azure AD and any SAML 2.0 identity providers. When you enable SSO, users are redirected to your provider’s authentication page to authenticate using their email and password.
|
||||
Docker Single Sign-on (SSO) allows users to authenticate using their identity providers (IdPs) to access Docker. Docker supports Azure AD and any SAML 2.0 identity providers. When you enable SSO, users are redirected to your provider’s authentication page to authenticate using their email and password.
|
||||
|
||||
### Q: What SSO flows are supported by Docker?
|
||||
|
||||
Docker currently supports Service Provider Initiated (SP-initiated) SSO flow. This means users must sign in to Docker Hub or Docker Desktop to initiate the SSO authentication process.
|
||||
Docker supports Service Provider Initiated (SP-initiated) SSO flow. This means users must sign in to Docker Hub or Docker Desktop to initiate the SSO authentication process.
|
||||
|
||||
### Q: Where can I find detailed instructions on how to configure Docker SSO?
|
||||
|
||||
|
|
@ -29,35 +29,35 @@ When an organization uses SSO, MFA is determined on the IdP level, not on the Do
|
|||
|
||||
### Q: Do I need a specific version of Docker Desktop for SSO?
|
||||
|
||||
Yes, all users in your organization must upgrade to Docker Desktop version 4.4.0 or higher. Users on older versions of Docker Desktop will not be able to sign in after enforcing SSO if the company domain email is used to log in or as the primary email associated with an existing Docker account Your users with existing accounts cannot sign in with their username and password.
|
||||
Yes, all users in your organization must upgrade to Docker Desktop version 4.4.0 or later. Users on older versions of Docker Desktop will not be able to sign in after enforcing SSO if the company domain email is used to sign in or as the primary email associated with an existing Docker account Your users with existing accounts can't sign in with their username and password.
|
||||
|
||||
## SAML SSO
|
||||
|
||||
### Q: Does SAML authentication require additional attributes?
|
||||
|
||||
You must provide an email address as an attribute to authenticate through SAML. The ‘Name’ attribute is currently optional.
|
||||
You must provide an email address as an attribute to authenticate through SAML. The ‘Name’ attribute is optional.
|
||||
|
||||
### Q: Does the application recognize the NameID/Unique Identifier in the SAMLResponse Subject?
|
||||
### Q: Does the application recognize the NameID/Unique Identifier in the SAMLResponse subject?
|
||||
|
||||
The preferred format is your email address, which should also be your Name ID.
|
||||
|
||||
### Q: When SAML SSO is enforced, at what stage is the login required to be tracked through SAML? At runtime or install time?
|
||||
### Q: When you enforce SAML SSO, at what stage is the login required for tracking through SAML? At runtime or install time?
|
||||
|
||||
At runtime for Docker Desktop if it’s configured to require authentication to the organization.
|
||||
|
||||
### Q: How long is the grace-period for using regular user id and password for the docker desktop itself regardless of the enforced SSO?
|
||||
### Q: How long is the grace-period for using regular user id and password for the Docker Desktop itself regardless of the enforced SSO?
|
||||
|
||||
Currently, we do not have a date on when the grace-period will end.
|
||||
We don't have a date on when the grace-period will end.
|
||||
|
||||
### Q: Do you have any information on how to use the Docker Desktop application in accordance with the SSO users we provide? How can we verify that we are handling the licensing correctly?
|
||||
### Q: Do you have any information on how to use the Docker Desktop application in accordance with the SSO users we provide? How can we verify that we're handling the licensing correctly?
|
||||
|
||||
Verify that your users have downloaded the latest version of Docker Desktop. We will be enhancing user management observability and capabilities in the near future.
|
||||
Verify that your users have downloaded the latest version of Docker Desktop. An enhancement in user management observability and capabilities will become available in the future.
|
||||
|
||||
## Docker org and Docker ID
|
||||
|
||||
### Q: What’s a Docker ID? Can I retain my Docker ID when using SSO?
|
||||
|
||||
For a personal Docker ID, a user is the account owner, it’s associated with access to the user's repositories, images, assets. An end user can choose to have a company domain email on the Docker account, when SSO is enforced, the account will be tied to the organization account. Alternatively, when SSO is enforced for a company organization, any user logging in without an existing account using verified company domain email will automatically have an account provisioned, and a new Docker ID created.
|
||||
For a personal Docker ID, a user is the account owner, it’s associated with access to the user's repositories, images, assets. An end user can choose to have a company domain email on the Docker account, when enforcing SSO, the account is connected to the organization account. When enforcing SSO for a company organization, any user logging in without an existing account using verified company domain email will automatically have an account provisioned, and a new Docker ID created.
|
||||
|
||||
### Q: What if the Docker ID I want for my org is taken?
|
||||
|
||||
|
|
@ -65,17 +65,17 @@ This depends on the state of the namespace, if trademark claims exist for the Or
|
|||
|
||||
### Q: What if I want to create more than 3 organizations?
|
||||
|
||||
You can create multiple organizations or multiple teams under a single organization. If you intend to enforce SSO, SSO is currently only available for a single org with a single identity provider.
|
||||
You can create multiple organizations or multiple teams under a single organization. If you intend to enforce SSO, it's only available for a single org with a single identity provider.
|
||||
|
||||
### Q: If I have multiple orgs how will that affect my org if they are all connected to the same domain?
|
||||
### Q: If I have multiple orgs how will that affect my org if they're all connected to the same domain?
|
||||
|
||||
We are currently limited in supporting such a setup, and would recommend setting up different teams under the same org if you plan to enforce SSO and only have one email domain.
|
||||
We're currently limited in supporting such a setup, and would recommend setting up different teams under the same org if you plan to enforce SSO and only have one email domain.
|
||||
|
||||
## Identity providers
|
||||
|
||||
### Q: Is it possible to use more than one IdP with Docker SSO?
|
||||
|
||||
No. You can only configure Docker SSO to work with a single IdP. A domain can only be associated with a single IdP. Docker currently supports Azure AD and identity providers that support SAML 2.0.
|
||||
No. You can only configure Docker SSO to work with a single IdP. A domain can only be associated with a single IdP. Docker supports Azure AD and identity providers that support SAML 2.0.
|
||||
|
||||
### Q Is it possible to change my identity provider after configuring SSO?
|
||||
|
||||
|
|
@ -95,11 +95,11 @@ If your existing certificate has expired, you may need to contact your identity
|
|||
|
||||
### Q: What happens if my IdP goes down when SSO is enabled?
|
||||
|
||||
It is not possible to access Docker Hub when your IdP is down. However, you can access Docker Hub images from the CLI using your Personal Access Token. Or, if you had an existing account before the SSO enforcement, you can use your username and password to access Docker Hub images during the grace period for your organization.
|
||||
It's not possible to access Docker Hub when your IdP is down. However, you can access Docker Hub images from the CLI using your Personal Access Token. Or, if you had an existing account before the SSO enforcement, you can use your username and password to access Docker Hub images during the grace period for your organization.
|
||||
|
||||
### Q: What happens when I turn off SSO for my organization?
|
||||
|
||||
When you turn off SSO, authentication through your Identity Provider will no longer be required to access Docker. Users may continue to log in through Single Sign-On as well as Docker ID and password.
|
||||
When you turn off SSO, authentication through your Identity Provider isn't required to access Docker. Users may continue to sign in through Single Sign-On as well as Docker ID and password.
|
||||
|
||||
### Q: How do I handle accounts using Docker Hub as a secondary registry? Do I need a bot account?
|
||||
|
||||
|
|
@ -107,7 +107,7 @@ You can add a bot account to your IDP and create an access token for it to repla
|
|||
|
||||
### Q: Does Docker plan to release SAML just in time provisioning?
|
||||
|
||||
Our SSO implementation is already "just in time". Admins don't have to create users’ accounts on Hub, they can just enable it on the IdP and have the users log in through their domain email on Hub.
|
||||
The SSO implementation is already "just in time". Admins don't have to create users’ accounts on Hub, they can just enable it on the IdP and have the users sign in through their domain email on Hub.
|
||||
|
||||
### Q: Will there be IdP initiated logins? Does Docker plan to support SSO logins outside of Hub and Desktop?
|
||||
|
||||
|
|
@ -115,7 +115,7 @@ We currently do have any plans to enable IdP initiated logins.
|
|||
|
||||
### Q: Build agents - For customers using SSO, do they need to create a bot account to fill a seat within the dockerorg?
|
||||
|
||||
Yes, generally bot accounts need to be a seat, similar to a regular end user, having a non-aliased domain email enabled in the IdP and using a seat in Hub.
|
||||
Yes, bot accounts needs a seat, similar to a regular end user, having a non-aliased domain email enabled in the IdP and using a seat in Hub.
|
||||
|
||||
### Q: Is it possible to connect Docker Hub directly with a Microsoft Azure Active Directory Group?
|
||||
|
||||
|
|
@ -134,11 +134,11 @@ They can do it one time to add it to a connection. If they ever change idPs and
|
|||
|
||||
### Q: Is adding Domain required to configure SSO? What domains should I be adding? And how do I add it?
|
||||
|
||||
Adding and verifying Domain is required to enable and enforce SSO. Click Add Domain and specify the email domains that are allowed to authenticate through your server. This should include all email domains users will use to access Docker. Public domains are not permitted, such as gmail.com, outlook.com, etc. Also, the email domain should be set as the primary email.
|
||||
Adding and verifying Domain is required to enable and enforce SSO. Select **Add Domain** and specify the email domains that's allowed to authenticate through your server. This should include all email domains users will use to access Docker. Public domains are not permitted, such as gmail.com, outlook.com, etc. Also, the email domain should be set as the primary email.
|
||||
|
||||
### Q: If users are using their personal email, do they have to convert to using the Org’s domain before they can be invited to join an Org? Is this just a quick change in their Hub account?
|
||||
|
||||
No, they do not. Though they can add multiple emails to a Docker ID if they choose to. However, that email can only be used once across Docker. The other thing to note is that (as of January 2022) SSO will not work for multi domains as an MVP and it will not work for personal emails either.
|
||||
No, they don't. Though they can add multiple emails to a Docker ID if they choose to. However, that email can only be used once across Docker. The other thing to note is that (as of January 2022) SSO will not work for multi domains as an MVP and it will not work for personal emails either.
|
||||
|
||||
### Q: Since Docker ID is tracked from SAML, at what point is the login required to be tracked from SAML? Runtime or install time?
|
||||
|
||||
|
|
@ -146,7 +146,7 @@ Runtime for Docker Desktop if they configure Docker Desktop to require authentic
|
|||
|
||||
### Q: Do you support IdP-initiated authentication (e.g., Okta tile support)?
|
||||
|
||||
We do not support IdP-initiated authentication. Users must initiate login through Docker Desktop or Hub.
|
||||
We don't support IdP-initiated authentication. Users must initiate login through Docker Desktop or Hub.
|
||||
|
||||
## SSO enforcement
|
||||
|
||||
|
|
@ -179,7 +179,7 @@ Before enforcing SSO, you must create PATs for automation systems and CI/CD pipe
|
|||
|
||||
If they already have their organization email on their account, then it will be migrated to SSO.
|
||||
|
||||
### Q: If an organization enables SSO, the owners can control Docker IDs associated with their work email domain. Some of these Docker IDs will not be users of Docker Desktop and therefore don't require a Business subscription. Can the owners choose which Docker IDs they add to their Docker org and get access to Business features? Is there a way to flag which of these Docker IDs are Docker Desktop users?
|
||||
### Q: If an organization enables SSO, the owners can control Docker IDs associated with their work email domain. Some of these Docker IDs won't be users of Docker Desktop and therefore don't require a Business subscription. Can the owners choose which Docker IDs they add to their Docker org and get access to Business features? Is there a way to flag which of these Docker IDs are Docker Desktop users?
|
||||
|
||||
SSO enforcement will apply to any domain email user, and automatically add that user to the Docker Hub org that enables enforcement. The admin could remove users from the org manually, but those users wouldn't be able to authenticate if SSO is enforced.
|
||||
|
||||
|
|
@ -187,15 +187,15 @@ SSO enforcement will apply to any domain email user, and automatically add that
|
|||
|
||||
Yes, they can choose to not enforce, and users have the option to use either Docker ID (standard email/password) or email address (SSO) at the sign-in screen.
|
||||
|
||||
### Q: We have enforced SSO, but one of our users is connected to several organizations (and several email-addresses) and is able to bypass SSO and login through userid and password. Why is this happening?
|
||||
### Q: SSO is enforced, but one of our users is connected to several organizations (and several email-addresses) and is able to bypass SSO and login through userid and password. Why is this happening?
|
||||
|
||||
They can bypass SSO if the email they are using to log in doesn't match the organization email being used when SSO is enforced.
|
||||
They can bypass SSO if the email they're using to sign in doesn't match the organization email being used when SSO is enforced.
|
||||
|
||||
### Q: 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).
|
||||
|
||||
### Q: Once we enable SSO for Docker Desktop, what is the impact to the flow for Build systems that use service accounts?
|
||||
### Q: Once we enable SSO for Docker Desktop, what's the impact to the flow for Build systems that use service accounts?
|
||||
|
||||
If SSO is enabled, there is no impact for now. We'll continue to support either username/password or personal access token sign-in.
|
||||
However, if you **enforce** SSO:
|
||||
|
|
@ -224,17 +224,17 @@ Users with a public domain email address will be added as guests.
|
|||
|
||||
### Q: Can Docker Org Owners/Admins approve users to an organization and use a seat, rather than having them automatically added when SSO Is enabled?
|
||||
|
||||
Admins and organization owners can currently approve users by configuring their permissions through their IdP. That is, if the user account is configured in the IdP, the user will be automatically added to the organization in Docker Hub as long as there’s an available seat.
|
||||
Admins and organization owners can currently approve users by configuring their permissions through their IdP. That's if the user account is configured in the IdP, the user will be automatically added to the organization in Docker Hub as long as there’s an available seat.
|
||||
|
||||
### Q: How will users be made aware that they are being made a part of a Docker Org?
|
||||
### Q: How will users be made aware that they're being made a part of a Docker Org?
|
||||
|
||||
When SSO is enabled, users will be prompted to authenticate through SSO the next time they try to sign in to Docker Hub or Docker Desktop. The system will see the end-user has a domain email associated with the docker ID they are trying to authenticate with, and prompts them to sign in with SSO email and credentials instead.
|
||||
When SSO is enabled, users will be prompted to authenticate through SSO the next time they try to sign in to Docker Hub or Docker Desktop. The system will see the end-user has a domain email associated with the docker ID they're trying to authenticate with, and prompts them to sign in with SSO email and credentials instead.
|
||||
|
||||
If users attempt to log in through the CLI, they must authenticate using a personal access token (PAT).
|
||||
If users attempt to sign in through the CLI, they must authenticate using a personal access token (PAT).
|
||||
|
||||
### Q: Is it possible to force users of Docker Desktop to authenticate, and/or authenticate using their company’s domain?
|
||||
|
||||
Yes. Admins can force users to authenticate with Docker Desktop by provisioning a [`registry.json`](../docker-hub/configure-sign-in.md) configuration file. The `registry.json` file will force users to authenticate as a user that is configured in the `allowedOrgs` list in the `registry.json` file.
|
||||
Yes. Admins can force users to authenticate with Docker Desktop by provisioning a [`registry.json`](../docker-hub/configure-sign-in.md) configuration file. The `registry.json` file will force users to authenticate as a user that's configured in the `allowedOrgs` list in the `registry.json` file.
|
||||
|
||||
Once SSO enforcement is set up on their Docker Business org on Hub, when the user is forced to authenticate with Docker Desktop, the SSO enforcement will also force users to authenticate through SSO with their IdP (instead of authenticating using their username and password).
|
||||
|
||||
|
|
@ -245,8 +245,8 @@ Users may still be able to authenticate as a "guest" account to the organization
|
|||
Yes, you can convert existing users to an SSO account. To convert users from a non-SSO account:
|
||||
|
||||
* Ensure your users have a company domain email address and they have an account in your IdP
|
||||
* Verify that all users have Docker Desktop version 4.4.0 or higher installed on their machines
|
||||
* Each user has created a PAT to replace their passwords to allow them to log in through Docker CLI
|
||||
* Verify that all users have Docker Desktop version 4.4.0 or later installed on their machines
|
||||
* Each user has created a PAT to replace their passwords to allow them to sign in through Docker CLI
|
||||
* Confirm that all CI/CD pipelines automation systems have replaced their passwords with PATs.
|
||||
|
||||
For detailed prerequisites and instructions on how to enable SSO, see [Configure Single Sign-on](index.md).
|
||||
|
|
@ -257,17 +257,17 @@ When SSO is enabled and enforced, your users just have to sign in using the emai
|
|||
|
||||
### Q: Is Docker SSO fully synced with Active Directory (AD)?
|
||||
|
||||
Docker doesn’t currently support a full sync with AD. That is, if a user leaves the organization, administrators must sign in to Docker Hub and manually [remove the user](../docker-hub/members.md#remove-members) from the organization.
|
||||
Docker doesn’t currently support a full sync with AD. That's, if a user leaves the organization, administrators must sign in to Docker Hub and manually [remove the user](../docker-hub/members.md#remove-members) from the organization.
|
||||
|
||||
Additionally, you can use our APIs to complete this process.
|
||||
|
||||
### Q: What is the best way to provision the Docker Subscription without SSO?
|
||||
### Q: What's the best way to provision the Docker Subscription without SSO?
|
||||
|
||||
Admins in the Owners group in the orgs can invite users through Docker Hub UI, by email address (for any user) or by Docker ID (assuming the user has created a user account on Hub already).
|
||||
|
||||
### Q: If we add a user manually for the first time, can I register in the dashboard and will the user get an invitation link through email?
|
||||
|
||||
Yes, if the user is added through email address to an org, they will receive an email invite. If invited through docker ID as an existing user instead, they'll be added to the organization automatically. We'll be adding a new invite flow in the near future that will require an email invite in this situation as well (so the user can choose to opt out). If the org later sets up SSO for [zeiss.com](https://www.zeiss.com/) domain, the user will automatically be added to the domain SSO org next sign in which requires SSO auth with the identity provider (Hub login will automatically redirect to the identity provider).
|
||||
Yes, if the user is added through email address to an org, they will receive an email invite. If invited through Docker ID as an existing user instead, they'll be added to the organization automatically. A new invite flow will occur in the near future that will require an email invite (so the user can choose to opt out). If the org later sets up SSO for [zeiss.com](https://www.zeiss.com/) domain, the user will automatically be added to the domain SSO org next sign in which requires SSO auth with the identity provider (Hub login will automatically redirect to the identity provider).
|
||||
|
||||
### Q: Can someone join the organization without an invitation? Is it possible to put specific users to an organization with existing email accounts?
|
||||
|
||||
|
|
@ -281,11 +281,11 @@ Yes, the existing user account will join the organization with all assets retain
|
|||
|
||||
We only support one email per user on the Docker platform.
|
||||
|
||||
### Q: How can I remove invitees to the org who have not signed in?
|
||||
### Q: How can I remove invitees to the org who haven't signed in?
|
||||
|
||||
They can go to the invitee list in the org view and remove them.
|
||||
|
||||
### Q: How is the flow for service account authentication different from a UI user account?
|
||||
### Q: How's the flow for service account authentication different from a UI user account?
|
||||
|
||||
It isn't; we don't differentiate the two in product.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,22 +1,23 @@
|
|||
---
|
||||
description: Single Sign-on
|
||||
keywords: Single Sign-on, SSO, sign-on
|
||||
title: Configure Single Sign-on
|
||||
title: Overview
|
||||
---
|
||||
|
||||
This section is for administrators who want to enable Docker Single Sign-on (SSO) for their businesses. Docker SSO allows users to authenticate using their identity providers (IdPs) to access Docker. You can enable SSO on organizations that are part of the Docker Business subscription. To upgrade your existing account to a Docker Business subscription, see [Upgrade your subscription](../subscription/upgrade/){:target="blank" rel="noopener" class=""}.
|
||||
|
||||
When SSO is enabled, users are redirected to your provider’s authentication page to log in. They cannot authenticate using their Docker login credentials (Docker ID and password). Docker currently supports Service Provider Initiated SSO flow. Your users must sign in to Docker Hub or Docker Desktop to initiate the SSO authentication process.
|
||||
When SSO is enabled, users are redirected to your provider’s authentication page to sign in. They cannot authenticate using their Docker login credentials (Docker ID and password). Docker currently supports Service Provider Initiated SSO flow. Your users must sign in to Docker Hub or Docker Desktop to initiate the SSO authentication process.
|
||||
|
||||
Before enabling SSO in Docker Hub, administrators must configure their identity provider to configure their IdP to work with Docker Hub. Docker provides the Assertion Consumer Service (ACS) URL and the Entity ID. Administrators use this information to establish a connection between their IdP server and Docker Hub.
|
||||
|
||||
After establishing the connection between the IdP server and Docker Hub, administrators log in to the organization in Docker Hub and complete the SSO enablement process. See the section **Enable SSO in Docker Hub** for detailed instructions.
|
||||
After establishing the connection between the IdP server and Docker Hub, administrators sign in to the organization in Docker Hub and complete the SSO enablement process. See the section **Enable SSO in Docker Hub** for detailed instructions.
|
||||
|
||||
To enable SSO in Docker Hub, you need the following information from your identity provider:
|
||||
|
||||
* **SAML 2.0**: Single Sign-On URL and the X.509 signing certificate
|
||||
* **Azure AD**: Client ID (a unique identifier for your registered AD application), Client Secret (a string used to gain access to your registered Azure AD application), and AD Domain details
|
||||
|
||||
We currently support enabling SSO on a single organization. However, we do not support single logout. If you have any users in your organization with a different domain (including social domains), they will be added to the organization as guests. Guests will continue to authenticate through Docker with their Docker login credentials (Docker ID and password).
|
||||
Currently, enabling SSO on a single organization is supported. However, single logout isn't supported. If you have any users in your organization with a different domain (including social domains), they will be added to the organization as guests. Guests will continue to authenticate through Docker with their Docker login credentials (Docker ID and password).
|
||||
|
||||
|
||||
## Single Sign-on architecture flow
|
||||
|
|
@ -24,190 +25,3 @@ We currently support enabling SSO on a single organization. However, we do not s
|
|||
The following diagram shows how Single Sign-on (SSO) operates and is managed in Docker Hub and Docker Desktop. In addition, it provides information on how to authenticate between your IdPs.
|
||||
|
||||
[](images/sso-architecture.png){: target="_blank" rel="noopener" class="_"}
|
||||
|
||||
|
||||
## Prerequisites
|
||||
|
||||
* You must first notify your company about the new SSO login procedures
|
||||
* Verify that your org members have Docker Desktop version 4.4.2 installed on their machines
|
||||
* New org members must create a PAT to log in to the CLI, however existing users can currently use their username and password during the grace period as specified below
|
||||
* Confirm that all CI/CD pipelines have replaced their passwords with PATs
|
||||
* For your service accounts, add your additional domains or enable it in your IdP
|
||||
* Test SSO using your domain email address and IdP password to successfully log in and log out of Docker Hub
|
||||
|
||||
## Create a Personal Access Token (PAT)
|
||||
|
||||
Before you configure SSO for your organization, new members of your organization must [create an access token](../docker-hub/access-tokens.md) to log in to the CLI. There is currently a grace period for existing users, which will expire in the near future. Before the grace period ends, your users will be able to log in from Docker Desktop CLI using their previous credentials until PATs are mandatory.
|
||||
In addition, all email addresses should be added to your IdP.
|
||||
|
||||
## Configure
|
||||
|
||||
To configure SSO, log in to [Docker Hub](https://hub.docker.com){: target="_blank" rel="noopener" class="_"} to complete the IdP server configuration process. You can only configure SSO with a single IdP. When this is complete, log back in to [Docker Hub](https://hub.docker.com){: target="_blank" rel="noopener" class="_"} and complete the SSO enablement process.
|
||||
|
||||
> **Important**
|
||||
>
|
||||
> If your IdP setup requires an Entity ID and the ACS URL, you must select the
|
||||
> **SAML** tab in the **Authentication Method** section. For example, if your
|
||||
> Azure AD setup uses SAML configuration within Azure AD, you must select
|
||||
> **SAML**. If you are [configuring Open ID Connect with Azure AD](https://docs.microsoft.com/en-us/powerapps/maker/portals/configure/configure-openid-settings){: target="_blank" rel="noopener" class="_"} select **Azure AD** as the
|
||||
> authentication method. Also, IdP initiated connections are not supported at
|
||||
> this time.
|
||||
{: .important}
|
||||
|
||||
The following video walks you through the process of configuring SSO.
|
||||
|
||||
<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/QY0j02ggf64" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
|
||||
### SAML 2.0 IdP configuration
|
||||
|
||||
1. Log in to [Docker Hub](https://hub.docker.com){: target="_blank" rel="noopener" class="_"} as an administrator and navigate to **Organizations** and select the organization that you want to enable SSO on.
|
||||
2. Click **Settings** and select the **Security** tab.
|
||||
3. Select an authentication method for **SAML 2.0**.
|
||||
|
||||
{:width="500px"}
|
||||
|
||||
4. In the Identity Provider Set Up, copy the **Entity ID**, **ACS URL** and **Certificate Download URL**.
|
||||
|
||||
{:width="500px"}
|
||||
|
||||
5. Log in to your IdP to complete the IdP server configuration process. Refer to your IdP documentation for detailed instructions.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> The NameID is your email address and is set as the default.
|
||||
> For example, yourname@mycompany.com. We also support the optional `name` attribute. This attribute name must be lower-cased. _The following is an example of this attribute in Okta._
|
||||
|
||||
{:width="500px"}
|
||||
|
||||
6. Complete the fields in the **Configuration Settings** section and click **Save**. If you want to change your IdP, you must delete your existing provider and configure SSO with your new IdP.
|
||||
|
||||
{:width="500px"}
|
||||
|
||||
7. Proceed to **add your domain** before you test and enforce SSO.
|
||||
|
||||
### Azure AD IdP configuration with Open ID Connect
|
||||
|
||||
>**Note**
|
||||
>
|
||||
> This section is for users who only want to configure Open ID Connect with
|
||||
> Azure AD. This connection is a basic OIDC connection, and there are no
|
||||
> special customizations available when using it.
|
||||
|
||||
1. Log in to [Docker Hub](https://hub.docker.com){: target="_blank" rel="noopener" class="_"} as an administrator and navigate to **Organizations** and select the organization that you want to enable SSO on.
|
||||
2. Click **Settings** and select the **Security** tab.
|
||||
3. Select an authentication method for **Azure AD**.
|
||||
4. In the Identity Provider Set Up, copy the **Redirect URL / Reply URL**.
|
||||
|
||||
{:width="500px"}
|
||||
|
||||
5. Log in to your IdP to complete the IdP server configuration process. Refer to your IdP documentation for detailed instructions.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> The NameID is your email address and is set as the default.
|
||||
> For example: yourname@mycompany.com.
|
||||
|
||||
6. Complete the fields in the **Configuration Settings** section and click **Save**. If you want to change your IdP, you must delete your existing provider and configure SSO with your new IdP.
|
||||
|
||||
{:width="500px"}
|
||||
|
||||
7. Proceed to **add your domain** before you test and enforce SSO.
|
||||
|
||||
## Domain control
|
||||
|
||||
Click **Add Domain** and specify the corporate domain you’d like to manage with SSO. Domains should be formatted without protocol or www information, for example, yourcompany.com. Docker currently supports multiple domains that are part of your IdP. Make sure that your domain is reachable through email.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> This should include all email domains and sub-domains users will use to access Docker.
|
||||
> Public domains such as gmail.com, outlook.com, etc are not permitted.
|
||||
> Also, the email domain should be set as the primary email.
|
||||
|
||||
{:width="500px"}
|
||||
|
||||
## Domain verification
|
||||
|
||||
To verify ownership of a domain, add a TXT record to your Domain Name System (DNS) settings.
|
||||
|
||||
1. Copy the provided TXT record value and navigate to your DNS host and locate the **Settings** page to add a new record.
|
||||
2. Select the option to add a new record and paste the TXT record value into the applicable field. For example, the **Value**, **Answer** or **Description** field.
|
||||
|
||||
Your DNS record may have the following fields:
|
||||
* Record type: enter your 'TXT' record value
|
||||
* Name/Host/Alias: leave the default (@ or blank)
|
||||
* Time to live (TTL): enter **86400**
|
||||
|
||||
3. After you have updated the fields, click **Save**.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> It can take up to 72 hours for DNS changes to take effect, depending on
|
||||
> your DNS host. The Domains table will have an Unverified status during
|
||||
> this time.
|
||||
|
||||
4. In the Security section of your Docker organization, click **Verify** next to the domain you want to verify after 72 hours.
|
||||
|
||||
Once you've verified your domain, you can move forward to test your configuration and enforce SSO, or you can [Configure your System Cross-domain Identity Management (SCIM)](../docker-hub/scim.md).
|
||||
|
||||
## Test your SSO configuration
|
||||
|
||||
After you’ve completed the SSO configuration process in Docker Hub, you can test the configuration when you log in to Docker Hub using an incognito browser. Login using your domain email address and IdP password. You will then get redirected to your identity provider’s login page to authenticate.
|
||||
|
||||
1. Authenticate through email instead of using your Docker ID, and test the login process.
|
||||
2. To authenticate through CLI, your users must have a PAT before you enforce SSO for CLI users.
|
||||
|
||||
## Enforce SSO in Docker Hub
|
||||
|
||||
Before you enforce SSO in Docker Hub, you must complete the following:
|
||||
Test SSO by logging in and out successfully, confirm that all members in your org have upgraded to Docker Desktop version 4.4.2, PATs are created for each member, CI/CD passwords are converted to PAT. Also, when using Docker partner products (for example, VS Code), you must use a PAT when you enforce SSO. For your service accounts add your additional domains in **Add Domains** or enable the accounts in your IdP.
|
||||
|
||||
Admins can force users to authenticate with Docker Desktop by provisioning a registry.json configuration file. The registry.json file will force users to authenticate as a user that is configured in the allowedOrgs list in the registry.json file. For info on how to configure a registry.json file see [Configure registry.json](../docker-hub/image-access-management.md#enforce-authentication)
|
||||
|
||||
1. On the Single Sign-On page in Docker Hub, click **Turn ON Enforcement** to enable your SSO.
|
||||
2. When SSO is enforced, your members are unable to modify their email address and password, convert a user account to an organization, or set up 2FA through Docker Hub. You must enable 2FA through your IdP.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> If you want to turn off SSO and revert back to Docker’s built-in
|
||||
> authentication, click **Turn OFF Enforcement**. Your members aren’t
|
||||
> forced to authenticate through your IdP and can log in to Docker using
|
||||
> their personal credentials.
|
||||
|
||||
{:width="500px"}
|
||||
|
||||
## Manage users when SSO is enabled
|
||||
|
||||
You don’t need to add users to your organization in Docker Hub manually. You just need to make sure an account for your users exists in your IdP.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> When you enable SSO for your organization, a first-time user can log in to Docker Hub using their company's domain email address. They are then added to your organization and assigned to your company's team.
|
||||
|
||||
To add a guest to your organization in Docker Hub if they aren’t verified through your IdP:
|
||||
|
||||
1. Go to **Organizations** in Docker Hub, and select your organization.
|
||||
2. Click **Add Member**, enter the email address, and select a team from the drop-down list.
|
||||
3. Click **Add** to confirm.
|
||||
|
||||
## Remove members from the SSO organization
|
||||
|
||||
To remove a member from an organization:
|
||||
|
||||
1. Log in to [Docker Hub](https://hub.docker.com){: target="_blank" rel="noopener" class="_"} as an administrator of your organization.
|
||||
2. Select the organization from the list. The organization page displays a list of members.
|
||||
3. Click the **x** next to a member’s name to remove them from all the teams in the organization.
|
||||
4. Click **Remove** to confirm. The member will receive an email notification confirming the removal.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> When you remove a member from an SSO organization, they are unable to log
|
||||
> in using their email address.
|
||||
|
||||
## FAQs
|
||||
To learn more see our [FAQs](faqs.md).
|
||||
|
||||
## Deleting SSO
|
||||
|
||||
When you disable SSO, you can delete the connection to remove the configuration settings and the added domains. Once you delete this connection, it cannot be undone. Users must authenticate with their Docker ID and password or create a password reset if they do not have one.
|
||||
|
||||
{:width="500px"}
|
||||
|
|
|
|||
|
|
@ -0,0 +1,44 @@
|
|||
---
|
||||
description: Manage SSO
|
||||
keywords: manage, single sign-on, SSO, sign-on
|
||||
title: Manage SSO
|
||||
---
|
||||
|
||||
## Manage users when SSO is enabled
|
||||
|
||||
You don’t need to add users to your organization in Docker Hub manually. You just need to make sure an account for your users exists in your IdP.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> When you enable SSO for your organization, a first-time user can sign in to Docker Hub using their company's domain email address. They're then added to your organization and assigned to your company's team.
|
||||
|
||||
To add a guest to your organization in Docker Hub if they aren’t verified through your IdP:
|
||||
|
||||
1. Go to **Organizations** in Docker Hub, and select your organization.
|
||||
2. Select **Add Member**, enter the email address, and select a team from the drop-down list.
|
||||
3. Select **Add** to confirm.
|
||||
|
||||
## Remove users from the SSO organization
|
||||
|
||||
To remove a user from an organization:
|
||||
|
||||
1. Sign in to [Docker Hub](https://hub.docker.com){: target="_blank" rel="noopener" class="_"} as an administrator of your organization.
|
||||
2. Select the organization from the list. The organization page displays a list of user.
|
||||
3. Select the **x** next to a member’s name to remove them from all the teams in the organization.
|
||||
4. Select **Remove** to confirm. The member will receive an email notification confirming the removal.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> When you remove a member from an SSO organization, they're unable to log
|
||||
> in using their email address.
|
||||
|
||||
|
||||
## Deleting SSO
|
||||
|
||||
When you disable SSO, you can delete the connection to remove the configuration settings and the added domains. Once you delete this connection, it can't be undone. Users must authenticate with their Docker ID and password or create a password reset if they don't have one.
|
||||
|
||||
{:width="500px"}
|
||||
|
||||
## FAQs
|
||||
|
||||
To learn more see [FAQs](/single-sign-on/faqs.md).
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
---
|
||||
description: Single Sign-on requirements
|
||||
keywords: Single Sign-on, SSO, sign-on, requirements
|
||||
title: Requirements
|
||||
---
|
||||
## Prerequisites
|
||||
|
||||
* You must first notify your company about the new SSO login procedures
|
||||
* Verify that your org members have Docker Desktop version 4.4.2 installed on their machines
|
||||
* New org members must create a PAT to sign in to the CLI, however existing users can use their username and password during the grace period as specified below
|
||||
* Confirm that all CI/CD pipelines have replaced their passwords with PATs
|
||||
* For your service accounts, add your additional domains or enable it in your IdP
|
||||
* Test SSO using your domain email address and IdP password to successfully sign in and log out of Docker Hub
|
||||
|
||||
## Create a Personal Access Token (PAT)
|
||||
|
||||
Before you configure SSO for your organization, new members of your organization must [create an access token](/docker-hub/access-tokens.md) to sign in to the CLI. There is a grace period for existing users, which will expire in the near future. Before the grace period ends, your users will be able to sign in from Docker Desktop CLI using their previous credentials until PATs are mandatory.
|
||||
In addition, you should add all email addresses to your IdP.
|
||||
Loading…
Reference in New Issue