SAML JIT Provisioning, Auto-Approval, and Deprovisioning Limitations

This document explains how Synaccess CMP handles SAML just-in-time (JIT) provisioning, approval, password access, and user deprovisioning.

Summary

Synaccess CMP supports SAML 2.0 sign-in and optional JIT user creation. JIT provisioning creates a Synaccess CMP user record after a successful SAML authentication when no matching user already exists.

JIT provisioning is not full directory synchronization. It does not currently sync identity provider groups, roles, device assignments, profile attributes, disabled status, or user removals from the identity provider into Synaccess CMP.

Key Terms

How SAML Login Works

1. The user starts a SAML login from Synaccess CMP.
2. Synaccess CMP redirects the browser to the identity provider.
3. The identity provider authenticates the user and posts a SAML response to the Synaccess ACS URL.
4. Synaccess CMP validates the SAML response using the configured identity provider issuer, login URL, and signing certificate.
5. Synaccess CMP reads the SAML Name ID and treats it as the user's email address.
6. If a Synaccess CMP user already exists with that email address, Synaccess signs in that user.
7. If no matching user exists and JIT provisioning is enabled, Synaccess creates a new enterprise user.
8. If no matching user exists and JIT provisioning is disabled, the login is rejected.

The SAML Name ID must match the user's Synaccess CMP email address. For Entra ID this usually means mapping Name ID to user.mail or user.userprincipalname, depending on which value matches the Synaccess user email.

What JIT Creates

When JIT provisioning creates a new user, Synaccess CMP currently creates a regular non-admin enterprise user with:

JIT does not update an existing Synaccess user with new values from the identity provider. If the user's name, email, group membership, or employment status changes in the identity provider, update the Synaccess user or access policy separately as needed.

Auto-Approval Behavior

Auto-approve JIT users controls whether SAML-created users are immediately approved in Synaccess CMP.

Auto-approval does not bypass identity provider assignment or policy. The user must still be allowed to authenticate to the SAML application in the identity provider.

Auto-approval also does not assign Synaccess admin privileges, roles, groups, or device-specific access. Configure those in Synaccess CMP after the user exists if the user needs a restricted or elevated access profile.

Email Verification

JIT-created users start with email_verified set to false.

If the enterprise requires email verification, a JIT-created user may still need email verification before reaching the main application, even after successful SAML authentication and approval.

If the enterprise does not require email verification, Synaccess CMP treats the email-verification gate as satisfied for app access.

Password Access and SSO-Only Access

SAML and password access are separate controls.

• A JIT-created user does not have a password set.
• If Require SSO for sign-in is enabled for the team, password sign-in and password setup/reset flows are blocked for the team.
• If Require SSO for sign-in is not enabled, a user could use password sign-in only if a Synaccess password is later set and password sign-in is not disabled for that user.
• Password sign-in can also be disabled per user.

For SSO-only environments, enable Require SSO for sign-in after SAML is tested, and keep at least one break-glass administrator path available.

Access Assignment

SAML JIT provisioning does not map IdP groups into Synaccess roles, Synaccess groups, or device access lists.

In the current Synaccess access model, an empty device access list represents access to all PDUs unless the user is constrained by other role or assignment rules. This is important for JIT users because SAML does not add explicit device access entries. If least-privilege access is required, keep auto-approval off until an administrator assigns the correct role and device access.

After the user is created, a Synaccess administrator should review:

1. Whether the user is approved.
2. Whether the user should be active in the team.
3. Whether the user should have admin privileges.
4. Which Synaccess role should apply.
5. Which PDUs or Synaccess groups the user should be able to access.
6. Whether password sign-in should be disabled for that user.

Do not rely on identity provider group membership to restrict device access unless the same restriction is also configured in Synaccess CMP.

Deprovisioning Limitations

Synaccess CMP does not currently support automatic SAML or SCIM deprovisioning.

Removing a user from the identity provider application, disabling the identity provider account, or deleting the identity provider account can prevent future SAML authentication through that provider, but it does not automatically:

• Delete the Synaccess CMP user.
• Mark the Synaccess CMP user inactive.
• Remove Synaccess roles or device assignments.
• Disable Synaccess password sign-in.
• Revoke existing Synaccess browser sessions before they expire.
• Disable or delete Synaccess personal access tokens.

SAML is checked at login time. Synaccess CMP API requests and active browser sessions use Synaccess-issued tokens after login, not a live identity provider lookup on every request.

Recommended Deprovisioning Procedure

When a user should lose access, update both the identity provider and Synaccess CMP.

1. Remove the user from the SAML enterprise application in the identity provider.
2. In Synaccess CMP, go to Team > Members.
3. Open the user.
4. Disable password sign-in if the user should not be able to use Synaccess credentials.
5. Mark the user unapproved or inactive in the team, or delete the user if the account is no longer needed.
6. Remove admin privileges, roles, groups, and device access as appropriate.
7. Review and disable or delete any personal access tokens for that user.
8. Confirm the user can no longer sign in through SAML or password login.

For high-risk offboarding, delete the Synaccess user or remove all access in Synaccess CMP rather than relying only on IdP app assignment removal.

Operational Recommendations

• Test SAML with one pilot user before enabling JIT or Require SSO for sign-in broadly.
• Use JIT with auto-approval off when administrators need to review new users before they can access devices.
• Use JIT with auto-approval on only when IdP assignment is tightly controlled and the default Synaccess access model, including empty device access list behavior, is acceptable.
• Keep Require SSO for sign-in enabled for SSO-only organizations.
• Periodically compare IdP app assignments with Synaccess Team Members to find stale accounts.
• Rotate the SAML signing certificate before expiration and update Synaccess CMP with the new certificate.
• Maintain a documented break-glass administrator process.

Current Non-Goals and Limitations

The current SAML/JIT flow does not provide:

• SCIM user provisioning or deprovisioning.
• IdP group-to-Synaccess role mapping.
• IdP group-to-device assignment mapping.
• Automatic user profile synchronization.
• Automatic removal of users who are removed from the IdP application.
• Automatic session revocation when an IdP account is disabled.
• SAML Single Logout.

These limitations should be considered when designing customer onboarding and offboarding procedures.