Directory Sync

SCIM 2.0 (System for Cross-domain Identity Management) lets your IdP automatically create, update, and remove users and groups in LoginRadius based on what happens in your directory. When you assign someone to a SCIM-enabled app in your IdP, they are provisioned in your organization. When you remove or deactivate them, they are deprovisioned. No manual account management needed.

Configuration Guide

To enable Directory Sync for an organization, follow the steps below.

Access Directory Sync

1. Log in to the Admin Console.
2. Navigate to the Organizations tab in the left sidebar.
3. Click on an organization from the list to open its Organization Details.
4. Go to the Features tab and click Directory Sync.

Create a Directory

1. Click the Create Directory button.
2. Fill in the form:
   • Directory Name — A unique name to identify this directory.
   • Directory Type — Select your IdP (e.g., Okta, Azure AD, Google Workspace).
3. Click Create.

Save Your Credentials

Once the directory is created, your SCIM Endpoint and Security Token are displayed.

• SCIM Endpoint — https://{your-domain}/scim/v2/{directoryId}
• Security Token — Use this as the Bearer token in all SCIM requests from your IdP.

Base URL and Authentication

Each organization has its own dedicated SCIM endpoint:

https://{your-domain}/scim/v2/{directoryId}

Your directoryId is assigned when you create a directory in the admin panel. Every request to this endpoint must include a Bearer token in the Authorization header:

Authorization: Bearer <token>

Tokens are managed under Organization Details → Features → Directory Sync in the admin panel.

IdP Configuration Tips

How Provisioning Works

User Provisioning

Creating a User

When you assign a user to the SCIM-enabled app in your IdP:

1. Your IdP sends a POST /Users request with the user's attributes.
2. LoginRadius checks whether an account with that email already exists:
   • Account exists — the user is linked to your organization with a new SCIM identity. Their existing account is reused.
   • No account found — a new account is created.
3. The user is automatically assigned your organization's default member role and can log in immediately.

Updating a User

When a user's attributes are changed in your IdP (e.g., name, email), the IdP sends a PATCH /Users/{id} or PUT /Users/{id} request. LoginRadius updates the user's profile to reflect those changes.

Group Provisioning

SCIM groups are mapped to roles in LoginRadius. When you assign a group to the SCIM app:

1. Your IdP sends a POST /Groups request with the group's displayName and its members.
2. LoginRadius creates a new role in your organization matching the group name.
3. All listed members are added to that role.

When members are added or removed from the group in your IdP, the IdP sends a PATCH /Groups/{id} request and LoginRadius updates role membership accordingly.

Deprovisioning

Deprovisioning can happen in two ways depending on the action taken in your IdP.

Delete User — DELETE /Users/{id}

The user is fully removed from your organization. If they belong to no other organizations in LoginRadius, their account is permanently deleted. If they belong to other organizations, only access to your organization is removed and their account stays active.

Deactivate User — PATCH /Users/{id} with active: false

The user's account is deactivated. They can no longer log in to your organization, but their account data is retained.

FAQs

A user was provisioned in our IdP but they don't appear in LoginRadius. What should I check?

Confirm the SCIM token is valid and has not been deleted — test the connection from your IdP's provisioning settings. Check that the user has a valid email address in the IdP and that userName is mapped to their email. If provisioning fails with a 409 Conflict, a user with that email already exists and cannot be created again.

We have a group with over 200 members. Will group provisioning work?

The group itself will be created successfully. However, if your IdP sends all members in a single PATCH request exceeding 200 members, the request will fail. Most IdPs (Okta, Azure AD) automatically batch large group membership changes into multiple requests, so this is rarely an issue in practice. If you encounter errors, check your IdP's logs for failed PATCH operations.

We need to sync more than 100 users. How do we ensure all users are provisioned?

LoginRadius returns a maximum of 100 results per page. Your IdP must use pagination: start with startIndex=1&count=100, then startIndex=101&count=100, and so on until the returned totalResults is reached. All major IdPs (Okta, Azure AD, Google Workspace) handle SCIM pagination automatically — no additional configuration is needed on the IdP side.