Utilisation de JaaS avec Jersey sur Grizzly

Question

J'essaie de trouver un moyen simple et flexible d'ajouter l'authentification JaaS à REST. J'ai trouvé un post qui, selon moi, me mène dans la bonne direction (voir la réponse de StevenC). Il semble que le conteneur de servlet soit responsable de la sécurité, pas le code de Jersey lui-même. J'aime cette idée, mais j'ai besoin de quelques conseils sur la mise en œuvre. Grizzly est mon conteneur de servlet et je veux le configurer pour utiliser JaaS pour l'authentification. Pour l'instant, une combinaison simple nom d'utilisateur/mot de passe serait bien, et coder en dur les paires nom d'utilisateur/mot de passe directement dans le code est très bien. Tant qu'il utilise JaaS, nous pouvons affiner ces détails plus tard.

En ce qui concerne ce qui est envoyé via HTTP, je pense que stocker un cookie serait le moyen le plus facile de faire fonctionner tout cela. Tout ce qu'il faut pour garder les déchets d'authentification loin de mon code de Jersey.

Voici le code pour commencer Grizzly jusqu'à présent:

final String baseUri = "http://localhost:9998/"; 
final Map initParams = new HashMap(); 

initParams.put("com.sun.jersey.config.property.packages", 
    "my.jersey.Service"); 

System.out.println("Starting grizzly..."); 
SelectorThread threadSelector = GrizzlyWebContainerFactory.create(baseUri, initParams); 
System.out.println(String.format(
     "Jersey app started with WADL available at %sapplication.wadl\n" 
    + "Try out %shelloworld\nHit enter to stop it...", baseUri, baseUri));     
System.in.read(); 
threadSelector.stopEndpoint(); 
System.exit(0); 

Si ce processus fonctionne, quelle est la meilleure façon de vérifier les autorisations pour l'utilisateur? Je voudrais probablement que mon code REST valide réellement les autorisations à certains points. Suis-je même sur la bonne voie? Y a-t-il un moyen plus facile? Un lien vers un tutoriel serait une excellente réponse. Même une réponse comme «Je l'ai fait et ça a marché» me donnerait un vague sentiment que je suis dans la bonne direction.

Merci pour toute aide.

EDIT: Quelques précisions pour le commentaire de StevenC:

• Voulez-vous encore utiliser des filtres de servlet pour protéger vos ressources? Je vais utiliser tout ce qui peut séparer les détails d'authentification du code de Jersey. Ce ne doit pas être des filtres de servlet. Que veut dire «configurer pour utiliser JaaS»? Le plan original était de protéger l'API actuelle en utilisant JaaS. La prochaine étape consistera à rendre l'ensemble de l'API disponible en ligne. Il semblait logique d'avoir un wrapper de Jersey autour des appels d'API, mais de garder l'authentification gérée par Grizzly. Grizzly devrait interagir avec JaaS à ce moment-là je crois.
• Pensez-vous qu'il devrait y avoir une certaine config qui cause simplement grizzly pour protéger vos ressources? Je considérais un processus en deux étapes d'authentification de l'utilisateur et basé sur les rôles, autorisant l'utilisateur à accéder aux ressources. L'idée était d'avoir l'authentification Grizzly handle (en utilisant JaaS) et Jersey gérer l'autorisation.
• "Je ne vois pas le besoin d'utiliser des cookies avec une ressource RESTful." Ce serait merveilleux d'enlever l'utilisation de cookies, mais comment peut-on l'accomplir? Le système doit savoir si l'utilisateur est authentifié. Je préfère ne pas leur demander de passer un nom d'utilisateur/mot de passe/etc pour chaque appel. Même passer un jeton de session comme paramètre à chaque appel semble "moche".

En outre, s'il vous plaît noter que je suis assez nouveau à REST. Je fais du SOAP depuis quelques années, donc j'ai peut-être un «biais SOAP» qui peut m'empêcher de trouver une solution simple et évidente que tout le monde utilise. S'il y a un moyen plus facile, n'hésitez pas à partager. J'essaie juste d'apprendre autant que possible.

Answer 1

Vous ne savez pas si vous demandez comment sécuriser chaque ressource, mais j'ai trouvé une présentation sur javapassion qui ressemble à ce que vous cherchez. Il dit d'utiliser @Context SecurityContext en tant que paramètre.

@Path("basket") 
    // Sub-resource locator could return a different resource if a user 
    // is a preferred customer: 
    public ShoppingBasketResource get(@Context SecurityContext sc) { 
    if (sc.isUserInRole("PreferredCustomer") { 
     return new PreferredCustomerShoppingBaskestResource(); 
    } else { 
     return new ShoppingBasketResource(); 
    } 
} 

Answer 2

Je ne comprends pas très bien ce que l'on entend par «configurer pour utiliser JaaS pour l'authentification». S'il y a une configuration simple pour que l'authentification HTTP de grizzly soit utilisée pour protéger les URL, je ne suis pas au courant.

Je suppose de l'autre question et vous répondez que vous voulez utiliser un filtre de servlet. Normalement, cela est configuré dans le fichier web.xml d'un projet de servlet. Grizzly est bien sûr souvent utilisé pour démarrer un serveur à partir du code par opposition à la configuration de l'application. Lorsque j'ai utilisé Grizzly de cette façon, j'ai remarqué que GrizzlyWebContainerFactory n'offrait aucune version de create() qui vous permettait de spécifier des filtres de servlet. Cependant, j'ai remarqué ServletAdapter [1] dans le même projet qui vous donne cette capacité. En ce qui concerne le filtre lui-même, je ne connais malheureusement pas de filtre de servlet préconstruit qui branche simplement les modules de connexion configurés par JaaS dans votre application, vous devrez probablement y écrire un peu de code. Ce n'est pas grand chose, choisissez simplement la méthode d'authentification basée sur HTTP (par exemple HTTP BASIC, DIGEST, etc.), extrayez les informations d'identification de la requête en conséquence, et connectez-vous en utilisant le framework JaaS. Je ne vois pas qu'un cookie serait spécifiquement nécessaire pour les ressources RESTful. Le style architectural RESTful fronce les sourcils en gardant des sessions. Il y a beaucoup de tutoriels sur JaaS dans le cas contraire, donc je ne vais pas m'étendre là-dessus.

Une fois qu'un sujet JaaS est actif (client connecté avec succès), vous pouvez simplement obtenir le sujet actuel et vérifier les principaux et les informations d'identification en utilisant la méthode Subject.getSubject.

Quoi qu'il en soit, cette réponse est spécifiquement destinée à donner un peu plus de détails sur la manière de faire auth avec les filtres de servlet, comme vous l'avez demandé dans l'autre question (liée). Ce n'est pas nécessairement la seule façon de faire auth dans un webapp jersey, mais c'est une façon assez simple de le faire. Je l'aime parce que cela m'empêche d'injecter du code d'authentification répétitif dans chaque ressource qui en a besoin.

[1] https://grizzly.dev.java.net/nonav/apidocs/com/sun/grizzly/http/servlet/ServletAdapter.html