Sécurité
Votre application accepte-t-elle ce qu'elle devrait refuser ? ID-Kit joue l'IdP et envoie des réponses piégées : vous vérifiez que chaque piège est bien refusé.
Votre application doit refuser ou lire uniquement l'assertion signée. Si elle connecte « admin@evil.example », elle est vulnérable.
Votre application doit lire le NameID COMPLET (alice@example.test.evil.example) ou refuser. Si elle comprend « alice@example.test », elle est vulnérable à l'attaque de 2018 : un attaquant pourrait se faire passer pour quelqu'un d'autre.
Votre application doit refuser : rien ne prouve que la réponse vient de l'IdP.
Votre application doit refuser : l'identité a été changée après la signature.
Votre application doit refuser : la signature n'est pas celle du certificat de confiance.
Votre application doit refuser : un identifiant d'assertion doit être unique, sinon la signature peut être détournée.
Votre application doit refuser : toutes les AudienceRestriction doivent être satisfaites (c'est un ET logique).
Votre application doit afficher ces valeurs sans les exécuter : pas de script, pas de HTML interprété, pas de plantage sur les guillemets ou les emojis.
Votre application doit refuser un second envoi de la même assertion (rejeu). Essayez d'envoyer deux fois la même réponse.
Pour une connexion lancée par votre application, elle doit refuser une réponse qui ne répond à aucune demande (sauf si elle accepte les connexions lancées par l'IdP).
Votre application doit refuser : la période de validité est déjà terminée.
Votre application doit refuser : la période de validité n'a pas commencé (utile pour tester la tolérance d'horloge).
Une application avec une tolérance d'horloge de 2 min refuse ; avec 5 min ou plus, elle accepte. Permet de connaître sa tolérance.
L'assertion a expiré depuis 5 minutes : refusée si la tolérance est inférieure à 5 min.
Votre application doit considérer la session de l'IdP comme terminée : elle ne doit pas ouvrir une session plus longue que celle-ci.
Votre application doit refuser : l'assertion est destinée à une autre application.
Votre application stricte doit refuser : rien n'indique pour quelle application l'assertion est faite.
Votre application doit refuser : la confirmation désigne une autre adresse ACS.
Votre application doit refuser : la réponse est adressée à une autre URL.
Votre application doit refuser : cette réponse ne correspond à aucune de ses demandes.
Votre application doit refuser : la réponse prétend venir d'un autre IdP que celui qu'elle a configuré.
Votre application doit refuser ou afficher une erreur claire : elle ne sait pas qui se connecte.
La connexion peut réussir, mais l'application doit gérer l'absence de nom, d'e-mail ou de groupes sans planter ni donner de droits par défaut.
Si votre application a demandé une authentification forte (RequestedAuthnContext), elle doit refuser : l'IdP indique seulement un simple mot de passe.
Si l'application a bien les DEUX certificats (ancien + nouveau, option « publier le certificat suivant »), elle accepte ; si elle n'a gardé que l'ancien, elle refuse. Révèle si une rotation de certificat provoquera une panne.
Votre application doit refuser : elle ne peut pas déchiffrer l'assertion et doit l'indiquer clairement (sans planter).
Votre application doit afficher une erreur claire et ne connecter personne.
Votre application, si elle a demandé IsPassive, doit rediriger vers un écran de connexion normal au lieu d'afficher une erreur brute.
Votre application doit afficher une erreur claire (l'IdP refuse de traiter la demande), sans planter ni boucler.
Votre application doit signaler que sa demande (format de NameID) n'est pas acceptée par l'IdP.
Votre application doit afficher une erreur de protocole propre, sans planter.
N'y envoyez jamais de secret réel : ce sont des identités fictives.