Intégration de la sécurité Spring et de Waffle sur Tomcat avec des vérifications de rôle

Comme le titre l’indique, j’essaie d’intégrer Spring Security et Waffle sur Tomcat en utilisant des rôles. L’application sera déployée dans un environnement Windows où les utilisateurs auront déjà été authentifiés par domaine et que je souhaite exercer l’authentification unique. Pour aller plus loin, je souhaite vérifier les groupes auxquels appartient l’utilisateur authentifié et configurer les intercepteurs pour empêcher les utilisateurs qui ne sont pas membres du ou des groupes approuvés d’accéder à l’application Web.

Voici à quoi ressemble le contexte de l’application:

                                                               <!---->           <!---->

Et le web.xml

  springSecurityFilterChain org.springframework.web.filter.DelegatingFilterProxy   springSecurityFilterChain /*    contextConfigLocation /WEB-INF/appname-servlet.xml   log4jConfigLocation /WEB-INF/log4j.properties   org.springframework.web.util.Log4jConfigListener    defaultHtmlEscape true   org.springframework.web.context.ContextLoaderListener    appname org.springframework.web.servlet.DispatcherServlet  contextConfigLocation /WEB-INF/appname-servlet.xml     appname *.htm  <!--  java.lang.Exception /error.jsp  -->  /WEB-INF/views/appname_main.jsp   60  true

Ce qui se passe actuellement, c’est que toutes les tentatives pour atteindre l’application “appName” entraînent une demande d’authentification immédiate. En lisant sur Waffle, je ne peux que supposer qu’il s’agit d’une authentification de secours car elle n’a pas réussi à obtenir le jeton Windows et à authentifier l’utilisateur (soit par une tentative échouée, soit par des informations d’identification non valides).

Les tentatives précédentes ont inclus ne pas utiliser “hasRole” mais utiliser à la place

 access="IS_AUTHENTICATED_FULLY" />

Cela ne vérifierait pas le rôle de l’utilisateur, mais au moins limiterait l’access à l’application en fonction de l’authentification du domaine. Malheureusement, dans ce cas, il incite toujours l’utilisateur à chaque fois qu’il atteint l’application. Au moins, cette configuration permettait aux utilisateurs du domaine d’accéder à l’application, contrairement à l’approche «hasRole» qui a renvoyé un access refusé à chaque fois.

N’importe quelles idées seraient appréciées…

[EDIT: Ajouter des détails de nos journaux]

Il s’est avéré que je recevais des résultats faussement positifs lorsque je pensais que l’authentification unique fonctionnait avec “IS_AUTHENTICATED_FULLY”. Le navigateur mettait en cache les informations d’identification et les appliquait à la demande, de sorte que l’authentification unique ne fonctionnait jamais vraiment. Je suis invité à tout moment. ROLE_USER donne les mêmes résultats: invite et accepte les informations d’identification.

Étrangement, nous avons eu du mal à essayer de trouver des détails dans la gaufre. Nous avons ajouté les lignes suivantes au fichier conf logging.properties de Tomcat:

 waffle.servlet.NegotiateSecurityFilter.level = FINE waffle.servlet.spi.SecurityFilterProviderCollection.level = FINE waffle.servlet.spi.NegotiateSecurityFilterProvider.level = FINE waffle.servlet.spi.BasicSecurityFilterProvider.level = FINE

Cependant, localhost, catalina, etc. ne produisent aucun détail supplémentaire concernant la gaufre.

La seule information de journalisation que nous pouvions trouver liée aux rôles en jeu était la suivante:

 token:'org.springframework.security.authentication.AnonymousAuthenticationToken@905571d8: Principal: anonymousUser; Credentials: [PROTECTED]; Authenticated: true; Details: org.springframework.security.web.authentication.WebAuthenticationDetails@0: RemoteIpAddress: 10.10.90.70; SessionId: null; Granted Authorities: ROLE_ANONYMOUS'> 2013-02-21 11:25:10,527 DEBUG [org.springframework.security.web.FilterChainProxy] -  2013-02-21 11:25:10,528 DEBUG [org.springframework.security.web.FilterChainProxy] -  2013-02-21 11:25:10,528 DEBUG [org.springframework.security.web.FilterChainProxy] -  2013-02-21 11:25:10,529 DEBUG [org.springframework.security.web.access.intercept.FilterSecurityInterceptor] -  2013-02-21 11:25:10,529 DEBUG [org.springframework.security.web.access.intercept.FilterSecurityInterceptor] - <Previously Authenticated: org.springframework.security.authentication.AnonymousAuthenticationToken@905571d8: Principal: anonymous

De WFETCH nous avons capturé ceci:

 User; Credentials: [PROTECTED]; Authenticated: true; Details: org.springframework.security.web.authentication.WebAuthenticationDetails@0: RemoteIpAddress: 10.10.10.10; SessionId: null; Granted Authorities: ROLE_ANONYMOUS> http://10.10.10.10/ourappname/ Transfer-Encoding: chunked Date: Thu, 21 Feb 2013 16:29:42 GMT

[EDIT AGAIN] L’information d’en-tête de l’appel ayant échoué, comme demandé. Il est à noter que l’exemple de filtre Waffle fonctionne comme vous le souhaitez sans que l’utilisateur soit invité à utiliser localhost. Lorsque l’IP ou le domaine est utilisé, il vous invite. Je suppose que c’est un problème d’administration système / hôte de confiance?

 GET /ourappnameHTTP/1.1 Accept: text/html, application/xhtml+xml, */* Accept-Language: en-US User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0) Accept-Encoding: gzip, deflate Host: localhost:8080 Connection: Keep-Alive HTTP/1.1 302 Found Server: Apache-Coyote/1.1 Location: http://localhost:8080/ourappname/ Transfer-Encoding: chunked Date: Thu, 21 Feb 2013 20:15:51 GMT GET /ourappname/ HTTP/1.1 Accept: text/html, application/xhtml+xml, */* Accept-Language: en-US User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0) Accept-Encoding: gzip, deflate Host: localhost:8080 Connection: Keep-Alive HTTP/1.1 401 Unauthorized Server: Apache-Coyote/1.1 Set-Cookie: JSESSIONID=F2216F75CBA6AC8476189DA48A63A872; Domain=.domain.tld; Path=/something/; HttpOnly Connection: keep-alive WWW -Authenticate: Negotiate WWW-Authenticate: NTLM WWW-Authenticate: Basic realm="BasicSecurityFilterProvider" Transfer-Encoding: chunked Date: Thu, 21 Feb 2013 20:15:51 GMT GET /fismacm/ HTTP/1.1 Accept: text/html, application/xhtml+xml, */* Accept-Language: en-US User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0) Accept-Encoding: gzip, deflate Host: localhost:8080 Connection: Keep-Alive Authorization: Negotiate YHkGBisGAQUFAqBvMG2gMDAuBgorBgEEAYI3AgIKBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKKwYBBAGCNwICHqI5BDd OVExNU1NQAAEAAACXsgjiBAAEADMAAAALAAsAKAAAAAYBsR0AAAAPVzJLOFIyLURFVjFHT0xE HTTP/1.1 401 Unauthorized Server: Apache-Coyote/1.1 Set-Cookie: JSESSIONID=2CC0FDBF578629857113C6A72EE67FF5; Domain=.domain.tld; Path=/something/; HttpOnly Connection: keep-alive WWW-Authenticate: Negotiate WWW-Authenticate: NTLM WWW-Authenticate: Basic realm="BasicSecurityFilterProvider" Transfer-Encoding: chunked Date: Thu, 21 Feb 2013 20:15:51 GMT GET /favicon.ico HTTP/1.1 Accept: */* Accept-Encoding: gzip, deflate User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0) Host: localhost:8080 Connection: Keep-Alive HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Accept-Ranges: bytes ETag: W/"21630-1349272326000" Last-Modified: Wed, 03 Oct 2012 13:52:06 GMT Content-Type: image/x-icon Content-Length: 21630 Date: Thu, 21 Feb 2013 20:16:07 GMT

J’ai eu le même problème aujourd’hui.

Le problème s’est avéré être lié au nom de GrantedAuthority généré dans le contexte de sécurité Spring. Ce paramètre sera par défaut défini sur ROLE_ “domain” \ “role”, par exemple ROLE_MYDOMAIN \ MYROLE .

C’est le nom que vous devriez vérifier dans la vérification hasRole.

Consultez la documentation à l’ adresse suivante : https://github.com/Waffle/waffle/blob/master/Docs/spring/SpringSecurityAuthenticationProvider.md ,

Autorités concédées

Une fois la connexion établie, Waffle remplira l’object Authentification de Spring Security avec des instances de GrantedAuthority.

Par défaut, Waffle remplira l’object Authentication avec les éléments suivants:

Une GrantedAuthority avec la chaîne ROLE_USER. Un GrantedAuthority par groupe auquel appartient l’utilisateur. Les chaînes GrantedAuthority seront le nom de groupe en majuscule préfixé par ROLE_. Par exemple, si un utilisateur est membre du groupe Tout le monde, il obtient l’autorité ROLE_EVERYONE accordée. Le comportement par défaut peut être modifié en configurant un autre defaultGrantedAuthority et en atsortingbuantAuthorityFactory au waffleSpringAuthenticationProvider