Question

J'utilise Wicket avec le projet Wicket Auth pour ma couche de présentation et je l'ai donc intégré à Spring Sécurité. C'est la méthode appelée par Wicket pour l'authentification pour moi:

@Override
public boolean authenticate(String username, String password) {
    try {
        Authentication request = new UsernamePasswordAuthenticationToken(
                username, password);
        Authentication result = authenticationManager.authenticate(request);
        SecurityContextHolder.getContext().setAuthentication(result);
    } catch (AuthenticationException e) {
        return false;
    }
    return true;
}

Le contenu (à l'intérieur) de ma configuration XML Spring Security est:

<http path-type="regex">
    <form-login login-page="/signin"/>
<logout logout-url="/logout" />
</http>
<global-method-security secured-annotations="enabled" />
<authentication-manager alias="authenticationManager"/>
<authentication-provider user-service-ref="userService">
    <password-encoder ref="bcryptpasswordencoder" />
</authentication-provider>

La section 2.3.6. La protection contre les attaques par fixation de session de la documentation de référence indique:

  

Les attaques par fixation de session constituent un risque potentiel lorsque cela est possible.   pour un attaquant malveillant de créer un   session en accédant à un site, puis   persuader un autre utilisateur de se connecter avec   même session (en leur envoyant un   lien contenant l'identifiant de session   en tant que paramètre, par exemple). Printemps   La sécurité protège contre cela   automatiquement en créant un nouveau   session lorsqu'un utilisateur se connecte. Si vous   ne nécessite pas cette protection, ou   en conflit avec une autre exigence,   vous pouvez contrôler le comportement en utilisant   la session-fixation-protection   attribut sur, qui a trois   options:

     
      
  • migrateSession - crée une nouvelle session et copie le fichier existant   attributs de session pour la nouvelle session. C'est la valeur par défaut.
  •   
  • aucun - Ne faites rien. La session originale sera conservée.
  •   
  • newSession - Crée un nouveau " clean " session, sans copier le   données de session existantes.
  •   

L’authentification fonctionne, mais comme je suis relativement nouveau dans Spring Security, j’ai quelques questions auxquelles il me faut aussi des réponses:

  • Normalement, pour la connexion, je POSTERais les informations d'authentification à j_spring_security_check et laisserais Spring Security exécuter le code d'authentification réel. Je souhaite bénéficier d'une protection contre les attaques par fixation de session. Est-ce que je l'obtenir lorsque j'effectue un login programmatique comme je le fais? Et si non, que devrais-je faire pour l'obtenir?
  • Comment puis-je effectuer une déconnexion par programme?
  • Comme je vais utiliser la connexion et la déconnexion par programme, comment puis-je empêcher Spring d'intercepter ces URL?

Mise à jour: Pour la protection contre les attaques par fixation de session, il me semble nécessaire d'appeler la méthode de la classe SessionUtils avec la signature startNewSessionIfRequired (demande HttpServletRequest, boolean migrateAttributes, SessionRegistry sessionRegistry) . . . .

Comment obtenir l'instance SessionRegistry que je dois transmettre? Je ne trouve aucun moyen de créer un identifiant d'alias pour celui-ci, ni comment l'obtenir ou son nom.

Était-ce utile?

La solution

Peut-être que ce n'est pas une réponse complète à vos questions, mais peut-être que cela pourrait vous aider.

Le code appelé lorsque vous n'utilisez PAS le login par programme, mais vous trouverez un code standard ici:

org.springframework.security.ui.webapp.AuthenticationProcessingFilter

Je suppose que cela vous a inspiré dans votre code. Il semble assez similaire.

De même, le code exécuté lorsque vous accédez au / j_spring_security_logout dans l’approche standard, se trouve ici:

org.springframework.security.ui.logout.LogoutFilter

LogoutFilter appelle plusieurs gestionnaires. Le gestionnaire que nous utilisons s'appelle: org.springframework.security.ui.logout.SecurityContextLogoutHandler , afin que vous puissiez appeler le même code dans votre approche.

Autres conseils

Vous serez en effet ouvert aux attaques par fixations de session. Pour remédier à cela, vous pouvez à nouveau être "inspiré". par le code de printemps. Pour créer une nouvelle session, vous devez évidemment avoir accès à la httpsession et vous devrez peut-être procéder à une refactorisation.

Si vous voyez la méthode SessionUtils . startNewSessionIfRequired .

Ceci migrera l'authentification vers une nouvelle session. Vous pourrez peut-être appeler cette méthode directement ou simplement refactoriser un peu le code.

En ce qui concerne la déconnexion par programme, vous ne pouvez pas vous tromper en appelant simplement session.invalidate () lorsque vous devez déconnecter la personne. Cela fera tout ce qui est nécessaire du point de vue de la sécurité générale, mais gardez à l'esprit que vous devrez peut-être nettoyer certaines choses de la session. Si vous avez un ensemble très complexe de filtres, etc. et que vous devez vous assurer que l'utilisateur est déconnecté pour le reste de la demande, vous pouvez ajouter:

SecurityContextHolder.getContext().setAuthentication(null);

En ce qui concerne l'interception des URL, vous pouvez simplement leur attribuer une valeur inutilisée et les ignorer! Je ne sais pas si vous pouvez désactiver l'interception dans la configuration - si vous voulez vraiment la supprimer, jetez un coup d'œil à AuthenticationProcessingFilter - vous pouvez le personnaliser. Si vous faites cela, vous devrez configurer manuellement le code XML de sécurité printanière et ne pas utiliser les espaces de noms fournis. Ce n'est pas si difficile - regardez une documentation plus ancienne et vous verrez comment faire.

J'espère que ça aide!

1) Déconnexion par programme

  1. appelez HttpServletRequest.getSession (false) .invalidate
  2. appelez SecurityContextHolder.clearContext ()

2) Indiquez à Spring Security de NE PAS intercepter certaines URL. Cela dépend en quelque sorte de la configuration de l'espace url de votre application. Si toutes vos pages (à l'exception de / logIn et / logout) vivaient dans le contexte / myApp, procédez comme suit:

<http ....>
  <intercept-url pattern="/myApp/**" ..>
 ....
</http>

J'ai eu un problème avec la connexion par programme. J'ai appelé toutes les méthodes authenticationManager.authenticate (...) et SecurityContextHolder.getContext (). SetAuthentication (...) , mais des problèmes se sont produits avec la session. J'ai dû ajouter les lignes suivantes pour gérer correctement la session:

HttpSession session = request.getSession();
session.setAttribute("SPRING_SECURITY_CONTEXT", SecurityContextHolder.getContext());

Cela ne ressort pas de l'exemple de code posté ci-dessus. Pour plus d'informations, consultez http://forum.springsource.org/showthread.php?t=69761

Pour vous déconnecter par programme, il est également possible de lancer une org.springframework.security.core.AuthenticationException . Par exemple, SessionAuthenticationException . Dans ce cas, ExceptionTranslationFilter initie la déconnexion.

Vous pouvez essayer ceci

    try {
        HttpSession session = request.getSession(false);
        if (session != null) {
            session.invalidate();
        }

        SecurityContextHolder.clearContext();

    } catch (Exception e) {
        logger.log(LogLevel.INFO, "Problem logging out.");
    }
Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top