## Restrict auto user creation for SSO

URL: https://docs.atlan.com/product/integrations/identity-management/sso/how-tos/limit-sso-automatically-creating-users-when-they-log-in

> Prevent Atlan from auto-provisioning an account for every user who can authenticate against your identity provider. Restrict access to only the users and groups your IdP explicitly assigns to the Atlan application.

By default, any user who can authenticate against your identity provider and reach Atlan's login page is automatically given an Atlan account on their first sign-in. For most production workspaces, that's too open: you typically want only the users IT has explicitly approved to get accounts.

Restricting auto-provisioning moves that control into your IdP. Once restricted, only users assigned to the Atlan application in the IdP can sign in. Anyone else is rejected at the IdP before Atlan even sees the request: no account is created.

## Prerequisites

- You are an **admin** in Atlan and an administrator of your identity provider.
- SSO is already configured. If not, see [Set up authentication](https://docs.atlan.com/llms/governance/access-control/authentication-and-authorization/llms.txt) first.
- You have a list of users or groups who should have Atlan access. After restricting, only those users can sign in.

## Restrict access in your identity provider

The control lives entirely in your IdP, not in Atlan. Select your provider below.

### Okta

In Okta, only users explicitly assigned to an app can sign in to it. To restrict Atlan access:

1. Log in to the Okta admin console.

2. Go to **Applications → Applications** and open your Atlan SAML app.

3. Open the **Assignments** tab.

4. Click **Assign**, then choose **Assign to People** to add individual users or **Assign to Groups** to add groups.

5. Select each user or group, confirm, and click **Save and Go Back**. Click **Done** when finished.

Only assigned users can now sign in to Atlan via Okta. To give a new user access later, add them to the assignment here: they are provisioned automatically on their first sign-in.

To remove access, open the Assignments tab, find the user or group, and click **Remove**.

### Azure AD / Entra

Entra has a dedicated **Assignment required** property. When it's on, users who are not assigned to the app cannot sign in: they receive an error at the Entra login page.

1. Log in to the [Microsoft Entra admin center](https://entra.microsoft.com).

2. Go to **Identity → Enterprise apps → All applications** and open your Atlan application.

3. In the left menu under **Manage**, click **Properties**.

4. Set **Assignment required** to **Yes**, then click **Save**.

5. In the left menu, click **Users and groups**, then click **Add user/group** and assign the users or groups who should have access.

With **Assignment required** on, any Entra user not in the assigned list is blocked at sign-in. No Atlan account is created for them. To give a new user access, add them under **Users and groups**.

To revert: turn **Assignment required** back to **No** in Properties. All authenticated Entra users can sign in again.

### Google Workspace

In Google Admin Center, SAML app access is controlled by organizational unit (org unit). Users in org units where the app is set to OFF cannot sign in to Atlan and no account is created for them.

1. Log in to [Google Admin Center](https://admin.google.com).

2. Go to **Apps → Web and mobile apps** and open your Atlan SAML app.

3. Expand **User access**.

4. Under _Service status_, switch from **ON for everyone** to the specific org unit or units that should have access. Set all other org units to **OFF**.

5. Click **Save**.

Users in org units where the app is OFF are rejected by Google before a SAML assertion ever reaches Atlan. To grant access to a new user, move them into an org unit where the app is ON, or toggle their org unit to ON.

:::note
Google controls access at the org unit level, not per individual user. If you need user-level assignment control, consider [Okta](?sso-provider=okta) or [Azure AD](?sso-provider=azure-ad) for SAML, or add [SCIM provisioning](https://docs.atlan.com/product/integrations/identity-management/scim/how-tos/configure-scim-provisioning) for tighter lifecycle management.
:::

### Other IdPs (SAML 2.0)

For JumpCloud, OneLogin, PingFederate, and any other SAML 2.0 provider, the principle is the same: restrict which users the IdP will send a SAML assertion for.

The exact steps depend on your IdP, but in all cases:

1. Open your IdP's admin console and find the Atlan SAML application.

2. Edit the application's **user or group assignments** so only approved users are listed.

3. Save the assignment changes.

Users not in the assignment list will be rejected by the IdP at sign-in: Atlan never receives a SAML assertion for them, so no account is created. Refer to your IdP's documentation for the specific assignment UI.

## Need help?

If a user can sign in when they shouldn't, verify the assignment in your IdP: the restriction lives there, not in Atlan. If a user can't sign in but should be able to, confirm they are in the assigned list and that SSO is reaching your IdP. See [Troubleshooting SSO](https://docs.atlan.com/llms/governance/access-control/troubleshooting-sso/llms.txt) for common issues.

## Next steps

- [Configure SCIM provisioning](https://docs.atlan.com/product/integrations/identity-management/scim/how-tos/configure-scim-provisioning): Automate provisioning and deprovisioning from your identity provider.
- [Set default role for SSO users](https://docs.atlan.com/llms/governance/access-control/set-default-user-roles-for-sso/llms.txt): Choose the role assigned users land with.

---