انتقل إلى المحتوى الرئيسي
DocumentMS
اطلب عرضًا توضيحيًاابدأ تجربة مجانية
العربية

Integration

Okta single sign-on document management

Okta acts as the identity provider for DocumentMS over OIDC. Group claims in the token drive role assignment on each sign-in, so a user deactivated in Okta cannot authenticate, and role changes made in Okta take effect at their next session.

اطلب عرضًا توضيحيًااطّلع على الأسعار

What this connection does

Okta acts as the identity provider for DocumentMS over OIDC. Group claims in the token drive role assignment on each sign-in, so a user deactivated in Okta cannot authenticate and a role change in Okta takes effect at their next session.

For organisations that have consolidated identity governance in Okta, this means DocumentMS access is reviewed and revoked in the same place as everything else — rather than being a separate console that access reviews forget.

What you need on your side

Have these ready before you start; the configuration itself takes minutes.
  • An Okta tenant and an administrator able to create an OIDC application
  • Okta groups corresponding to the DocumentMS roles you intend to use
  • A group claim configured on the authorisation server

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: Create the OIDC application

    Create a web application in Okta with the DocumentMS redirect URI, and note the client credentials.

  2. Step 2: Add a groups claim

    Configure the authorisation server to include group membership in the ID token.

  3. Step 3: Map groups to roles

    Map each Okta group to a DocumentMS role, starting with the most restrictive.

  4. Step 4: Verify and revoke

    Sign in as a test user, confirm the role, then deactivate in Okta 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 apply at next sign-in; deactivate the user in Okta for immediate revocation rather than changing group membership
  • Group claim size limits apply on some Okta configurations — use a filtered claim expression rather than returning every group
  • SCIM 2.0 provisioning is supported alongside SSO, so Okta remains the source of truth for account lifecycle as well as for authentication — a deactivation in Okta removes access here without a second action

آخر مراجعة: 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.
اطلب عرضًا توضيحيًاابدأ تجربة مجانية