BT

Spring Security 3.1: Multiple http, Stateless, Debug, Crypto, HttpOnly, Paramètres Form-login person

par Bienvenido David , traduit par Slim Ouertani le 01 sept. 2013 |

SpringSource vient de publier Spring Security 3.1.0. La dernière version majeure de Spring Security était la version 3.0.0 publiée le 23 décembre 2009, avec des versions de maintenance jusqu'à 3.0.7. Ci-dessous les nouveautés de Spring Security 3.1.

  • Multiples éléments http

Désormais, il est possible de créer plusieurs éléments HTTP pour définir des configurations alternatives de la chaîne de filtrage de sécurité pour les différents modèles (pattern) de requête. L'élément http correspondra à tous les modèles de requête si l'attribut pattern n'est pas spécifié. L’utilisation de l'attribut request-matcher au lieu de l'attribut pattern est toujours supporté. Le cas d'utilisation principal consiste à supporter les URL avec ou sans état dans une même application, i.e. spécifier une configuration différente de sécurité pour l'application Web et les services REST qu’elle expose. Il est également possible de contourner complètement le filtre de sécurité en mettant l'attribut de sécurité à none.

  <http pattern="/resources/**" security="none" />

  <http>
                ...
  </http>

Si l'on spécifie l'option create-session="stateless", Spring ne créera pas de session. Ce qui diffère de l'existant avec create-session="never". Il pourra aussi utiliser une session existante si l'application l’a déjà créée.

  <http create-session="stateless">

Permet d’activer le support de déboguage. Il affiche actuellement la correspondance des requêtes avec les chaînes de filtres et la création de nouvelles sessions. Notez que les informations affichées peuvent inclure des données sensibles et ne doivent être utilisées qu’au sein d’un environnement de développement.

  <http>
              ...
  </http>

  <debug/>

Active Directory est largement utilisé et se distingue du standard LDAP. C’est pour cette raison qu’ ActiveDirectoryLdapAuthenticationProvider a été créé pour une meilleure prise en charge d’Active Directory.

Le module Crypto de Spring Security fournit un support pour le chiffrement symétrique, la génération de clés et l’encodage de mot de passe. Les principales classes ajoutées sont Encryptors, KeyGenerators et PasswordEncoder.

  • HttpOnly pour Servlet 3.0

Le support du flag HttpOnly des cookies dans les environnements Servlet 3.0 est rajouté. Si le flag HttpOnly est inclus dans l'en-tête de réponse HTTP, le cookie ne peut pas être accessible par un script client tel que JavaScript. Ceci permet d'éviter le scripting inter-site (cross site scripting ou XSS). Notez que le serveur et le navigateur auront besoin de supporter le flag HttpOnly pour que cela fonctionne correctement.

Il est recommandé que les cookies “remember-me” soient marqués comme “secure” et donc soumis uniquement via HTTPS. Par défaut, le cookie sera sécurisé si la requête est sécurisée.

  <http>
              ...
              <remember-me key="..." use-secure-cookie="true" />
  </http>

InMemoryUserDetailsManager fournit une implémentation non persistante de UserDetailsManager, qui est basée sur une map en mémoire. Ce manager est principalement destiné au développement et aux tests, où la persistance n'est pas nécessaire.

  • hasPermission dans la balise authorize

Ajout du support pour l'expression hasPermission sur la balise JSP authorize.

  <sec:authorize access="hasPermission(#var, 'permission')">
  • Désactiver la sécurité pour l'UI

Il est désormais possible d’afficher les éléments de l'interface utilisateur qui sont normalement masqués par l'utilisation de la balise authorize. Cela permet de tester facilement si les URL sont effectivement sécurisées coté serveur. Si la propriété système spring.security.disableUISecurity est à true, le contenu sera toujours affiché. Ces zones "cachées" seront entourées par la balise <span class="securityHiddenUI"> afin d’être différenciées via CSS.

Si l'attribut erase-credentials est à true, l’AuthenticationManager tentera d'effacer toutes les données d'identification de l'objet Authentication résultat, une fois l'utilisateur authentifié. Cet attribut correspond à la propriété eraseCredentialsAfterAuthentication de ProviderManager. C'est le comportement par défaut dans Spring Security 3.1.

  <http>
        ...
  </http>

  <authentication-manager erase-credentials="true">
              ...
  </authentication-manager>

Ajout du support pour la suppression des cookies à la déconnexion. L'attribut delete-cookies accepte une liste de noms de cookies séparés par des virgules qui seront supprimés par Spring Security lorsque l'utilisateur se déconnecte.

<http>
        ...
        <logout delete-cookies="cookieName1, cookieName2, ..." />
</http>
  • CAS Proxy Tickets

Ajout du support pour CAS (Central Authentication Service) des tickets proxy. Désormais, Spring Security prend en charge la convention CAS proxy basé sur le paramètre de requête "ticket".

  • JAAS Injection de configuration

Ajout du support pour les différentes configurations d’implémentation de JAAS (Java Authentication and Authorization Service). Désormais, ce support de JAAS peut être configuré seulement en utilisant la configuration de Spring sans avoir à étendre de classes particulières.

  • Empêcher les Switchs imbriqués

SwitchUserFilter est le filtre de traitement responsable de l’aiguillage du contexte utilisateur ; il ne permet plus de switchs imbriqués. La méthode attemptExitUser est désormais appelée avant chaque switch.

Vu qu’il est désormais possible d'avoir plusieurs chaînes de filtrage de sécurité, il est aussi possible de leur associer une référence d'AuthenticationManager.

    <global-method-security authentication-manager-ref="...">

    <http authentication-manager-ref="...">

    <authentication-manager alias="...">

L'élément http possède désormais l'attribut name qui peut être utilisé pour faire référence au bean partout dans le contexte.

    <http name="">
            ...
    </http>

L'attribut request-matcher-ref pointe vers le bean qui implémente l'interface RequestMatcher qui va déterminer si cette chaîne de filtres devrait être utilisée. C'est une alternative plus puissante que http@pattern où il est possible d’utiliser ELRequestMatcher ou IpAddressMatcher, ou même de développer son propre RequestMatcher.

    <http request-matcher-ref="...">
            ...
    </http>
  • AuthenticationDetailsSource Namespace

Ajout du support pour manipuler l’AuthenticationDetailsSource en utilisant le namespace qui sera utilisé par le filtre d'authentification. AuthenticationDetailsSource fournit un objet Authentication.getDetails () pour une requête donnée. Voir form-login@authentication-details-source-ref, openid-login@authentication-details-source-ref, http-basic@authentication-details-source-ref et x509@authentication-details-source-ref.

Ajout du support http/expression-handler pour le contrôle d'accès basé sur des expressions personnalisées. Il définit une référence à un bean Spring qui implémente SecurityExpressionHandler, lui-même utilisé si l'expression basée sur le contrôle d'accès est activée. Par défaut, une implémentation sans le support des ACL sera utilisée.

  <global-method-security expression-handler="...">

  <http expression-handler="...">

Il définit AuthenticationEntryPoint pour BasicAuthenticationFilter. Ce dernier traite les en-têtes d'autorisation BASIC de la requête et met le résultat dans la SecurityContextHolder.

    <http>
            ...
            <http-basic entry-point-ref="..." />
    </http>

L'attribut authentication-success-handler-ref définit la propriété authenticationSuccessHandler du RememberMeAuthenticationFilter si la navigation personnalisée est requise. La valeur doit être le nom du bean AuthenticationSuccessHandler utilisé pour traiter une authentification réussie de l'utilisateur. Le cas d'utilisation le plus courant est de contrôler la navigation vers la prochaine destination en utilisant redirect ou forward.

  <http>
            ...
            <remember-me key="..." authentication-success-handler-ref="..." />
  </http>

L’élément method-security-metadata-source crée une instance de MethodSecurityMetadataSource, une implémentation de SecurityMetadataSource qui est conçue pour effectuer des recherches définies par des méthodes. Par défaut, l’instance fournie de MethodSecurityMetadataSource sera prioritaire sur les autres sources comme les annotations. L'attribut use-expressions permet l'utilisation des expressions dans les attributs “access” des éléments.

  <global-method-security metadata-source-ref="id">

  <http>
            ...
  </http>

  <method-security-metadata-source id="id" use-expressions="..." />

L'attribut mode peut être défini pour spécifier qu’AspectJ doit être utilisé au lieu de Spring AOP par défaut.

  <global-method-security mode="aspectj"> 

L'élément attribute-exchange définit la liste des attributs à récupérer auprès d’OpenID. Plusieurs éléments attribute-exchange peuvent être définis, dans ce cas, chacun doit avoir un attribut identifier-match relié à l'identifiant OpenID. Cela permet de faire correspondre des listes d'attributs différentes en fonction du fournisseur d'identité.

    <http>
            ...
            <openid-login>
                    <attribute-exchange>
                            <openid-attribute name="..." type="..." />
                    </attribute-exchange>
            </openid-login>
    </http>

Si elle est disponible, elle exécute la requête en tant que Subject obtenu par JaasAuthenticationToken qui est implémenté par l'ajout d'un bean JaasApiIntegrationFilter. Par défaut, ce n'est pas le cas.

  <http jaas-api-provision="...">
            ...
  </http>

Désormais, il est possible de spécifier les paramètres de la requête de l'élément form-login. L'attribut username-parameter spécifie le paramètre de la requête qui contient le nom d'utilisateur, qui est "j_username" par défaut. L'attribut password-parameter spécifie le paramètre de la requête qui contient le mot de passe, par défaut "j_password".

  <http>
            <form-login username-parameter="..." password-parameter="..." />
  </http>

Vous pouvez dès à présent démarrer en téléchargeant cette version à partir de Spring Community Downloads. Pour les utilisateurs de Maven, utilisez le groupId org.springframework.security, l’artifactId spring-security-* et la dependency version 3.1.0. N'oubliez pas d'utiliser le nouveau schéma de Spring Security, http://www.springframework.org/schema/security/spring-security-3.1.xsd dans vos XML Spring Security afin de profiter des améliorations du namespace.

Pour plus d'informations, regardez la documentation de référence Spring Security 3.1. Vous pouvez cloner le code source à partir des dépôts Git de Spring, disponible sur git://git.springsource.org/spring-security/spring-security.git.

Bonjour étranger!

Vous devez créer un compte InfoQ ou cliquez sur pour déposer des commentaires. Mais il y a bien d'autres avantages à s'enregistrer.

Tirez le meilleur d'InfoQ

Donnez-nous votre avis

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet
Commentaires de la Communauté

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet

Discuter

Contenu Éducatif

Rien ne serait possible sans le soutien et la confiance de nos Sponsors Fondateurs:

AppDynamics   CloudBees   Microsoft   Zenika
Feedback Général
Bugs
Publicité
Éditorial
InfoQ.com et tous les contenus sont copyright © 2006-2014 C4Media Inc. InfoQ.com est hébergé chez Contegix, le meilleur ISP avec lequel nous ayons travaillé.
Politique de confidentialité
BT