Skip to content

Commit

Permalink
Merge pull request #21239 from sarahsanders-docker/ENGDOCS-2269
Browse files Browse the repository at this point in the history
Update JIT, SCIM, and group mapping guides
  • Loading branch information
sarahsanders-docker authored Oct 28, 2024
2 parents 60bf7c8 + 8a29833 commit a691e88
Show file tree
Hide file tree
Showing 6 changed files with 148 additions and 142 deletions.
49 changes: 24 additions & 25 deletions content/manuals/security/for-admins/provisioning/group-mapping.md
Original file line number Diff line number Diff line change
Expand Up @@ -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:

Expand Down Expand Up @@ -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.

Expand All @@ -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.
Expand All @@ -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
Expand All @@ -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`.
Expand All @@ -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 >}}
Expand All @@ -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)
54 changes: 31 additions & 23 deletions content/manuals/security/for-admins/provisioning/just-in-time.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.

The following graphic provides an overview of SSO authentication with JIT enabled:

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.

![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:

1. Checks if there's an existing Docker account with the email address of the user that just authenticated.
When JIT provisioning is disabled in your SSO connection, the following actions occur during authentication:

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.
1. The system checks if a Docker account exists for the user's email address.

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.
- 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.

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.
2. The system checks for any pending invitations to the SSO 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.
- 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.

b) If the user is a member of the organization, or has a pending invitation to join, then sign in is successful.
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.

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.
Loading

0 comments on commit a691e88

Please sign in to comment.