SSO d'entreprise vers Obexal (Obexal comme SP)

Laissez vos utilisateurs se connecter à Obexal via votre IdP SAML d'entreprise (Entra ID, ADFS, Okta, Keycloak), avec validation d'assertion durcie, liaison de compte automatique et provisioning JIT.

Si votre entreprise exploite déjà un fournisseur d'identité (Microsoft Entra ID, ADFS, Okta, Keycloak, ou tout IdP SAML 2.0), vos utilisateurs peuvent se connecter à Obexal avec lui. Obexal joue le rôle de Service Provider SAML : il envoie l'utilisateur vers votre IdP, valide l'assertion retournée, puis ouvre une session Obexal ordinaire. Il existe une connexion SAML par organisation. Pour le sens inverse (Obexal émettant des assertions vers vos applications), voir Obexal comme IdP.

Ce qu'Obexal expose à votre IdP

{tenant} est le slug de votre organisation. Les exemples utilisent accounts.obexal.com ; votre domaine de connexion personnalisé le remplace si vous en avez un.

Endpoint	Rôle
`GET /saml/{tenant}/metadata`	Métadonnées SP (XML). L'entityID du SP est cette URL
`GET /saml/{tenant}/login?redirect_uri=`	Démarre le SSO SP-initiated (redirige vers votre IdP)
`POST /saml/{tenant}/acs`	Assertion Consumer Service (appelé par votre IdP)

Dans votre IdP d'entreprise, créez l'application avec cet entityID et cette URL ACS (la plupart des produits importent directement l'URL de métadonnées).

Configurer la connexion

La configuration exige la permission tenant:manage (session console ou jeton d'API admin obx_). Vous collez les métadonnées XML de votre IdP et activez la connexion ; le XML est analysé et rejeté avec un 400 s'il est invalide :

curl -sS -X PUT https://accounts.obexal.com/v1/admin/saml \
  -H "Authorization: Bearer $OBEXAL_API_TOKEN" -H 'Content-Type: application/json' \
  -d "{\"metadataXml\": $(jq -Rs . < idp-metadata.xml), \"enabled\": true}"
# 200 -> {"status":"ok"}

GET /v1/admin/saml retourne l'état courant (configured, enabled, metadataXml). Dans la console d'administration, le même réglage se trouve dans le panneau SSO SAML entrant : téléchargez le XML de métadonnées de fédération depuis votre IdP (dans Entra ID : le « Federation Metadata XML » de l'application d'entreprise ; dans Keycloak : le descripteur SAML du realm) et collez-le là.

Le déroulement de la connexion

Le navigateur ouvre /saml/{tenant}/login?redirect_uri=.... Le redirect_uri (où l'utilisateur atterrit après connexion) est validé contre les origines autorisées.
Obexal construit une AuthnRequest (binding HTTP-Redirect, non signée) et redirige vers l'URL SSO de votre IdP. L'état du flux est conservé côté serveur, haché, à usage unique, avec un TTL de 10 minutes, et rattaché au RelayState.
L'utilisateur s'authentifie chez votre IdP, qui POSTe la réponse signée vers l'ACS.
Obexal valide l'assertion, résout le compte, puis pose le cookie de session et redirige vers redirect_uri, ou redirige vers l'écran MFA. En cas d'échec, l'utilisateur est redirigé avec error=social_failed (assertion invalide) ou error=social_state (état de flux expiré ou rejoué) ; aucune session n'est jamais posée sur échec.

Validation d'assertion durcie

Aucune session n'existe tant que l'assertion n'a pas passé chaque contrôle :

Signature : vérifiée contre le certificat publié dans les métadonnées de votre IdP. Les assertions doivent être signées.
Conditions : restriction d'audience, fenêtres NotBefore et NotOnOrAfter.
Anti-rejeu : le InResponseTo de la réponse doit correspondre à l'ID de l'AuthnRequest qu'Obexal a réellement émise pour ce navigateur ; cet ID est conservé côté serveur et consommé une seule fois. Les réponses non sollicitées (IdP-initiated) ne sont donc pas acceptées.

L'extraction d'identité est volontairement minimale : le NameID devient le sujet fédéré stable, et l'e-mail est lu dans le premier attribut dont le nom contient email ou mail (y compris l'URI standard claims/emailaddress). Sans attribut e-mail, si le NameID est lui-même une adresse e-mail, il est utilisé. Les e-mails sont mis en minuscules.

Résolution du compte et provisioning JIT

L'identité fédérée est scopée à votre organisation : le même NameID chez deux tenants reste deux identités distinctes. La résolution, dans l'ordre :

L'identité est déjà liée à un utilisateur : connexion directe.
Première fois pour cette identité, et un compte local existe avec l'e-mail affirmé : l'identité y est liée automatiquement et l'e-mail est marqué vérifié (votre IdP d'entreprise s'en porte garant).
Aucun compte n'existe : un utilisateur est provisionné à la volée (JIT), avec l'e-mail déjà vérifié.

Une première connexion exige un e-mail dans l'assertion ; sans e-mail, le flux échoue. Chaque chemin écrit dans le journal d'audit.

La MFA s'applique après la fédération

Le SAML est un facteur primaire, exactement comme le mot de passe : si le compte résolu a un facteur MFA actif, aucune session n'est ouverte à l'ACS. Le navigateur est redirigé vers l'écran MFA avec un token de défi à usage unique ; voir le point de passage MFA. Les règles d'accès conditionnel s'appliquent aussi.

Limites, en toute honnêteté

Une connexion SAML par organisation ; impossible de fédérer plusieurs IdP d'entreprise dans un même tenant.
Les assertions doivent être signées et non chiffrées ; les assertions chiffrées ne sont pas prises en charge.
Votre IdP doit exposer un binding SSO HTTP-Redirect ; l'AuthnRequest elle-même n'est pas signée.
La connexion IdP-initiated vers Obexal n'est pas acceptée (conséquence de la validation stricte du InResponseTo).
Seuls le sujet et l'e-mail sont consommés depuis l'assertion ; les autres attributs (nom, groupes) ne sont pas mappés. Utilisez le provisioning SCIM pour synchroniser les profils.
Pas de Single Logout SAML.