JAX-WS webservice et @rolesAllowed

Est-il possible d'utiliser @RolesAllowed annotation sur un JAX-WS webservice et si oui, comment?

J'ai un webservice sur glassfish 3.1.1 l'aide de l'Authentification de Base, mais des restrictions exprimées à l'aide d' @RolesAllowed sont ignorés. Le rôle de l'information doit être disponible, je peux y accéder comme ceci:

@Resource
WebServiceContext wsContext;

if (wsContext.isUserInRole("READ"))
log.info("Role: READ");

- Je obtenir le rôle attendu, mais encore toutes les méthodes sont accessibles, même si @RolesAllowed est fixé à un rôle différent. @DenyAll ne fonctionne pas aussi bien.

Si ces annotations ne sont pas pris en charge, est-il possible d'utiliser des descripteurs de déploiement de gérer l'accès à webservice méthodes basées sur les rôles d'utilisateur?

Modifier:
Cette partie de JAVA EE 6 tutoriel décrit l'utilisation de @RolesAllowed annotation. Il lit

Pour les composants Java EE, vous définissez les rôles de sécurité à l'aide de @DeclareRoles et @RolesAllowed annotations de métadonnées.

Services Web ne sont pas répertoriés en tant que composants Java EE dans la première partie du tutoriel, de sorte qu'il ressemble à la sécurité des annotations ne sont pas pris en charge.

Edit2
Suivant Izan post, j'ai donné une autre chance. Voici ce que j'ai fait:

@Webservice
@DeclareRoles(value = {"READ", "UPDATE", "DELETE"})
public class ServiceImpl implements Service {
  @Override
  @WebMethod(operationName = "helloWorld")
  @RolesAllowed({"NONE"})
  public String helloWorld() throws Exception {
     return "Hello World!";
  }
}

À l'aide de ce type de configuration, tout le monde peut accéder à la méthode, peu importe ce que les rôles sont définis. Les utilisateurs sont authentifiés (pouvez voir que dans la vérification.journal), mais aucune autorisation n'a lieu. Comme indiqué ci-dessus, je peux accéder au rôle de WebServiceContext (en fait, je ne manuel autorisation à l'aide de cette info).

Ajoutant @Stateless annotation, laissez-moi utiliser la sécurité des annotations. Donc @permitAll fonctionne comme prévu. Mais à l'aide de rôles ne fonctionne toujours pas, tant que l'utilisateur n'obtenez pas authentifié maintenant. Ils apparaissent comme des ANONYMOUS dans le journal d'audit et l'accès est refusé.

Mon web.xml ressemble à ceci:

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" version="3.0">
<display-name>OneMore</display-name>
<security-constraint>  
<display-name>WebServiceSecurity</display-name>  
<web-resource-collection>  
<web-resource-name>Authorized users only</web-resource-name>  
<url-pattern>/service</url-pattern>  
<http-method>POST</http-method>
</web-resource-collection>  
<auth-constraint>       
<role-name>READ</role-name>
<role-name>UPDATE</role-name>
<role-name>DELETE</role-name>
</auth-constraint>  
</security-constraint>  
<login-config>
<auth-method>BASIC</auth-method>
</login-config>
<security-role>
<role-name>READ</role-name>
</security-role>
<security-role>
<role-name>UPDATE</role-name>
</security-role>
<security-role>
<role-name>DELETE</role-name>
</security-role>
</web-app>

Glassfish-web.xml juste des cartes rôle de noms de noms de groupe, comme ceci:

<security-role-mapping>
<role-name>READ</role-name>
<group-name>READ</group-name>
</security-role-mapping>

Modifier 3
Grâce à Izan et d'innombrables essais plus tard, j'ai enfin réussi à le faire fonctionner.

Comme dit avant, le point principal était de commutation à partir d'un simple service web un service web EJB par l'ajout de @Stateless annotation. Cela permet d'utiliser la sécurité des annotations.

Ce changement nécessaire pour modifier les descripteurs de déploiement ainsi. Alors que l'original web service exigé d'un glassfish-web.xml pour définir les rôles, un glassfish-ejb-jar.xml est nécessaire par la suite.

InformationsquelleAutor TPete | 2012-01-31