Skip to main content

SCIM provisioning and SAML single sign-on

Confirm feature availability and compatibility before connecting your identity provider or deploying SSO. The API reference describes the available contracts; it does not imply compatibility with every provider configuration.

These are optional integrations for an organization's identity administrator and application developer. They are not required for the first hosted-login test.

  • SCIM keeps users and groups synchronized through provisioning requests from another identity system.
  • SAML SSO lets users sign in to a connected application through an identity provider. In the flow documented here, SyAuth is the identity provider, and the other application is the service provider.

Both require configuration on two sides. Saving a token or provider entry in SyAuth is only one side of the setup.

SCIM provisioning​

Open SCIM, select a workspace and create a token. Copy it once. Configure your identity provider with base URL https://api.syauth.com/e/v1/scim/v2 and Bearer token authentication. Use the exact Users/Groups paths without trailing slashes.

Test a single user and group before enabling wider provisioning. User creation maps username/email and names, sets active by default, and marks provisioned email verified. Group members must belong to the token's workspace. User deletion deactivates the user and removes group memberships; group deletion removes the group.

Supported PATCH fields include userName, name.givenName, name.familyName and active for users, and displayName/members for groups. Arbitrary attribute paths and custom schemas are not supported. Password provisioning, bulk operations, sorting and ETags are not available. An externalId returned from the service is not a separately persisted identity-provider identifier.

Send application/json for write requests. Check that your provider can handle the current response-location and authentication limitations described in SCIM API.

To check setup, ask the identity administrator to provision one test user, read it back and update it, then check the result in the intended SyAuth workspace. If the first request fails, keep its exact endpoint, status and body and check the token's workspace and feature-availability note before enabling wider synchronization.

SAML SSO​

SyAuth acts as the identity provider. In SAML settings, register your service provider with its name, Entity ID and Assertion Consumer Service (ACS) URL. Configure NameID, attributes and assertion signing to match the SP.

Get the Entity ID (the application's SAML identifier) and ACS URL (where it receives the login result) from that application's SAML administrator or configuration screen. These are not your OAuth client ID and OAuth callback URL. Copy the values exactly rather than inventing them.

Import metadata from https://api.syauth.com/e/v1/saml/metadata/ into the SP. Use the entity ID, signing certificate and SSO endpoint from that metadata. If metadata is unavailable, resolve feature availability with support before continuing.

The SP sends SAMLRequest; SyAuth signs in the application user and posts SAMLResponse to the registered ACS. Test the full browser round trip, attribute mapping and rejection of invalid responses. A SAML Single Logout endpoint is not provided. See SAML operations.

Start the test with the connected application's SAML sign-in action. The expected journey is that application → SyAuth sign-in → the application's ACS → an authenticated application session. Opening the metadata URL alone only reads configuration. If the return fails, check the ACS/Entity ID and assertion-validation error with the application's administrator.