docker
/
docs
mirror of https://github.com/docker/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #21239 from sarahsanders-docker/ENGDOCS-2269 

Update JIT, SCIM, and group mapping guides
This commit is contained in:
Sarah Sanders 2024-10-28 09:49:01 -07:00 committed by GitHub
parent 60bf7c8406 8a29833cd6
commit a691e88d9f
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
6 changed files with 148 additions and 142 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

49
content/manuals/security/for-admins/provisioning/group-mapping.md
View File

@ -7,31 +7,30 @@ aliases:
- /admin/organization/security-settings/group-mapping/
- /docker-hub/group-mapping/
- /security/for-admins/group-mapping/
weight: 40
---
With directory group-to-team provisioning from your IdP, user updates will automatically sync with your Docker organizations and teams. You can use group mapping once you have configured [single sign-on (SSO)](../single-sign-on/_index.md).
Group mapping lets you sync user groups from your identity provider (IdP) with teams in your Docker organization. This automates team membership management, keeping your Docker teams up to date based on changes in your IdP. You can use group mapping once you have configured [single sign-on (SSO)](../single-sign-on/_index.md).
> [!TIP]
>
> Group mapping is ideal for adding a user to multiple organizations or multiple teams within one organization. If you don't need to set up multi-organization or multi-team assignment, you can use [user-level attributes](scim.md#set-up-role-mapping).
> Group mapping is ideal for adding users to multiple organizations or multiple teams within one organization. If you don't need to set up multi-organization or multi-team assignment, you can use SCIM [user-level attributes](scim.md#set-up-role-mapping).
## How group mapping works
IdPs share with Docker the main attributes of every authorized user through SSO, such as email address, name, surname, and groups. Just-in-Time (JIT) Provisioning uses these attributes to create or update the user’s Docker profile and their associations with organizations and teams on Docker Hub.
With group mapping enabled, when a user authenticates through SSO, your IdP shares key attributes with Docker, such as the user's email address, name, and groups. Docker uses these attributes to create or update the user's profile, as well as to manage their team and organization assignments. With group mapping, users’ team memberships in Docker automatically reflect changes made in your IdP groups.
Docker uses the email address of the user to identify them on the platform. Every Docker account must have a unique email address at all times.
It's important to note that Docker uses the user's email address as a unique identifier. Each Docker account must always have a unique email address.
## Use group mapping
To correctly assign your users to Docker teams, you must create groups in your IdP following the naming pattern `organization:team`. For example, if you want to manage provisioning for the team "developers", and your organization name is "moby", you must create a group in your IdP with the name `moby:developers`.
To assign users to Docker teams through your IdP, you must create groups in your IdP following the naming pattern: `organization:team`. For example, if your organization is called "moby" and you want to manage the "developers" team, the group name in your IdP should be `moby:developers`. In this example, any user added to this group in your IdP is automatically assigned to the "developers" team in Docker.
Once you enable group mappings in your connection, users assigned to that group in your IdP will automatically be added to the team "developers" in Docker.
You can also use this format to assign users to multiple organizations. For example, to add a user to the "backend" team in the "moby" organization and the "desktop" team in the "whale" organization, the group names would be `moby:backend` and `whale:desktop`.
You can use this format to add a user to multiple organizations. For example, if you want to add a user to the "backend" team in the "moby" organization as well as the "desktop" team in the "whale" organization, the format would be: `moby:backend` and `whale:desktop`.
>**Tip**
> [!TIP]
>
>Use the same names for the Docker teams as your group names in the IdP to prevent further configuration. When you sync groups, this creates a group if it doesn’t already exist.
> Match the group names in your IdP with your Docker teams. When groups are synced, Docker creates a team if it doesn’t already exist.
The following lists the supported group mapping attributes:
@ -66,14 +65,14 @@ The user interface for your IdP may differ slightly from the following steps. Yo
To set up group mapping:
1. Sign in to the Okta Console to go to your application.
2. Go to the **SAML Settings** for your application.
1. Sign in to Okta and open your application.
2. Navigate to the **SAML Settings** page for your application.
3. In the **Group Attribute Statements (optional)** section, configure like the following:
- **Name**: `groups`
- **Name format**: `Unspecified`
- **Filter**: `Starts with` + `organization:` where `organization` is the name of your organization
The filter option will filter out the groups that aren't affiliated with your Docker organization.
4. Create your groups by navigating to **Directory > Groups**.
4. Create your groups by selecting **Directory**, then **Groups**.
5. Add your groups using the format `organization:team` that matches the names of your organization(s) and team(s) in Docker.
6. Assign users to the group(s) that you create.
@ -86,17 +85,17 @@ The user interface for your IdP may differ slightly from the following steps. Yo
To set up group mapping:
1. Sign in to Entra ID and go to your application.
2. Go to **Manage > Single sign-on**.
1. Sign in to Entra ID and open your application.
2. Select **Manage**, then **Single sign-on**.
3. Select **Add a group claim**.
4. In **Group Claims**, select **Groups assigned to the application** with the source attribute **Cloud-only group display names (Preview)**.
4. In the Group Claims section, select **Groups assigned to the application** with the source attribute **Cloud-only group display names (Preview)**.
5. Select **Advanced options**, then the **Filter groups** option.
6. Configure the attribute like the following:
- **Attribute to match**: `Display name`
- **Match with**: `Contains`
- **String**: `:`
7. Select **Save**.
8. Go to **Groups > All groups** then select **New group** to create your group(s).
8. Select **Groups**, **All groups**, then **New group** to create your group(s).
9. Assign users to the group(s) that you create.
The next time you sync your groups with Docker, your users will map to the Docker groups you defined.
@ -115,15 +114,15 @@ The user interface for your IdP may differ slightly from the following steps. Yo
To set up your groups:
1. Sign in to the Okta Console to go to your application.
2. Select **Applications > Provisioning > Integration**.
1. Sign in to Okta and open your application.
2. Select **Applications**, then **Provisioning**, and **Integration**.
3. Select **Edit** to enable groups on your connection, then select **Push groups**.
4. Select **Save**. Saving this configuration will add the **Push Groups** tab to your application.
5. Create your groups by navigating to **Directory > Groups**.
5. Create your groups by navigating to **Directory** and selecting **Groups**.
6. Add your groups using the format `organization:team` that matches the names of your organization(s) and team(s) in Docker.
7. Assign users to the group(s) that you create.
8. Return to **Applications > Provisioning > Integration**, then select the **Push Groups** tab to open the view where you can control and manage how groups are provisioned.
9. Select **Push Groups > Find groups by rule**.
8. Return to the **Integration** page, then select the **Push Groups** tab to open the view where you can control and manage how groups are provisioned.
9. Select **Push Groups**, then **Find groups by rule**.
10. Configure the groups by rule like the following:
- Enter a rule name, for example `Sync groups with Docker Hub`
- Match group by name, for example starts with `docker:` or contains `:` for multi-organization
@ -145,7 +144,7 @@ The user interface for your IdP may differ slightly from the following steps. Yo
Complete the following before configuring group mapping:
1. Sign in to Entra ID and go to your application.
2. In your application, go to **Provisioning > Mappings**.
2. In your application, select **Provisioning**, then **Mappings**.
3. Select **Provision Microsoft Entra ID Groups**.
4. Select **Show advanced options**, then **Edit attribute list**.
5. Update the `externalId` type to `reference`, then select the **Multi-Value** checkbox and choose the referenced object attribute `urn:ietf:params:scim:schemas:core:2.0:Group`.
@ -162,7 +161,7 @@ Next, set up group mapping:
5. Assign the group to the provisioning group.
6. Select **Start provisioning** to start the sync.
To verify, go to **Monitor > Provisioning logs** to see that your groups were provisioned successfully. In your Docker organization, you can check that the groups were correctly provisioned and the members were added to the appropriate teams.
To verify, select **Monitor**, then **Provisioning logs** to see that your groups were provisioned successfully. In your Docker organization, you can check that the groups were correctly provisioned and the members were added to the appropriate teams.
{{< /tab >}}
{{< /tabs >}}
@ -175,7 +174,7 @@ Once complete, a user who signs in to Docker through SSO is automatically added
## More resources
The following videos demonstrate how to use group mapping with your IdP with SCIM enabled.
The following videos demonstrate how to use group mapping with your IdP with SCIM enabled:
- [Video: Group mapping with Okta](https://youtu.be/c56YECO4YP4?feature=shared&t=3023)
- [Video: Attribute and group mapping with Entra ID (Azure)](https://youtu.be/bGquA8qR9jU?feature=shared&t=2039)

52
content/manuals/security/for-admins/provisioning/just-in-time.md
View File

@ -5,57 +5,65 @@ title: Just-in-Time provisioning
linkTitle: Just-in-Time
---
Just-in-Time (JIT) provisioning runs after every successful single sign-on (SSO) sign-in. JIT verifies that the user that signs in is a member of the organization and teams that they are assigned to in the IdP. When you [create your SSO connection](../single-sign-on/_index.md), JIT provisioning is turned on by default.
Just-in-Time (JIT) provisioning automatically creates and updates user accounts after every successful single sign-on (SSO) authentication. JIT verifies that the user signing in belongs to the organization and the teams assigned to them in your identity provider (IdP). When you [create your SSO connection](../single-sign-on/_index.md), JIT provisioning is turned on by default.
## SSO authentication with JIT provisioning enabled
After every successful SSO sign-in authentication, the JIT provisioner performs the following actions:
When a user signs in with SSO and your SSO configuration has JIT provisioning enabled, the following steps occur automatically:
1. Checks if there's an existing Docker account with the email address of the user that just authenticated.
1. The system checks if a Docker account exists for the user's email address.
a) If no account is found with the same email address, it creates a new Docker account using basic user attributes (email, name, and surname). The JIT provisioner generates a new username for this new account by using the email, name, and random numbers to make sure that all account usernames are unique in the platform.
- If an account exists: The system uses the existing account and updates the user's full name if necessary.
- If no account exists: A new Docker account is created using basic user attributes (email, name, and surname). A unique username is generated based on the user's email, name, and random numbers to ensure all usernames are unique across the platform.
b) If an account exists for this email address, it uses this account and updates the full name of the user’s profile if needed.
2. The system checks for any pending invitations to the SSO organization.
2. Checks for any pending invitations to the SSO organization to auto-accept the invitation. If the invitation is specific to a group, the user is added to the invited group along with group mappings in the following step.
- Invitation found: The invitation is automatically accepted.
- Invitation includes a specific group: The user is added to that group within the SSO organization.
3. Checks if the IdP shared group mappings while authenticating the user.
3. The system verifies if the IdP has shared group mappings during authentication.
a) If the IdP provided group mappings for the user, the user gets added to the organizations and teams indicated by the group mappings.
- Group mappings provided: The user is assigned to the relevant organizations and teams.
- No group mappings provided: The system checks if the user is already part of the organization. If not, the user is added to the default organization and team configured in the SSO connection.
b) If the IdP didn't provide group mappings, it checks if the user is already a member of the organization, or if the SSO connection is for multiple organizations (only at company level) and if the user is a member of any of those organizations. If the user isn't a member, it adds the user to the default team and organization configured in the SSO connection.
The following graphic provides an overview of SSO authentication with JIT enabled:
![JIT provisioning enabled](../../images/jit-enabled-flow.svg)
## SSO authentication with JIT provisioning disabled
When you opt to disable JIT provisioning in your SSO connection, the following actions occur:
When JIT provisioning is disabled in your SSO connection, the following actions occur during authentication:
1. Checks if there's an existing Docker account with the email address of the user that just authenticated.
1. The system checks if a Docker account exists for the user's email address.
a) If no account is found with the same email address, it creates a new Docker account using basic user attributes (email, name, and surname). Authentication with SSO generates a new username for this new account by using the email, name, and random numbers to make sure that all account usernames are unique in the platform.
- If an account exists: The system uses the existing account and updates the user's full name if necessary.
- If no account exists: A new Docker account is created using basic user attributes (email, name, and surname). A unique username is generated based on the user's email, name, and random numbers to ensure all usernames are unique across the platform.
b) If an account exists for this email address, it uses this account and updates the full name of the user’s profile if needed.
2. The system checks for any pending invitations to the SSO organization.
2. Checks if there are any pending invitations to the SSO organization (or, SSO organizations if the SSO connection is managed at the company level) in order to auto-accept the invitation.
- Invitation found: If the user is a member of the organization or has a pending invitation, sign-in is successful, and the invitation is automatically accepted.
- No invitation found: If the user is not a member of the organization and has no pending invitation, the sign-in fails, and an `Access denied` error appears. The user must contact an administrator to be invited to the organization.
a) If the user isn't already a member of the organization, or doesn't have a pending invitation to join, sign in fails and the user encounters an `Access denied` error. This blocks the user from joining the organization. They need to contact an administrator to invite them to join.
With JIT disabled, group mapping is only available if you have [SCIM enabled](/security/for-admins/provisioning/scim/#enable-scim-in-docker). If SCIM is not enabled, users won't be auto-provisioned to groups.
b) If the user is a member of the organization, or has a pending invitation to join, then sign in is successful.
If you disable JIT provisioning when you create or edit your SSO connection, you can still use group mapping as long as you have also [enabled SCIM](/security/for-admins/provisioning/scim/#enable-scim-in-docker). When JIT provisioning is disabled and SCIM isn't enabled, users won't be auto-provisioned to groups. For instructions on disabling JIT provisioning, see [Manage how users are provisioned](/security/for-admins/single-sign-on/manage/#manage-how-users-are-provisioned).
The following graphic provides an overview of SSO authentication with JIT disabled:
![JIT provisioning disabled](../../images/jit-disabled-flow.svg)
## Disable JIT provisioning
> [!WARNING]
>
> Disabling JIT provisioning may disrupt your users' access and workflows. With JIT disabled, users will not be automatically added to your organization. Users must already be a member of the organization or have a pending invitation to successfully sign in through SSO. To auto-provision users with JIT disabled, [use SCIM](./scim.md).
You may want to disable JIT provisioning for reasons such as the following:
- You have multiple organizations, have SCIM enabled, and want SCIM to be the source of truth for provisioning
- You want to control and restrict usage based on your organization's security configuration, and want to use SCIM to provision access
> [!WARNING]
>
> Disabling JIT provisioning could potentially disrupt your users' workflows. Users must already be a member of the organization or have an invitation to the organization when they authenticate with SSO in order to sign in successfully. To auto-provision users with JIT disabled, you can [use SCIM](./scim.md).
Users are provisioned with JIT by default. If you enable SCIM, you can disable JIT:
See [Manage how users are provisioned](../single-sign-on/manage/_index.md#manage-how-users-are-provisioned) to learn how to disable JIT provisioning.
1. Sign in to the [Admin Console](https://app.docker.com/).
2. Select your organization or company in the left-hand navigation drop-down, and then select **SSO and SCIM**.
3. In the SSO connections table, select the **Action** icon and then **Disable JIT provisioning**.
4. Select **Disable** to confirm.

168
content/manuals/security/for-admins/provisioning/scim.md
View File

@ -5,92 +5,96 @@ linkTitle: SCIM
description: Learn how System for Cross-domain Identity Management works and how to set it up.
aliases:
- /security/for-admins/scim/
weight: 30
---
This section is for administrators who want to enable System for Cross-domain Identity Management (SCIM) 2.0 for their business. It is available for Docker Business customers.
System for Cross-domain Identity Management (SCIM) is available for Docker Business customers. This guide provides an overview of SCIM provisioning.
SCIM provides automated user provisioning and de-provisioning for your Docker organization or company through your identity provider (IdP). Once you enable SCIM in Docker and your IdP, any user assigned to the Docker application in the IdP is automatically provisioned in Docker and added to the organization or company.
## How SCIM works
Similarly, if a user gets unassigned from the Docker application in the IdP, this removes the user from the organization or company in Docker. SCIM also synchronizes changes made to a user's attributes in the IdP, for example the user’s first name and last name.
SCIM offers automated user provisioning and de-provisioning for Docker through your identity provider (IdP). Once SCIM is enabled, users assigned to the Docker application in your IdP are automatically provisioned and added to your Docker organization. If a user is unassigned, they are removed from Docker.
The following lists the supported provisioning features:
- Creating new users
- Push user profile updates
- Remove users
- Deactivate users
- Re-activate users
- Group mapping
SCIM also syncs user profile updates, such as name changes, made in your IdP. SCIM can be used with Docker’s default Just-in-Time (JIT) provisioning configuration, or on its own with JIT disabled.
SCIM supports the automation of:
- Creating users
- Updating user profiles
- Removing and deactivating users
- Re-activating users
- Group mapping
## Supported attributes
The following table lists the supported attributes. Note that your attribute mappings must match for SSO to prevent duplicating your members.
> [!IMPORTANT]
>
> Docker uses JIT provisioning by default for SSO configurations. If you enable SCIM, JIT values still overwrite the attribute
values set by SCIM provisioning. To avoid conflicts, your JIT attribute values must match your SCIM attribute values. To avoid conflicts between SCIM and JIT, you can also disable JIT provisioning. See [Just-in-Time](/manuals/security/for-admins/provisioning/just-in-time.md) for more information.
Attributes are pieces of user information, such as name and email, that are synchronized between your IdP and Docker when using SCIM. Proper mapping of these attributes is essential for seamless user provisioning and to prevent duplicate entries when using SSO.
The following table lists the supported attributes for SCIM:
| Attribute | Description |
|:---------------------------------------------------------------|:-------------------------------------------------------------------------------------------|
| userName | User's primary email address. This is the unique identifier of the user. |
| userName | User’s primary email address, used as the unique identifier |
| name.givenName | User’s first name |
| name.familyName | User’s surname |
| active | Indicates if a user is enabled or disabled. Can be set to false to de-provision the user. |
| active | Indicates if a user is enabled or disabled, set to “false” to de-provision a user |
For additional details about supported attributes and SCIM, see [Docker Hub API SCIM reference](/reference/api/hub/latest/#tag/scim).
> [!IMPORTANT]
>
> SSO uses Just-in-Time (JIT) provisioning by default. If you [enable SCIM](scim.md#set-up-scim), JIT values still overwrite the attribute values set by SCIM provisioning whenever users log in. To avoid conflicts, make sure your JIT values match your SCIM values. For more information, see
> [!TIP]
>
> Optional Just-in-Time (JIT) provisioning is available when you use the Admin Console and enable SCIM. With this feature, you can avoid conflicts between SCIM and JIT by disabling JIT provisioning in your SSO connection. See [SSO authentication with JIT provisioning disabled](/security/for-admins/provisioning/just-in-time/#sso-authentication-with-jit-provisioning-disabled).
## Enable SCIM in Docker
You must make sure you have [configured SSO](../single-sign-on/configure/_index.md) before you enable SCIM. Enforcing SSO isn't required.
You must [configure SSO](../single-sign-on/configure/_index.md) before you enable SCIM. Enforcing SSO isn't required to use SCIM.
{{< tabs >}}
{{< tab name="Docker Hub" >}}
{{% admin-scim %}}
{{< /tab >}}
{{< tab name="Admin Console" >}}
{{< include "admin-early-access.md" >}}
{{% admin-scim product="admin" %}}
{{< /tab >}}
{{< tab name="Docker Hub" >}}
{{% admin-scim %}}
{{< /tab >}}
{{< /tabs >}}
## Enable SCIM in your IdP
The user interface for your IdP may differ slightly from the following steps. You can refer to the documentation for your IdP to verify.
The user interface for your IdP may differ slightly from the following steps. You can refer to the documentation for your IdP to verify. For additional details, see the documentation for your IdP:
- [Okta](https://help.okta.com/en-us/Content/Topics/Apps/Apps_App_Integration_Wizard_SCIM.htm)
- [Entra ID (formerly Azure AD)](https://learn.microsoft.com/en-us/azure/active-directory/app-provisioning/user-provisioning)
{{< tabs >}}
{{< tab name="Okta" >}}
### Enable SCIM
1. Go to the Okta admin portal.
2. Go to the app you created when you configured your SSO connection.
3. On the app page, go to the **General** tab and select **Edit App Settings**.
1. Sign in to Okta and select **Admin** to open the admin portal.
2. Open the application you created when you configured your SSO connection.
3. On the application page, select the **General** tab, then **Edit App Settings**.
4. Enable SCIM provisioning, then select **Save**.
5. Now you can access the **Provisioning** tab. Navigate to this tab, then select **Edit SCIM Connection**.
6. To configure SCIM in Okta, set up your connection like the following:
5. Now you can access the **Provisioning** tab in Okta. Navigate to this tab, then select **Edit SCIM Connection**.
6. To configure SCIM in Okta, set up your connection using the following values and settings:
- SCIM Base URL: SCIM connector base URL (copied from Docker Hub)
- Unique identifier field for users: `email`
- Supported provisioning actions: **Push New Users** and **Push Profile Updates**
- Authentication Mode: HTTP Header
- SCIM Bearer Token: HTTP Header Authorization Bearer Token (copied from Docker Hub)
7. Select **Test Connector Configuration**.
8. Review the test results.
9. Select **Save**.
8. Review the test results and select **Save**.
### Enable synchronization
1. Go to **Provisioning > To App > Edit**.
2. Enable **Create Users**, **Update User Attributes**, and **Deactivate Users**.
3. Select **Save**.
4. Remove unnecessary mappings. The necessary mappings are:
1. In Okta, select **Provisioning**.
2. Select **To App**, then **Edit**.
3. Enable **Create Users**, **Update User Attributes**, and **Deactivate Users**.
4. Select **Save**.
5. Remove unnecessary mappings. The necessary mappings are:
- Username
- Given name
- Family name
@ -100,11 +104,11 @@ The user interface for your IdP may differ slightly from the following steps. Yo
{{< tab name="Entra ID SAML 2.0" >}}
1. In the Azure admin portal, go to **Enterprise Applications**, then select the **Docker** application you created when you set up your SSO connection.
2. Go to **Provisioning** and select **Get Started**.
2. Select **Provisioning**, then **Get Started**.
3. Select **Automatic** provisioning mode.
4. Enter the SCIM Base URL and API Token from Docker Hub into the **Admin Credentials** form.
4. Enter the **SCIM Base URL** and **API Token** from Docker into the **Admin Credentials** form.
5. Test the connection, then select **Save**.
6. Go to **Mappings** , then select **Provision Azure Active Directory Groups**.
6. Go to **Mappings**, then select **Provision Azure Active Directory Groups**.
7. Set the **Enabled** value to **No**.
8. Select **Provision Azure Active Directory Users**.
9. Remove all unsupported attributes.
@ -114,68 +118,68 @@ The user interface for your IdP may differ slightly from the following steps. Yo
{{< /tab >}}
{{< /tabs >}}
See the documentation for your IdP for additional details:
- [Okta](https://help.okta.com/en-us/Content/Topics/Apps/Apps_App_Integration_Wizard_SCIM.htm)
- [Entra ID (formerly Azure AD)](https://learn.microsoft.com/en-us/azure/active-directory/app-provisioning/user-provisioning)
## Set up role mapping
You can assign [roles](/security/for-admins/roles-and-permissions/) to members in your organization in the IdP. To set up a role, you can use optional user-level attributes for the person you want to assign a role. In addition to roles, you can set an organization or team to override the default provisioning values set by the SSO connection.
You can assign [roles](/security/for-admins/roles-and-permissions/) to members in your organization in your IdP. To set up a role, you can use optional user-level attributes for the person you want to assign a role. In addition to roles, you can set an organization or team to override the default provisioning values set by the SSO connection.
> [!NOTE]
>
> These mappings are supported for both SCIM and JIT provisioning. With JIT provisioning, role mapping only applies when a user is initially provisioned to the organization.
> Role mappings are supported for both SCIM and JIT provisioning. With JIT provisioning, role mapping only applies when a user is initially provisioned to the organization.
The following table lists the supported optional user-level attributes.
| Attribute | Possible values | Considerations |
| --------- | ------------------ | -------------- |
| `dockerRole` | `member`, `editor`, or `owner`. For a list of permissions for each role, see [Roles and permissions](/security/for-admins/roles-and-permissions/). | If you don't assign a role in the IdP, the value of the `dockerRole` attribute defaults to `member`. When you set the attribute, this overrides the default value. |
| `dockerOrg` | `organizationName`. For example, an organization named "moby" would be `moby`. | Setting this attribute overrides the default organization configured by the SSO connection. Also, this won't add the user to the default team. If this attribute isn't set, the user is provisioned to the default organization and the default team. If set and `dockerTeam` is also set, this provisions the user to the team within that organization. |
| `dockerTeam` | `teamName`. For example, a team named "developers" would be `developers`. | Setting this attribute provisions the user to the default organization and to the specified team, instead of the SSO connection's default team. This also creates the team if it doesn't exist. You can still use group mapping to provision users to teams in multiple organizations. See [Group mapping](/security/for-admins/provisioning/group-mapping/). |
| `dockerRole` | `member`, `editor`, or `owner`, for a list of permissions for each role, see [Roles and permissions](/security/for-admins/roles-and-permissions/) | If you don't assign a role in the IdP, the value of the `dockerRole` attribute defaults to `member`. When you set the attribute, this overrides the default value. |
| `dockerOrg` | `organizationName`, for example, an organization named "moby" would be `moby` | Setting this attribute overrides the default organization configured by the SSO connection. Also, this won't add the user to the default team. If this attribute isn't set, the user is provisioned to the default organization and the default team. If set and `dockerTeam` is also set, this provisions the user to the team within that organization. |
| `dockerTeam` | `teamName`, for example, a team named "developers" would be `developers` | Setting this attribute provisions the user to the default organization and to the specified team, instead of the SSO connection's default team. This also creates the team if it doesn't exist. You can still use group mapping to provision users to teams in multiple organizations. See [Group mapping](/security/for-admins/provisioning/group-mapping/) for more details. |
After you set the role in the IdP, you need to sync to push the changes to Docker.
After you set the role in the IdP, you must initiate a sync in your IdP to push the changes to Docker.
The external namespace to use to set up these attributes is `urn:ietf:params:scim:schemas:extension:docker:2.0:User`.
{{< tabs >}}
{{< tab name="Okta" >}}
### Set up
### Set up role mapping in Okta
1. Setup [SSO](../single-sign-on/configure/_index.md) and SCIM first.
2. In the Okta admin portal, go to **Directory > Profile Editor** and select **User (Default)**.
3. Select **Add Attribute** and configure the values for the role, org, or team you want to add. Exact naming isn't required.
2. In the Okta admin portal, go to **Directory**, select **Profile Editor**, and then **User (Default)**.
3. Select **Add Attribute** and configure the values for the role, organization, or team you want to add. Exact naming isn't required.
4. Return to the **Profile Editor** and select your application.
5. Select **Add Attribute** and enter the required values. The **External Name** and **External Namespace** must be exact. The external name values for org/team/role mapping are `dockerOrg`, `dockerTeam`, and `dockerRole` respectively, as listed in the previous table. The external namespace is the same for all of them: `urn:ietf:params:scim:schemas:extension:docker:2.0:User`.
6. After creating the attributes, go to the top and select **Mappings > Okta User to YOUR APP**.
7. Go to the newly created attributes and map the variable names selected above to the external names, then select **Save Mappings**. If you’re using JIT provisioning, continue to the following step.
8. Go to **Applications > YOUR APP > General > SAML Settings > Edit > Step 2** and configure the mapping from the user attribute to the docker variables.
5. Select **Add Attribute** and enter the required values. The **External Name** and **External Namespace** must be exact. The external name values for organization/team/role mapping are `dockerOrg`, `dockerTeam`, and `dockerRole` respectively, as listed in the previous table. The external namespace is the same for all of them: `urn:ietf:params:scim:schemas:extension:docker:2.0:User`.
6. After creating the attributes, navigate to the top of the page and select **Mappings**, then **Okta User to YOUR APP**.
7. Go to the newly created attributes and map the variable names to the external names, then select **Save Mappings**. If you’re using JIT provisioning, continue to the following steps.
8. Navigate to **Applications** and select **YOUR APP**.
9. Select **General**, then **SAML Settings**, and **Edit**.
10. Select **Step 2** and configure the mapping from the user attribute to the Docker variables.
### Assign roles by user
1. Go to **Directory > People > YOUR USER > Profile**, then select **Edit** on **Attributes**.
2. Update the attributes to the desired values.
1. In the Okta admin portal, select **Directory**, then **People**.
2. Select **Profile**, then **Edit**.
3. Select **Attributes** and update the attributes to the desired values.
### Assign roles by group
1. Go to **Directory > People > YOUR GROUP > Applications > YOUR APPLICATION**, then select the **Edit** icon.
2. Update the attributes to the desired values.
1. In the Okta admin portal, select **Directory**, then **People**.
2. Select **YOUR GROUP**, then **Applications**.
3. Open **YOUR APPLICATION** and select the **Edit** icon.
4. Update the attributes to the desired values.
If a user doesn't already have attributes set up, users who are added to the group will inherit these attributes upon provisioning.
{{< /tab >}}
{{< tab name="Entra ID SAML 2.0" >}}
### Set up
### Set up role mapping in Azure AD
1. Setup [SSO](../single-sign-on/configure/_index.md) and SCIM first.
2. In the Azure AD admin portal, go to**Enterprise Apps > YOUR APP > Provisioning > Mappings > Provision Azure Active Directory Users**.
3. To set up the new mapping, check **Show advanced options**, then select **Edit attribute options**.
4. Create new entries with the desired mapping for role, org, or group (for example, `urn:ietf:params:scim:schemas:extension:docker:2.0:User:dockerRole`) as a string type.
5. Go back to **Attribute Mapping** for users and click **Add new mapping**.
2. In the Azure AD admin portal, open **Enterprise Apps** and select **YOUR APP**.
3. Select **Provisioning**, then **Mappings**, and **Provision Azure Active Directory Users**.
4. To set up the new mapping, check **Show advanced options**, then select **Edit attribute options**.
5. Create new entries with the desired mapping for role, organization, or group (for example, `urn:ietf:params:scim:schemas:extension:docker:2.0:User:dockerRole`) as a string type.
6. Navigate back to **Attribute Mapping** for users and select **Add new mapping**.
### Expression mapping
@ -190,7 +194,7 @@ This implementation works best for roles, but can't be used along with organizat
Switch(SingleAppRoleAssignment([appRoleAssignments]), "member", "My Corp Administrator", "owner", "My Corp Editor", "editor")`
```
3. Set the following fields:
- **Target attribute**: `urn:ietf:params:scim:schemas:extension:docker:2.0:User:dockerRole`.
- **Target attribute**: `urn:ietf:params:scim:schemas:extension:docker:2.0:User:dockerRole`
- **Match objects using this attribute**: No
- **Apply this mapping**: Always
4. Save your configuration.
@ -211,15 +215,15 @@ Direct mapping is an alternative to expression mapping. This implementation work
### Assign users
If you used expression mapping in the previous step, go to **App registrations > YOUR APP > App Roles** and create an app role for each Docker role. If possible, create it with a display name that is directly equivalent to the role in Docker, for example, `owner` instead of `Owner`. If set up this way, then you can use expression mapping to `SingleAppRoleAssignment([appRoleAssignments])`. Otherwise, a custom switch will have to be used. See [Expression mapping](#expression-mapping).
If you used expression mapping in the previous step, navigate to **App registrations**, select **YOUR APP**, and **App Roles**. Create an app role for each Docker role. If possible, create it with a display name that is directly equivalent to the role in Docker, for example, `owner` instead of `Owner`. If set up this way, then you can use expression mapping to `SingleAppRoleAssignment([appRoleAssignments])`. Otherwise, a custom switch will have to be used. See [Expression mapping](#expression-mapping).
To add a user:
1. Go to **YOUR APP > Users and groups**. Select **Add user/group**.
2. Select the user you want to add, then **Select** their desired role.
1. Select **YOUR APP**, then **Users and groups**.
2. Select **Add user/groups**, select the user you want to add, then **Select** their desired role.
To add a group:
1. Go to **YOUR APP > Users and groups**. Select **Add user/group**.
2. Select the group you want to add, then **Select** the desired role for the users in that group.
1. Select **YOUR APP**, then **Users and groups**.
2. Select **Add user/groups**, select the user you want to add, then **Select** their desired role.
If you used direct mapping in the previous step, go to **Microsoft Graph Explorer** and sign in to your tenant. You need to be a tenant admin to use this feature. Use the Microsoft Graph API to assign the extension attribute to the user with the value that corresponds to what the attribute was mapped to. See the [Microsoft Graph API documentation](https://learn.microsoft.com/en-us/graph/extensibility-overview?tabs=http) on adding or updating data in extension attributes.
@ -236,23 +240,23 @@ See the documentation for your IdP for additional details:
If SCIM is disabled, any user provisioned through SCIM will remain in the organization. Future changes for your users will not sync from your IdP. User de-provisioning is only possible when manually removing the user from the organization.
{{< tabs >}}
{{< tab name="Docker Hub" >}}
{{% admin-scim-disable %}}
{{< /tab >}}
{{< tab name="Admin Console" >}}
{{< include "admin-early-access.md" >}}
{{% admin-scim-disable product="admin" %}}
{{< /tab >}}
{{< tab name="Docker Hub" >}}
{{% admin-scim-disable %}}
{{< /tab >}}
{{< /tabs >}}
## More resources
The following videos demonstrate how to configure SCIM for your IdP.
The following videos demonstrate how to configure SCIM for your IdP:
- [Video: Configure SCIM with Okta](https://youtu.be/c56YECO4YP4?feature=shared&t=1314)
- [Video: Attribute mapping with Okta](https://youtu.be/c56YECO4YP4?feature=shared&t=1998)

4
content/manuals/security/for-admins/single-sign-on/manage.md
View File

@ -69,6 +69,10 @@ aliases:
{{< /tab >}}
{{< /tabs >}}
## Manage provisioning
Users are provisioned with Just-in-Time (JIT) provisioning by default. If you enable SCIM, you can disable JIT. For more information, see the [Provisioning overview](/manuals/security/for-admins/provisioning/_index.md) [Just-in-Time](/manuals/security/for-admins/provisioning/just-in-time.md) guides.
## What's next?
- [Set up SCIM](../provisioning/scim.md)

2
layouts/shortcodes/admin-sso-connect.md
View File

@ -26,7 +26,7 @@ After you’ve completed the SSO configuration process in Docker, you can test t
> - [Okta](https://help.okta.com/en-us/Content/Topics/Security/policies/configure-app-signon-policies.htm)
> - [Entra ID (formerly Azure AD)](https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-restrict-your-app-to-a-set-of-users)
>
> Alternatively, see [Manage how users are provisioned](/security/for-admins/single-sign-on/manage/#manage-how-users-are-provisioned).
> Alternatively, see [Manage how users are provisioned](/security/for-admins/single-sign-on/manage/).
The SSO connection is now created. You can continue to set up SCIM without enforcing SSO log-in. For more information about setting up SCIM, see [Set up SCIM](/security/for-admins/provisioning/scim/).

13
layouts/shortcodes/admin-sso-management-users.md
View File

@ -15,12 +15,6 @@
- Organization: Select your organization in the left navigation drop-down menu, and then select **Members**.
- Company: Select your company in the left navigation drop-down menu, and then select **Users**.` }}
{{ $remove_button = "**Remove member**, if you're an organization, or **Remove user**, if you're a company" }}
{{ $provisioning_steps = `Users are provisioned with JIT provisioning by default. If you enable SCIM, you can disable JIT:
1. Sign in to the [Admin Console](https://admin.docker.com).
2. Select your organization or company in the left navigation drop-down menu, and then select **SSO and SCIM**.
3. In the SSO connections table, select the **Action** icon and then **Disable JIT provisioning**.
4. Select **Disable** to confirm.` }}
{{ end }}
> [!IMPORTANT]
>
@ -31,7 +25,7 @@
> - [Okta](https://help.okta.com/en-us/Content/Topics/Security/policies/configure-app-signon-policies.htm)
> - [Entra ID (formerly Azure AD)](https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-restrict-your-app-to-a-set-of-users)
>
> Alternatively, see [Manage how users are provisioned](#manage-how-users-are-provisioned).
> Alternatively, see [Manage how users are provisioned](/manuals/security/for-admins/single-sign-on/manage.md).
### Add guest users when SSO is enabled
@ -51,7 +45,4 @@ To remove a user:
2. {{ $member_navigation }}
3. Select the action icon next to a user’s name, and then select {{ $remove_button }}.
4. Follow the on-screen instructions to remove the user.
### Manage how users are provisioned
{{ $provisioning_steps }}
{{ end }}