Fédération d'identité et provisionnement

Scrydon peut se placer des deux côtés d'une fédération : il connecte vos membres via votre fournisseur d'identité, et il agit en tant que fournisseur d'identité pour les applications que vous développez. Tout ce qui suit se trouve sous Paramètres → Organisation → Identité et provisionnement, et chaque action requiert les droits d'administrateur de l'organisation.

Connecter votre fournisseur d'identité

Ajouter un fournisseur accepte un émetteur (issuer) ou une URL de métadonnées et remplit le reste.

• OIDC — collez l'émetteur (par exemple https://login.example.okta.com/oauth2/default). Scrydon lit le document de découverte et pré-remplit les points de terminaison et les clés de signature. Ajoutez l'identifiant et le secret client fournis par votre IdP.
• SAML — collez l'URL de métadonnées, pas l'émetteur (par exemple https://idp.example.com/api/saml/metadata). Scrydon y lit l'entity ID, l'URL de connexion et le certificat de signature. Vous pouvez aussi saisir l'URL de connexion et le certificat à la main sous Avancé.

Scrydon affiche ensuite les deux valeurs dont votre IdP a besoin :

Pour OIDC, l'équivalent est l'URL de rappel, à ajouter à la liste des redirections autorisées de votre IdP.

Signature et chiffrement des requêtes (SAML)

De nombreux fournisseurs d'identité publics et de défense exigent que le fournisseur de service signe ses requêtes d'authentification — leurs métadonnées l'indiquent, et Scrydon les lit. Le cas échéant, l'écran d'ajout active la signature pour vous et demande une clé.

• Clé de signature du fournisseur de service — une clé privée PEM que vous fournissez. Scrydon n'en génère pas à votre place : pour un déploiement réglementé, la clé relève de votre propre ICP, et une clé logicielle créée dans la base d'une application est précisément ce que ces règles visent à empêcher.
• Votre certificat de signature, et sa transmission au fournisseur d'identité — les métadonnées SP générées par Scrydon annoncent la signature des requêtes, mais ne contiennent pas votre certificat. Votre fournisseur d'identité en a besoin pour vérifier ce que nous signons. Deux moyens, dont l'un est indispensable : transmettre le certificat directement à votre fournisseur d'identité (la plupart des consoles acceptent un téléversement), ou publier des métadonnées de fournisseur de service qui le contiennent — collez vos propres métadonnées SP incluant un <KeyDescriptor use="signing">, et Scrydon les sert telles quelles à l'URL de métadonnées SP. Tant que ce n'est pas fait, un fournisseur d'identité qui impose les requêtes signées rejette toutes les connexions, et l'erreur est levée chez lui, pas dans Scrydon. La fiche du fournisseur le signale sous Notre certificat de signature.
• L'expiration de votre certificat — affichée au même endroit. Elle compte davantage que celle du fournisseur d'identité, car un certificat expiré échoue chez celui-ci et rien dans Scrydon ne le signale.
• Assertions chiffrées — votre fournisseur d'identité chiffre l'assertion vers votre certificat. Fournissez la clé de déchiffrement correspondante.

Des métadonnées ayant dépassé leur propre validUntil sont également refusées. Les fédérations utilisent cette date pour imposer un rafraîchissement périodique, et un document expiré peut figer un certificat de signature que votre fournisseur a déjà renouvelé.

Correspondance des attributs

Laissez les noms d'attributs vides sauf si votre IdP en utilise de non standard. La connexion retombe de toute façon sur le NameID SAML ou le subject OIDC : un mappage vide est donc la bonne réponse pour Okta, Google Workspace et la plupart des fournisseurs SAML. Microsoft Entra ID publie ses revendications sous des URI http://schemas.xmlsoap.org/ws/2005/05/identity/claims/… — nommez-les explicitement si vous voulez que le nom affiché provienne d'une revendication plutôt que du NameID.

Renseignez les deux champs (e-mail et nom affiché) ou aucun. Un mappage à moitié rempli est rejeté.

Vérifier votre domaine

Le domaine d'un fournisseur reste non vérifié tant que vous n'avez pas publié l'enregistrement TXT affiché dans sa fiche puis cliqué sur Vérifier maintenant. Tant qu'il n'est pas vérifié, personne ne peut se connecter via ce fournisseur, et Scrydon refuse de lui laisser rattacher des comptes existants : la vérification prouve que votre organisation contrôle le domaine.

Ignorer la vérification (bris de glace)

Certains domaines ne peuvent pas être vérifiés parce que vous ne pouvez pas y publier de DNS — un environnement local, de préproduction ou de démonstration. Ignorer la vérification, dans la fiche du fournisseur, permet malgré tout la connexion.

C'est délibérément un mécanisme de bris de glace : il se referme tout seul.

• L'exception expire au bout de 7 jours. Passé ce délai, le fournisseur redevient non vérifié et cesse de connecter qui que ce soit tant que le DNS n'a pas prouvé le domaine — exactement l'état qui aurait été le sien sans l'exception.
• Le fournisseur porte le badge Ignorée, jamais Vérifié : le badge ne fait pas semblant qu'un contrôle a eu lieu.
• L'octroi, la révocation et l'expiration automatique sont tous consignés dans le journal d'audit.

Exiger à nouveau la vérification y met fin immédiatement, et la publication de l'enregistrement TXT lève l'exception d'elle-même.

Niveau de garantie requis

Sous Connexion, dans la fiche d'un fournisseur OIDC. C'est ainsi que le NIST SP 800-63 (AAL) et eIDAS (« substantiel » / « élevé ») s'appliquent concrètement.

Votre fournisseur d'identité indique la solidité de l'authentification qu'il a effectuée sous forme de valeur acr. Indiquez les valeurs que vous acceptez — une par ligne — et Scrydon refuse toute connexion en annonçant une autre. Laissez vide pour n'imposer aucune exigence.

Deux comportements à connaître avant de vous y fier :

• Il s'agit d'un ensemble de valeurs acceptées, pas d'un seuil. Les valeurs acr sont des URI opaques qu'aucune norme n'ordonne : Scrydon ne devinera pas que l'une est « plus forte » qu'une autre. Énumérez toutes celles que vous acceptez.
• Une connexion qui n'annonce aucun niveau est refusée. Un fournisseur d'identité qui ne dit pas comment il a authentifié n'a pas atteint un seuil qu'il n'a jamais revendiqué.

SAML est également appliqué. Le fournisseur d'identité indique le niveau dans <AuthnContextClassRef>, à l'intérieur de l'assertion. Scrydon ne le lit que dans le fragment couvert par la signature de l'assertion : une valeur falsifiée ajoutée hors signature est totalement invisible pour le contrôle. C'est là tout l'enjeu : une réponse à enveloppement de signature contient l'assertion faible authentique et signée à côté d'une assertion forte falsifiée, et un contrôle qui lit le document entier admet une connexion à un niveau que le fournisseur d'identité n'a jamais attesté.

Certificat de signature des métadonnées de la fédération

Sous Certificat de signature des métadonnées de la fédération, dans la fiche d'un fournisseur SAML. Renseignez-le si les métadonnées de votre fournisseur d'identité proviennent d'une fédération — InCommon, eduGAIN, une fédération d'identité nationale ou sectorielle — plutôt que directement du fournisseur.

Une fédération publie un document de métadonnées signé et impose à chaque membre de le vérifier avec la clé de signature de la fédération avant d'accorder la moindre confiance à son contenu. C'est cette signature qui rend le document digne de confiance : TLS authentifie le serveur qui a servi les octets, mais seule la signature authentifie la fédération qui les a rédigés — et seule la seconde affirme « cette entité est bien membre, et voici réellement ses points d'accès et ses certificats ».

Collez le certificat de signature de la fédération au format PEM. Une fois épinglé :

• Les métadonnées déjà enregistrées pour ce fournisseur sont vérifiées immédiatement. Si elles ne se vérifient pas, le certificat est refusé et rien n'est modifié — vous l'apprenez maintenant plutôt qu'à la prochaine connexion.
• Toute modification ultérieure des métadonnées de ce fournisseur doit se vérifier avec ce certificat, y compris les modifications qui n'en font pas mention. Un administrateur ne peut pas faire accepter des métadonnées non vérifiées en l'omettant.

Lors d'une rotation de clé de la fédération, l'ancien et le nouveau certificat sont publiés simultanément. Collez les deux, séparés par une ligne vide ; un membre qui n'en accepte qu'un cesse de fonctionner le jour de la bascule.

Laissez le champ vide si ce fournisseur ne fait pas partie d'une fédération. La plupart des fournisseurs d'identité publient des métadonnées non signées, et exiger une signature de tous bloquerait le parcours ordinaire.

Exiger un second approbateur (double contrôle)

Sous Exiger un second approbateur, dans la fiche de n'importe quel fournisseur, SAML ou OIDC.

Chaque réglage de cette page détermine qui peut s'authentifier en tant que qui, et chacun est enregistré au nom de l'administrateur qui l'a modifié. Cela répond à la question qui l'a fait — et un seul administrateur peut toujours le faire. Lorsqu'un second approbateur est requis, une modification est enregistrée plutôt qu'appliquée, et un autre propriétaire doit l'approuver pour qu'elle prenne effet.

Sont couverts : l'application du SSO, la connexion initiée par l'IdP, le contournement de la vérification de domaine, la politique de niveau de garantie, le certificat de signature de la fédération, la suppression de la connexion, et la désactivation de ce réglage. L'enregistrement d'une nouvelle connexion n'est pas couvert : il n'accorde aucun accès tant qu'un domaine n'est pas vérifié et que l'application n'est pas activée — deux points qui, eux, le sont.

Trois précisions utiles :

• Vous ne pouvez pas approuver votre propre demande. Sinon, c'est une seule paire d'yeux qui clique deux fois.
• Une demande expire au bout de 72 heures. Approuver une demande formulée trois jours plus tôt, dans un contexte que personne n'a réexaminé, n'est pas une revue. Reformulez-la.
• Désactiver ce réglage requiert également une approbation — un dispositif qu'une seule personne peut désactiver n'en est pas un. L'activer prend effet immédiatement.

L'approbateur voit exactement ce qui a été demandé, valeurs comprises : approuver « application du SSO » sans voir qu'il s'agit de la désactiver revient à approuver un mot.

Ce qui est chiffré, et ce que nous ne stockons jamais

Le secret client de votre fournisseur d'identité et les éventuelles clés SAML du fournisseur de service sont chiffrés au repos dans la base de Scrydon. Rien ne les déchiffre en dehors du service d'authentification.

Scrydon ne demande ni ne stocke jamais les identifiants de vos utilisateurs : l'authentification a lieu entièrement chez votre fournisseur d'identité.

Imposer le SSO

Avec Imposer le SSO, la connexion par mot de passe et via les réseaux sociaux est désactivée pour ce domaine. Les membres ne peuvent se connecter que par votre IdP.

Connexion initiée par l'IdP (SAML)

Désactivée par défaut, et réglable par fournisseur dans sa fiche.

Désactivée, une connexion doit commencer sur Scrydon. Activée, vos membres peuvent partir de la tuile applicative de votre IdP : Scrydon rejette l'assertion non sollicitée envoyée par la tuile, puis relance immédiatement la connexion comme un flux normal initié par le fournisseur de service. Comme le navigateur détient encore une session chez votre IdP, l'opération est invisible — une redirection de plus — et l'assertion finalement acceptée par Scrydon est toujours une assertion qu'il a lui-même demandée et qu'il peut corréler à sa propre requête.

Provisionner les membres avec SCIM

Émettez un identifiant de provisionnement depuis l'onglet SCIM et transmettez à votre IdP l'URL de base SCIM affichée ainsi que le jeton. Le jeton n'est affiché qu'une seule fois.

Scrydon prend en charge SCIM 2.0 pour les Users et les Groups : création, mise à jour, PATCH, filtrage sur GET et suppression logique. Un membre retiré de tous les groupes est suspendu, jamais supprimé — un nouveau provisionnement réactive le même compte et conserve son historique.

Groupes et équipes

L'onglet Groupes liste chaque groupe d'annuaire provisionné par votre IdP et permet de le rattacher à une équipe Scrydon.

Créer les équipes automatiquement (activé par défaut) décide du sort d'un groupe que vous n'avez pas rattaché : une équipe Scrydon correspondante est créée. Désactivez l'option si vous gérez vos équipes à la main — les groupes non rattachés sont alors ignorés et seuls vos rattachements explicites s'appliquent. Dans tous les cas, les équipes absentes de la table de correspondance ne sont jamais modifiées par le provisionnement : une équipe gérée manuellement reste intacte.

Utiliser Scrydon comme fournisseur d'identité

Scrydon est un fournisseur OAuth 2.1 / OIDC complet. Scrydon Identity, dans la liste des fournisseurs, affiche les points de terminaison dont votre application a besoin :

Types d'autorisation pris en charge : code d'autorisation (avec PKCE), client credentials et refresh token. Pointez votre bibliothèque sur l'URL de découverte, elle trouvera le reste.

Enregistrer une application

Enregistrer une application vous demande ce que vous construisez ; le modèle d'identifiants en découle.

Un client machine à machine n'a ni utilisateur ni URL de rappel. Ses portées sont obligatoires, car aucun utilisateur connecté ne lui transmet ses permissions : ce que vous accordez est exactement ce qu'il peut faire. Son secret n'est affiché qu'une seule fois.