Skip to content

SAML

Axowl supports SAML in both directions, scoped per organization.

SP — Axowl as Service Provider (inbound enterprise SSO)

Section titled “SP — Axowl as Service Provider (inbound enterprise SSO)”

An enterprise’s own IdP (ADFS/Okta/Entra) logs the user into an Axowl-backed app. Base path: /api/public/orgs/{slug}/auth/saml.

Method · RoutePurposeSource
GET loginEmit a SAML AuthnRequest (302 to the IdP)SamlAuthEndpoints.cs:57
GET metadataSP metadata (EntityID, ACS URL):125
POST acsAssertion Consumer Service — validates the SAMLResponse:158

The ACS is implemented (not a stub): it uses Saml2Response.GetClaims(options) (:236) — Sustainsys.Saml2 — to verify the signature, conditions, and audience, then JITs a ConnectedId via attribute mapping and issues the session, reusing the existing FederatedLoginCommand (pre-verified branch). Forged-signature rejection is covered by an automated test (PrK_SamlAcsSignatureTests).

IdP — Axowl as Identity Provider (“Sign in with Axowl”)

Section titled “IdP — Axowl as Identity Provider (“Sign in with Axowl”)”

A registered SP receives a signed SAML assertion from Axowl. Base path: /api/public/orgs/{slug}/saml/idp.

Method · RoutePurposeSource
GET metadataIdP metadata + signing cert (org RSA key)SamlIdpEndpoints.cs:46
GET/POST ssoParse AuthnRequest, verify SP registration:278
GET sso/continueResume after login; POST signed Response to the SP’s ACS:286

SP registration (EntityID, ACS URL) lives on the Application — see Applications. The IdP signs the Response with the org’s RSA key (RSA-SHA256), reusing the portal handshake bridge.