Restrict auto user creation for SSO

||Connect docs via MCP

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

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.

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 or Azure AD for SAML, or add 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 for common issues.

Next steps

• Configure SCIM provisioning: Automate provisioning and deprovisioning from your identity provider.
• Set default role for SSO users: Choose the role assigned users land with.