Ir al contenido principal
DocumentMS
Solicitar una demoPrueba gratuita
Español

Integration

Microsoft Entra ID single sign-on for DocumentMS

DocumentMS authenticates against Microsoft Entra ID over OIDC. Directory groups map to DocumentMS roles, which means a leaver removed from a group loses document access without anyone touching DocumentMS, and access reviews happen where the rest of your identity governance already lives.

Solicitar una demoVer precios

What this connection does

DocumentMS authenticates against Microsoft Entra ID over OIDC, with directory groups mapped to DocumentMS roles. Users sign in with the account they already have, and role assignment is evaluated on each sign-in from the group claims in the token.

The convenience is secondary. The control is that a leaver disabled in the directory cannot authenticate to DocumentMS — which removes the gap between an HR offboarding process and a document system nobody remembered to update. Access reviews then happen where the rest of your identity governance already happens.

What you need on your side

Have these ready before you start; the configuration itself takes minutes.
  • A Microsoft Entra ID tenant and an administrator able to create an application registration
  • Security groups that correspond to the DocumentMS roles you want — create them before mapping, rather than mapping to groups that exist for another purpose
  • Group claims enabled in the token configuration

Setting it up

Test with one user and one document before rolling out. Connection events and permission changes appear in the audit trail.

  1. Step 1: Register the application

    Create an app registration with the DocumentMS redirect URI and note the client and tenant identifiers.

  2. Step 2: Configure claims

    Enable group claims so role assignment can be driven from directory membership.

  3. Step 3: Map groups to roles

    Map each security group to a DocumentMS role. Start restrictive and widen; the reverse is harder to unwind.

  4. Step 4: Verify with one user

    Sign in as a test user, confirm the expected role, then disable the account and confirm access is refused.

Limits worth knowing before you rely on it

Stated up front rather than discovered later. Every integration has boundaries, and a directory that hides them just moves the discovery to a support ticket.
  • Role changes take effect at the next sign-in rather than immediately, because roles are evaluated from the token — for immediate revocation, disable the account rather than changing groups
  • Users in a very large number of groups may have group claims omitted from the token by Entra ID; use application roles or group filtering if you hit that limit
  • SCIM 2.0 provisioning is supported alongside OIDC, so joiners, movers and leavers flow from Entra ID without a manual step — authentication and account lifecycle are handled separately, and large tenants need both

Última revisión: 2026-09-01

Want to see this working?

We can set the connection up against a sandbox tenant on a demo call so you can see the behaviour rather than read about it.
Solicitar una demoPrueba gratuita