F5 APM : MFA, RSA et certificat client

Un parcours MFA combine des preuves selon le modèle retenu. Deux écrans qui redemandent le même mot de passe ne créent pas automatiquement deux facteurs indépendants. La branche de succès doit exiger le résultat prévu pour chaque contrôle.

RSA SecurID utilise un service AAA et ses paramètres ; le certificat client dépend du profil TLS, de la chaîne de confiance et des contrôles de révocation configurés. Posséder un certificat sans validation appropriée ne suffit pas à prouver une identité autorisée.

Reliez l’identité obtenue au compte et aux groupes utilisés ensuite. Une UPN extraite d’un certificat doit correspondre au contrat d’identité de l’annuaire. Vérifiez les cas certificat absent, expiré, non fiable et utilisateur sans droit.

Recettez aussi le secours AAA et les comportements de reconnexion. Un timeout du second facteur doit suivre une décision volontaire, sans tomber sur une branche permissive parce que la première authentification a réussi.

Ces repères permettent de relier le besoin à la configuration et aux observations. Comparer les objets réellement attachés au service avant de modifier un réglage.

La première authentification réussit mais RSA est indisponible. Le parcours doit suivre la politique de refus ou le secours explicitement prévu, pas Allow par fallback. Testez ce cas avec une session neuve pour vérifier toutes les conditions.

Expliquez la décision du schéma, puis recherchez dans la référence les objets qui la produisent. Pour APM, justifiez aussi ce qui changerait si un prérequis échouait : une réponse DNS, une décision WAF et une autorisation d’accès ne se vérifient pas au même endroit.

Revenir au parcours F5 APM pour lire les guides voisins et leurs exemples.