SSO & SCIM

ERP Preflight supports single sign-on with OpenID Connect (authorization code flow with PKCE). Each organization configures one identity provider. SAML 2.0 is not available.

Organization owners and security admins configure SSO and SCIM under Integrations → SSO & SCIM. These settings require an interactive sign-in — API keys cannot change them — and every change is recorded in the audit log.

1. Register ERP Preflight as an OIDC client at your identity provider, using the redirect URI shown in the form (it ends in /api/v1/sso/callback).
2. Enter the Issuer URL, the Client ID and, for a confidential client, the Client secret. On saving, ERP Preflight fetches <issuer>/.well-known/openid-configuration and validates it; the issuer must be reachable from ERP Preflight.
3. Keep the default Scopes openid email profile or adjust them; openid is required.
4. Choose the Role for just-in-time provisioned users: VIEWER (default), AUDITOR, MIGRATION_CONSULTANT or LEAD_ARCHITECT. Owner and security-admin roles are never granted automatically.

The client secret is stored encrypted and never displayed again; leave the field empty to keep the stored secret. With a secret, ERP Preflight authenticates at the token endpoint with HTTP Basic; without one, the flow relies on PKCE alone.

SSO sign-ins are only accepted for e-mail addresses of domains your organization has proven to own:

1. Add the domain (for example example.com) under Verified domains.
2. Create the DNS TXT record shown there: name _erppreflight-challenge.<domain>, value erppreflight-domain-verification=<token>.
3. Choose Verify DNS. When the record is found, the domain is marked VERIFIED.

A verified domain belongs to exactly one organization.

Members open the SSO sign-in page (/sso), enter their work e-mail address and are forwarded to the identity provider of the organization that verified the domain. After the sign-in, ERP Preflight validates the ID token — signature (JWKS), issuer, audience, expiry and nonce — and requires the identity provider to assert a verified e-mail address (email_verified) on one of the organization's verified domains.

• Just-in-time provisioning (on by default): on the first SSO sign-in, a missing account is created and added to the organization with the role chosen above. Accounts created this way have no password.
• Without just-in-time provisioning, only existing members of the organization can sign in with SSO — for example users provisioned through SCIM.
• An SSO sign-in creates the same server-side session as a password sign-in; signing out and ending sessions under Settings → Security work the same way.
• Enforcing SSO: with enforceSso set, members whose e-mail address belongs to a verified domain can no longer sign in with a password or an e-mail link; the sign-in page then offers Continue with single sign-on. The switch is set through the administration API (PUT /api/v1/sso/admin/config); the form in the web app does not show it, and saving the form — or a PUT without enforceSso — keeps the current setting.

With SCIM 2.0 your identity provider creates, updates and deactivates organization members and groups.

1. Under Integrations → SSO & SCIM choose Create SCIM token. The bearer token starts with erppf_scim_ and is shown once; ERP Preflight stores only its SHA-256 hash. Tokens are listed with prefix and last use and can be revoked.
2. Configure your identity provider with the SCIM 2.0 base URL https://<your API host>/api/v1/scim/v2 and the header Authorization: Bearer erppf_scim_….

Provisioning acts on the organization membership. Creating or activating a user adds the membership; active: false or DELETE removes it and access ends immediately. User accounts are global and are never deleted through SCIM. New members receive the role configured for just-in-time provisioning (VIEWER when no identity provider is configured). SCIM never grants the owner role, and the last organization owner cannot be deprovisioned.

A provisioned group can be mapped to one of the roles VIEWER, AUDITOR, MIGRATION_CONSULTANT, LEAD_ARCHITECT or SECURITY_ADMIN with PATCH /api/v1/sso/admin/scim-groups/{id} and a body such as {"role": "AUDITOR"} (null removes the mapping). Members of a mapped group get that role; owners keep theirs. The web app does not offer this mapping yet.

GET    /api/v1/scim/v2/ServiceProviderConfig
GET    /api/v1/scim/v2/ResourceTypes
GET    /api/v1/scim/v2/Users?filter=userName eq "jane@example.com"&startIndex=1&count=100
POST   /api/v1/scim/v2/Users
GET    /api/v1/scim/v2/Users/{id}
PUT    /api/v1/scim/v2/Users/{id}
PATCH  /api/v1/scim/v2/Users/{id}
DELETE /api/v1/scim/v2/Users/{id}
GET    /api/v1/scim/v2/Groups?filter=displayName eq "SAP architects"
POST   /api/v1/scim/v2/Groups
GET    /api/v1/scim/v2/Groups/{id}
PUT    /api/v1/scim/v2/Groups/{id}
PATCH  /api/v1/scim/v2/Groups/{id}
DELETE /api/v1/scim/v2/Groups/{id}

• Users: the e-mail address is taken from the primary emails entry, otherwise the first entry, otherwise userName. name (formatted, or givenName and familyName) and displayName are used only when the account is created. PUT updates userName, externalId and active; changing the e-mail address is rejected. PATCH supports the operations add and replace for active.
• Groups: displayName, externalId and members (ids of users of this organization; other ids are ignored). PATCH supports add, replace and remove on members, removal via members[value eq "<id>"], and changing displayName.
• Filters (URL-encoded): users by userName eq, externalId eq or emails eq; groups by displayName eq. User lists are paged with startIndex and count (default 100, at most 200).
• Not supported: bulk operations, sorting, ETags, password changes and the /Schemas endpoint.

Responses and errors use application/scim+json and the SCIM error schema. Requests of a suspended organization are rejected.