Dans un article précédent, j’utilisais Guard pour réaliser un mécanisme de double authentification (si vous ne voyez pas de quoi je parle, lisez ce blog post « Double authentification avec Symfony »). J’ai souhaité le mettre à jour pour utiliser la nouvelle fonctionnalité introduite dans Symfony 5.1.
Cette fonctionnalité redessine la façon de fonctionner des classes d’authentification en se basant sur les évents. Ainsi les nouvelles classes d’authentification qui ressemblent un peu à celle de Guard génèrent un passeport contenant toutes les informations nécessaires pour la validation de l’authentification.
Pour ce blog post, j’ai préféré vous présenter cette migration sous forme de questions et réponses.
Comment fonctionne la classe d’authentification ?
Premier point, une classe d’authentification doit (comme pour Guard) dire si oui ou non il supporte la requête en cours. Si oui, la méthode authenticate est appelée et devra retourner un objet qui implémente l’interface PassportInterface.
La méthode authenticate doit :
- Charger l’utilisateur depuis le fournisseur d’utilisateur.
- Collecter les informations d’authentification (depuis la requête en général).
- Générer le passeport avec la liste des badges nécessaires.
Comment sont vérifiées les informations d’authentification ?
Lors de la construction du passeport, le premier argument est l’objet utilisateur qui implémente l’interface UserInterface de Symfony. Le second est un « badge » spécifique qui implémente l’interface CredentialsInterface. Cet objet contiendra les informations d’authentification saisie par l’utilisateur qui tente de se connecter.
<?php
namespace Symfony\Component\Security\Http\Authenticator\Passport;
//...
class Passport implements UserPassportInterface
{
//...
/**
* @param CredentialsInterface $credentials the credentials to check for this authentication, use
* SelfValidatingPassport if no credentials should be checked.
* @param BadgeInterface[] $badges
*/
public function __construct(UserInterface $user, CredentialsInterface $credentials, array $badges = [])
{
//...
}
}
//...
}La vérification en elle-même dépend d’un écouteur (Listener/Subscriber) qui prend en charge la classe utilisée en second argument du constructeur de la classe passeport.
Qu’est-ce qu’un badge ?
Un badge est un objet qui est ajouté au passeport et qui permet de déclencher des vérifications supplémentaires lors de l’authentification. Par exemple, si l’utilisateur est actif, validation d’un code Yubikey…
Un badge doit implémenter l’interface BadgeInterface qui réclame que la méthode isResolved soit implémentée. Si cette méthode retourne la valeur « faux », l’authentification sera bloquée et l’utilisateur sera redirigé vers la page d’authentification.
Comment sont résolus les badges ?
Pour chaque badge il est nécessaire d’écrire un écouteur de l’événement SymfonyCheckPassportEvent. Ce dernier contient le passeport généré par la méthode authenticate de la classe d’authentification.
L’écouteur doit :
- Vérifier la présence dans le passeport du badge qu’il gère.
- Réaliser les traitements liés au badge.
- Si les conditions sont réunies, marquer le badge comme résolu (pour que la méthode
isResolvedretourne « vrai ») pour autoriser l’authentification.
Quelles sont les modifications marquantes ?
J’ai surtout dû ajouter beaucoup de classe puis déplacer certaines parties de code présentes dans les classes d’authentification vers les écouteurs.
Quelles sont les modifications apportées aux classes d’authentification ?
La première modification est l’héritage des classes AppLoginAuthenticator et AppTwoFactorAuthenticator qui est passé de SymfonyComponentSecurityGuardAuthenticatorAbstractFormLoginAuthenticator à SymfonyComponentSecurityHttpAuthenticatorAbstractLoginFormAuthenticator.
En observant le nom complet de la classe, il est possible de constater que je suis passé d’une classe d’authentification Guard à une classe d’authentification HTTP.
En suite les deux méthodes getUser et getCredentials on fusionné dans authenticate. La méthode checkCredentials pour la classe d’authentification AppLoginAuthenticator a été simplement supprimée, car c’est l’écouteur fourni par Symfony qui prend le relais pour vérifier le mot de passe de l’utilisateur.
Comment l’utilisateur est redirigé vers la page de saisie du second facteur ?
J’ai ajouté une classe de badge TwoFactorBadge avec son écouteur TwoFactorBadgeSubscriber. Lors de la construction du passeport dans AppLoginAuthenticator, ce badge est ajouté.
<?php
namespace AppSecurity;
final class AppLoginAuthenticator extends AbstractLoginFormAuthenticator
{
public function authenticate(Request $request): PassportInterface
{
$email = $request->get('email');
$user = $this->userRepository->findOneBy(['email' => $email]);
$request->getSession()->set(
Security::LAST_USERNAME,
$email
);
$request->getSession()->set(
AppTwoFactorAuthenticator::USER_SESSION_KEY,
$email
);
if (!$user) {
throw new UsernameNotFoundException();
}
return new Passport($user, new PasswordCredentials($request->get('password')), [
// and CSRF protection using a "csrf_token" field
new CsrfTokenBadge('authenticate', $request->get('_csrf_token')),
// and add support for upgrading the password hash
new PasswordUpgradeBadge($request->get('password'), $this->userRepository),
new TwoFactorBadge(),
]);
}
}Voir la classe AppLoginAuthenticator complète.
Cet écouteur a une particularité, il doit être exécuté après la vérification du mot de passe. J’ai donc dû modifier la priorité de l’écouteur à -10, car par défaut, les écouteurs sont tous exécutés avant la vérification du mot de passe.
//...
public static function getSubscribedEvents()
{
return [
CheckPassportEvent::class => ['resolveBadge', -10]
];
}
//...Maintenant, si le mot de passe est correct, l’écouteur ajoutera la clé need_auth_two avec la valeur « vrai » dans la session sans résoudre le badge.
<?php
namespace AppSecurityListener;
final class TwoFactorBadgeSubscriber implements EventSubscriberInterface
{
public function resolveBadge(CheckPassportEvent $event)
{
/** @var Passport $passport */
$passport = $event->getPassport();
// Here I can check if the user has the two factor authentication enabled
if ($passport->hasBadge(TwoFactorBadge::class) && $passport->hasBadge(PasswordCredentials::class) && $passport->getBadge(PasswordCredentials::class)->isResolved()) {
$this->session->set('need_auth_two', true);
}
}
}Voir la classe TwoFactorBadgeSubscriber complète.
Après le passage du passeport dans tous les écouteurs, Symfony vérifiera si tous les badges sont résolus. Comme ce ne sera pas le cas, il redirigera l’utilisateur vers la page de login. C’est là que la méthode getLoginUrl de classe d’authentification AppLoginAuthenticator génèrera une URL pour la saisie du code de second facteur d’authentification.
La méthode getLoginUrl n’a pas été modifiée !
<?php
namespace AppSecurity;
final class AppLoginAuthenticator extends AbstractLoginFormAuthenticator
{
//...
protected function getLoginUrl(Request $request): string
{
if ($this->session->get('need_auth_two', false) === true) {
return $this->urlGenerator->generate(AppTwoFactorAuthenticator::LOGIN_ROUTE);
}
return $this->urlGenerator->generate(self::LOGIN_ROUTE);
}
//...
}Comment est vérifié le second facteur ?
Comme avec Guard la page de saisie du code de second facteur est différente de celle de la connexion avec le mot de passe. Il y a donc deux classes d’authentification. J’ai également modifié la classe d’authentification AppTwoFactorAuthenticator.
<?php
namespace AppSecurity;
final class AppTwoFactorAuthenticator extends AbstractLoginFormAuthenticator
{
//...
public function authenticate(Request $request): PassportInterface
{
$email = $request->getSession()->get(self::USER_SESSION_KEY);
$user = $this->userRepository->findOneBy(['email' => $email]);
$request->getSession()->set(
Security::LAST_USERNAME,
$email
);
$request->getSession()->set(
AppTwoFactorAuthenticator::USER_SESSION_KEY,
$email
);
if (!$user) {
throw new UsernameNotFoundException();
}
return new Passport($user, new TwoFactorCredentials($request->get('password')), [
// and CSRF protection using a "csrf_token" field
new CsrfTokenBadge('authenticate', $request->get('_csrf_token')),
new TwoFactorTimeoutBadge(),
new TwoFactorMaxAttemptBadge(),
]);
}
}Cette classe d’authentification appliquait les règles suivantes en plus de la vérification du code :
- L’utilisateur n’a que 3 essais.
- L’utilisateur à un temps limité pour saisir le bon code.
Pour chacune de ces règles, j’ai ajouté un badge spécifique au passeport que génère la classe d’authentification. Bien sûr, j’ai également écrit l’écouteur qui correspond et qui marque le badge comme résolu si les conditions sont remplies (TwoFactorMaxAttemptBadgeSubscriber et TwoFactorTimeoutBadgeSubscriber).
Pour la partie vérification du code en lui-même, j’ai ajouté une classe TwoFactorCredentials qui permettra la vérification. Cette classe sera donc utilisée en second argument du constructeur du passeport et contiendra le code saisi par l’utilisateur.
J’ai ajouté une nouvelle classe, car ce n’est pas un mot de passe en tant que tel et je ne souhaite pas que l’écouteur fourni par Symfony se déclenche.
En suite, j’ai écrit l’écouteur pour réaliser la vérification du code.
<?php
namespace AppSecurityListener;
final class TwoFactorCredentialSubscriber implements EventSubscriberInterface
{
//...
public function checkCredential(CheckPassportEvent $event)
{
/** @var Passport $passport */
$passport = $event->getPassport();
if ($passport->hasBadge(TwoFactorCredentials::class) === false) {
return;
}
$badge = $passport->getBadge(TwoFactorCredentials::class);
if ($badge->getPassword() === $this->session->get(AppTwoFactorAuthenticator::CODE_SESSION_KEY, null)) {
$badge->markResolved();
return;
}
$this->session->set(AppTwoFactorAuthenticator::COUNT_SESSION_KEY,
$this->session->get(AppTwoFactorAuthenticator::COUNT_SESSION_KEY, 0) + 1);
}
}Fichier complet src/Security/Listener/TwoFactorCredentialSubscriber.php
Quelles sont les modifications apportées dans la configuration ?
Étant donné que les classes d’authentification ne sont plus liées à Guard, il a été nécessaire de modifier la configuration.
Ainsi, les ID de service enregistré pour le firewall main dans la clé guard.authenticators ont été déplacés dans la clé custom_authenticators. Étant donné que j’ai deux classes d’authentification, il est obligatoire de désigner le point d’entrée avec la clé entry_point à la place de guard.entry_point.
#...
firewalls:
dev:
pattern: ^/(_(profiler|wdt)|css|images|js)/
security: false
main:
provider: db
entry_point: AppSecurityAppLoginAuthenticator
custom_authenticators:
- AppSecurityAppLoginAuthenticator
- AppSecurityAppTwoFactorAuthenticator
logout:
path: app_logout
#...Voir le fichier config/packages/security.yaml complet.
En conclusion, quels sont les avantages d’un tel système ?
Le premier avantage que je constate est la possibilité de réutiliser un badge et son écouteur sur plusieurs firewalls de l’application.
Le second est le fort découpage des responsabilités, ainsi qu’une grande facilité d’extension du système.
Enfin le dernier avantage est de pouvoir proposer plus facilement des bundles Symfony permettant d’étendre et mutualiser les badges et leur écouteur.
