Identity federation & provisioning
Connect your own identity provider over OIDC or SAML, provision members automatically with SCIM, use Scrydon as an identity provider for your own applications, and register machine clients.
Scrydon can sit on either side of a federation: it signs your members in through your identity provider, and it acts as an identity provider for applications you build. Everything below lives under Settings → Organization → Identity & provisioning, and every action needs organization-admin rights.
Connect your identity provider
Add provider takes an issuer or a metadata URL and fills in the rest.
- OIDC — paste the issuer (for example
https://login.example.okta.com/oauth2/default). Scrydon reads the discovery document and prefills the endpoints and signing keys. Add the client ID and secret from your IdP. - SAML — paste the metadata URL, not the issuer (for example
https://idp.example.com/api/saml/metadata). Scrydon reads the entity ID, the sign-on URL and the signing certificate from it. You can also paste the sign-on URL and certificate by hand under Advanced.
Scrydon then shows the two values your IdP needs from us:
| Field | What your IdP calls it |
|---|---|
| ACS URL | Reply URL · Assertion Consumer Service (SAML) |
| SP metadata URL | Most IdPs configure themselves entirely from this |
For OIDC the equivalent is the callback URL, which goes in your IdP's allowed redirect list.
Scrydon validates every endpoint in an OIDC discovery document against your
allowed-origin list, not just the issuer. If registration fails with
discovery_untrusted_origin, the message names the endpoint that was refused.
Request signing and encryption (SAML)
Many government and defence identity providers require the service provider to sign its authentication requests — their metadata says so, and Scrydon reads it. When it does, the add-provider sheet turns request signing on for you and asks for a signing key.
- Service-provider signing key — a PEM private key you supply. Scrydon does not generate one for you: for regulated deployments the key belongs to your own PKI, and a software key minted into an application database is what those rules exist to prevent.
- Your signing certificate, and getting it to your identity provider — the SP metadata Scrydon generates announces that it signs requests, but it does not carry your certificate. Your identity provider needs it to verify anything we sign. Two ways to supply it, and you need one of them: give the certificate to your identity provider directly (most consoles accept an upload), or publish service-provider metadata that contains it — paste your own SP metadata including a
<KeyDescriptor use="signing">, and Scrydon serves that verbatim at the SP metadata URL. Until one of these is done, an identity provider that enforces signed requests rejects every sign-in, and the error is raised at your provider rather than in Scrydon. The provider sheet says so under Our signing certificate. - Your certificate's expiry — shown in the same place. It matters more than the identity provider's, because an expired one fails at your identity provider and nothing in Scrydon reports it.
- Encrypted assertions — your identity provider encrypts the assertion to your certificate. Supply the matching decryption key.
A configuration that cannot work is refused when you save it, not when your first user tries to sign in: request signing without a key, encrypted assertions without a decryption key, an identity provider that demands signed requests when you have supplied none, or SHA-1 for a signature or digest algorithm — prohibited by every current assurance regime.
Metadata that has passed its own validUntil is refused too. Federations use that date to force periodic re-fetch, and an expired document may pin a signing certificate your provider has already rotated.
Attribute mapping
Leave the attribute names blank unless your IdP uses non-standard ones. Sign-in falls back to the SAML NameID or the OIDC subject either way, so a blank mapping is the right answer for Okta, Google Workspace and most SAML providers. Microsoft Entra ID publishes its claims under http://schemas.xmlsoap.org/ws/2005/05/identity/claims/… URIs — name them explicitly if you want the display name to come from a claim rather than the NameID.
Set both the email and display-name fields or neither. A half-filled mapping is rejected.
Verify your domain
A provider's domain is unverified until you publish the TXT record shown in the provider's detail sheet and press Check now. Until it is verified, nobody can sign in through the provider at all, and Scrydon will not let it link existing accounts — verification is what proves your organization controls the domain.
Skipping verification (break-glass)
Some domains cannot be verified because you cannot publish DNS for them — a local, staging or demo tenant. Skip verification in the provider's detail sheet lets sign-in work anyway.
Skipping removes the check that stops an organization claiming a domain it does not own. Anyone who can add a provider for that domain can then route its sign-ins and link existing accounts at it — that is account takeover, not an inconvenience. Only skip it on a domain you control but cannot publish DNS for.
It is deliberately break-glass, so it closes itself:
- The bypass expires after 7 days. Past that the provider reverts to unverified and stops signing anyone in until DNS proves the domain — exactly the state it would have been in had the bypass never been granted.
- The provider is badged Bypassed, never Verified. The badge does not pretend a check happened.
- Granting it, revoking it, and its automatic lapse are all written to the audit log.
Require verification again ends it early, and publishing the TXT record clears it on its own.
Required assurance level
Under Sign-in on an OIDC provider's detail sheet. This is how NIST SP 800-63 AAL and eIDAS "substantial"/"high" are enforced in practice.
Your identity provider states the strength of the authentication it performed as an acr value. List the values you accept — one per line — and Scrydon refuses any sign-in asserting anything else. Leave it empty to require nothing.
Two behaviours are worth knowing before you rely on it:
- It is a set of accepted values, not a threshold. ACR values are opaque URIs and nothing in the standards orders them, so Scrydon will not guess that one is "stronger" than another — list every value you accept.
- A sign-in that asserts no level is refused. An identity provider that does not say how it authenticated has not met a bar it never claimed to meet.
SAML is enforced too. The identity provider states the level in
<AuthnContextClassRef> inside the assertion. Scrydon reads it only from the
fragment the assertion's signature covers — a forged value appended outside
the signature is not visible to the check at all. That distinction is the whole
control: a signature-wrapping response carries the genuine signed weak assertion
alongside a forged strong one, and a checker that reads the whole document
admits a sign-in at a level the identity provider never asserted.
Not available on a provider with encrypted assertions — the authentication context is inside the ciphertext, so no check outside the sign-in itself can read it. Setting a level on one is refused when you save it, rather than silently doing nothing.
Federation metadata signing certificate
Under Federation metadata signing certificate on a SAML provider's detail sheet. Set this if your identity provider's metadata comes from a federation — InCommon, eduGAIN, a national or sector identity federation — rather than directly from the provider.
A federation publishes one signed metadata document and requires every member to verify it against the federation's own signing key before trusting anything inside. That signature is what makes the document trustworthy: TLS authenticates the server that served the bytes, but only the signature authenticates the federation that authored them — and only the second says "this entity really is a member, and these really are its endpoints and certificates".
Paste the federation's signing certificate in PEM form. Once it is pinned:
- The metadata already stored for this provider is verified immediately. If it does not verify, the certificate is refused and nothing changes — you find out now rather than at the next sign-in.
- Every later change to this provider's metadata must verify against it, including changes that do not mention the certificate. An administrator cannot get unverified metadata accepted by omitting it.
During a federation key rotation both the outgoing and incoming certificates are published. Paste both, separated by a blank line; a member that accepts only one of them stops working on the cutover day.
Leave it empty if this provider is not part of a federation. Most identity providers publish unsigned metadata, and requiring a signature from all of them would block the ordinary path.
SAML providers only. An OIDC provider has no metadata document to verify, so setting a certificate on one is refused rather than stored.
Require a second approver (four-eyes)
Under Require a second approver on any provider's detail sheet, SAML or OIDC.
Every setting on this page decides who may authenticate as whom, and each one is recorded against the administrator who changed it. That answers who did it — and a single administrator can still do it. With a second approver required, a change is recorded rather than applied, and a different owner has to approve it before it takes effect.
Covered: SSO enforcement, IdP-initiated login, the domain-verification bypass, the assurance policy, the federation signing certificate, deleting the connection, and turning this setting off. Registering a new connection is not covered — it grants nobody access until a domain is verified and enforcement is set, and both of those are.
Three details worth knowing:
- You cannot approve your own request. Otherwise it is one pair of eyes clicking twice.
- A request expires after 72 hours. Approving something raised three days ago, against a situation nobody re-examined, is not review. Raise it again.
- Turning this setting off needs approval too — a scheme one person can switch off alone is not a scheme. Turning it on takes effect immediately.
An approver sees exactly what was requested, including the values: approving "enforcement" without seeing that it sets enforcement off is approving a word.
What is encrypted, and what we never store
Your identity provider's client secret and any SAML service-provider keys are encrypted at rest in Scrydon's database. Nothing decrypts them outside the authentication service.
Scrydon never asks for, and never stores, your users' credentials — authentication happens entirely at your identity provider.
Require SSO
With Require SSO on, password and social sign-in are disabled for that domain. Members can only sign in through your IdP.
IdP-initiated login (SAML)
Off by default, and settable per provider in the provider's detail sheet.
Off, a login must start at Scrydon. On, your members can start from your IdP's app tile: Scrydon discards the unsolicited assertion the tile sends, then immediately restarts the login as a normal service-provider-initiated flow. Because the browser still holds a session at your IdP, this is invisible — one extra redirect — and the assertion Scrydon finally accepts is always one it asked for and can correlate to its own request.
Unsolicited SAML responses are a known attack vector, and the SAML2Int interoperability profile recommends against accepting them. Turning this on does not make Scrydon accept one; it only allows the bounce described above.
Where a sign-in may return to
The address a sign-in returns to after your identity provider is finished is
restricted. Scrydon accepts a path on its own site, or a full address on an
origin it is configured to trust; anything else is refused with
UNTRUSTED_REDIRECT_TARGET before the sign-in starts.
You only need to think about this if you link people straight into Scrydon with
a callbackURL — deep links into your own Scrydon tenant keep working, and a
link that tries to send someone somewhere else after they authenticate does not.
The trusted list is the same one that governs browser access to the
authentication service, so a Scrydon deployment's own addresses are always on
it. Self-hosting on additional hostnames? Add them to CORS_ORIGINS.
Provision members with SCIM
Issue a provisioning credential from the SCIM tab and give your IdP the SCIM base URL it shows, along with the token. The token is displayed once.
Scrydon supports SCIM 2.0 Users and Groups: creation, update, PATCH, filtering on GET, and soft deletion. A member removed from every group is suspended, never deleted — re-provisioning reactivates the same account, keeping their history.
Tested against Entra ID and Okta
Scrydon's SCIM endpoint is exercised on every build by replaying the requests Microsoft Entra ID and Okta actually send — taken from those vendors' own documentation, including the places where they deviate from the SCIM standard. Both providers' full joiner–mover–leaver cycle is covered: create, attribute update, group membership in and out, deactivate, and reactivate.
Two specifics worth knowing when you configure provisioning:
- Entra works with or without the
aadOptscim062020flag. Microsoft's default provisioning dialect sends a few non-standard shapes — notably deactivation as the string"False"rather than a boolean. Scrydon accepts both dialects, so you do not need to change your tenant URL, and nothing breaks when Microsoft makes the compliant behaviour the default. - Okta's deactivation is a soft delete. Okta never sends
DELETE; it PATCHesactivetofalse, which Scrydon treats as offboarding — the person loses access and their record is preserved for a possible return.
AWS IAM Identity Center provisions into AWS rather than out to applications, so it is not a provisioning source for Scrydon. If your people live in Entra ID or Okta and you also provision AWS from there, point the same identity provider at Scrydon.
Groups and teams
The Groups tab lists every directory group your IdP has provisioned and lets you map each one onto a Scrydon team.
Create teams automatically (on by default) decides what happens to a group you have not mapped: a matching Scrydon team is created for it. Turn it off if you curate teams by hand — unmapped groups are then ignored, and only the mappings you set take effect. Either way, teams outside the mapping table are never touched by provisioning, so a manually curated team survives untouched.
Two known limits, both inherited from the underlying SCIM implementation: the
POST /.search endpoint is not implemented (filter on GET instead, which is
what Entra ID and Okta use), and PATCH remove has no effect on some
attributes. A user's email cannot be removed at all — Scrydon keys identity on
a verified email address.
Use Scrydon as your identity provider
Scrydon is a full OAuth 2.1 / OIDC provider. Scrydon Identity in the provider list shows the endpoints your application needs:
| Endpoint | Path |
|---|---|
| OIDC discovery | /api/auth/.well-known/openid-configuration |
| JWKS | /api/auth/jwks |
| Authorization | /api/auth/oauth2/authorize |
| Token | /api/auth/oauth2/token |
| Userinfo | /api/auth/oauth2/userinfo |
Supported grants: authorization code (with PKCE), client credentials, and refresh token. Point your library at the discovery URL and it will find the rest.
Register an application
Register app asks what you are building; the credential model follows from it.
| Application type | Credential | Use for |
|---|---|---|
| Web app | Client secret, plus code + PKCE | Server-side apps and proxies such as oauth2-proxy |
| Native / SPA | None — code + PKCE only | Mobile apps, single-page apps, CLIs |
| Machine-to-machine | Client secret, client_credentials | Servers, jobs and integrations that act as themselves |
A machine-to-machine client has no user and no redirect URI. Its scopes are mandatory, because there is no signed-in user whose permissions it could inherit — what you grant is exactly what it can do. Its secret is shown once.
Service accounts that carry a clearance for data classification are created under Settings → Organization → Members, not here. Their clearance is capped by your own, and their credential deliberately never reaches the browser.