Why Directory Synchronization Complements Federation

Federation solves the login problem. It lets a SaaS application redirect a user to the customer’s identity provider, receive the result through ProAuth, and keep the application itself dependent on one stable issuer instead of every customer directory.

That is necessary, but it is not the whole user lifecycle.

Many enterprise workflows need to know about people before they sign in for the first time. A project owner may need to assign a record to a colleague. An approval flow may need to route work to a manager. An administrator may need to grant a role to a group before rollout day. If the application only creates users after their first federated login, those workflows have a blind spot.

Directory synchronization fills that gap. Federation establishes the user at login time. SCIM provisioning tells ProAuth which users and groups exist before login time.

Federation Is Runtime Trust

In a federated setup, ProAuth sits between the SaaS application and the customer’s identity provider. The application trusts ProAuth. ProAuth handles the tenant-specific identity provider configuration, redirects the user to the right login system, validates the returned tokens, and issues the token the application consumes.

That architecture keeps customer-specific identity details out of application code. It also lets ProAuth normalize user information and maintain application-related profile data or group memberships centrally.

The important boundary is time: federation happens when the user authenticates. ProAuth can create or update its user record at that point, but without a prior provisioning step, ProAuth does not know about users who have not signed in yet. The existing directory synchronization post calls out this exact limitation: if a customer directory has 1,000 users and 50 have authenticated, a login-only model only gives ProAuth those 50 users.

That may be enough for a simple application. It is rarely enough for enterprise SaaS.

Provisioning Is Lifecycle State

Provisioning moves directory state before the login event. With SCIM, the System for Cross-domain Identity Management, an external directory can exchange standardized user and group data with a service provider. The companion SCIM protocol specification defines the HTTP-based operations used to create, read, update, and delete those resources.

In ProAuth, SCIM synchronization is scoped to an OIDC IdP instance. Each OIDC IdP instance can expose its own SCIM endpoint, with its own endpoint URL and security token. The default endpoint shape documented for ProAuth is:

https://<ProAuth-URI>/idpscheme/<IdpInstanceId>/scim

That IdP-instance boundary matters in multi-tenant SaaS. It keeps provisioning aligned with the customer’s federation configuration instead of treating all external directories as one shared feed.

ProAuth’s SCIM support is for users and groups. It does not synchronize credentials. Passwords, MFA policy, account recovery, and the primary lifecycle decisions stay with the customer’s directory and identity platform. ProAuth receives the directory data needed by the SaaS application: who exists, which groups exist, and how memberships should be represented.

flowchart TD
  App["SaaS application trusts ProAuth"]

  subgraph Login["Federation at login"]
    F1["User signs in"]
    F2["ProAuth resolves tenant IdP"]
    F3["Customer IdP authenticates"]
    F4["ProAuth issues application token"]
  end

  subgraph Sync["SCIM before login"]
    S1["Customer directory job"]
    S2["Users and groups"]
    S3["IdP-instance SCIM endpoint"]
    S4["Users and memberships exist upfront"]
  end

  F1 --> F2 --> F3 --> F4
  App --> F4
  S1 --> S2 --> S3 --> S4
  S4 -. match by unique identifier .-> F4

Why the Two Models Belong Together

Federation and provisioning are sometimes discussed as alternatives. In practice, they answer different questions.

Federation asks: can this person authenticate with the customer’s identity provider right now?

Provisioning asks: should this person, group, or membership already be known to the application before authentication happens?

The difference becomes visible during rollout. A customer administrator may want to assign application permissions to a group before inviting users. A business team may want all eligible colleagues available in owner pickers, approval rules, or comment mentions on day one. A support team may need to see whether a user exists but has not yet logged in.

Those are not authentication problems. They are lifecycle and application-state problems. SCIM gives the application a current view of users and groups without asking the application to connect directly to every customer directory.

The critical operational detail is the unique identifier. Provisioning creates the user record first. Later, federation has to recognize that the authenticating user is the same person.

For Azure AD provisioning, the ProAuth SCIM documentation configures the IdP instance with ScimUniqueIdentifierValues and UniqueIdentifierClaimTypes so the synchronized user can be matched during a federated login. The documented Azure AD pattern combines the Azure AD tenant ID with the SCIM externalId, and uses the tid and oid claims from the later login flow.

That small piece of configuration is worth treating as part of the onboarding design, not as a last checkbox. If the identifier is unstable or mapped differently between provisioning and login, the application will see separate identities where the customer expects one person.

A Practical First-Rollout Checklist

For a first enterprise customer rollout, keep the checklist concrete:

Create or identify the OIDC IdP instance that represents the customer’s federation setup.
Enable SCIM for that IdP instance by setting ScimEnabled.
Generate the SCIM security token and record the IdP instance ID.
Configure the customer’s Azure AD enterprise application provisioning with the ProAuth tenant URL and secret token.
Review the externalId mapping. The ProAuth documentation uses Azure AD objectId for this mapping.
Decide whether the customer should synchronize all users and groups or only assigned users and groups.
Configure the unique identifier options so SCIM-provisioned users and later federated logins resolve to the same ProAuth user.
Start provisioning and review the first synchronization logs before the customer invites users into the SaaS application.

That list is intentionally operational. The hard part is rarely “does the protocol exist?” The hard part is agreeing which users and groups belong in the application, which attributes are stable enough to identify them, and how the first customer rollout should be verified before people depend on it.

Keep the Boundary Clean

Directory synchronization should not turn the SaaS application into a shadow identity provider. It should give the application the directory state it needs while leaving authentication and primary account lifecycle with the customer.

That is why SCIM and federation fit together well in ProAuth. Federation keeps runtime authentication anchored in the customer’s identity provider. SCIM gives ProAuth the user and group data the application needs before first login. The SaaS application still trusts ProAuth, and ProAuth stays responsible for the tenant-specific identity integration.

For setup details, see the ProAuth SCIM configuration documentation.