sécurité du maillot et gestion des sessions

Question

Existe-t-il un moyen de gestion de session ou de sécurité disponible par programmation dans les spécifications de Jersey?

par exemple, comme une gestion de session d'application Web.

Ou bien transaction, session, sécurité sont-elles gérées par le conteneur sur lequel l’application jersey est déployée?

Adhir

Answer 1

La gestion de session est la compétence du conteneur dans lequel Jersey est déployé. Dans la plupart des cas de production, il sera déployé dans un conteneur assurant la gestion de session.

Le code ci-dessous est un exemple simple de ressource jersey qui récupère l'objet de session, stocke les valeurs dans la session et les récupère lors d'appels ultérieurs.

 @Path("/helloworld")
public class HelloWorld {

    @GET
    @Produces("text/plain")
    public String hello(@Context HttpServletRequest req) {

    	HttpSession session= req.getSession(true);
    	Object foo = session.getAttribute("foo");
    	if (foo!=null) {
    		System.out.println(foo.toString());
    	} else {
    		foo = "bar";
    		session.setAttribute("foo", "bar");
    	}
    	return foo.toString();


    }
}
 

Answer 2

Je pensais que les sessions est quelque chose que nous devrions ne jamais utiliser dans Reposant applications...

Yegor est droit. Nous ne devrions pas nous ne jamais conserver l'état dans le côté serveur à la classique de l'application web. Si vous voulez construire une découplé SOA orientée applications dont vous n'avez pas besoin d'utiliser une API/framework pour les services web REST. Si vous avez besoin, ou envie, de maintenir les clients à l'échelle mondiale-l'état du serveur dans le serveur vous sont implicitement la construction de ce que nous pourrions décrire comme un SOA orientée [web]app, mais à l'aide de Jersey comme un [web] cadre de développement de toutes sortes. Par inadvertance, vous êtes à la torsion de la nature d'un web service REST (ou autre). Vous pouvez le faire dans la façon dont il a été suggéré dans la première réponse, mais vous ne devez pas. Le résultat final n'est pas un service web, juste une simple application construite avec des services web outils.

-_o

Answer 3

Oui c'est possible. Maillot de documentation dit:

La sécurité de l'information de demande est disponible par l'injection d'un JAX-RS SecurityContext exemple à l'aide de @Contexte de l'annotation. Le injecté contexte de sécurité de l'instance fournit l'équivalent de la fonctionnalité disponible sur HttpServletRequest API. L'injection de contexte de sécurité dépend de la réelle Jersey le déploiement de l'application. Par exemple, pour un Maillot de l'application déployée dans un conteneur de Servlet, le Maillot SecurityContext va encapsuler les informations à partir d'un contexte de sécurité extrait de la Servlet demande. Dans le cas d'un Maillot de l'application déployé sur un Grizzly serveur, le SecurityContext sera de retour les informations récupérées dans le Grizzly demande.

Exemple:

@Path("basket")
public ShoppingBasketResource get(@Context SecurityContext sc) {
    if (sc.isUserInRole("PreferredCustomer") {
        return new PreferredCustomerShoppingBasketResource();
    } else {
        return new ShoppingBasketResource();
    }
}

ou

@Path("resource")
@Singleton
public static class MyResource {
    // Jersey will inject proxy of Security Context
    @Context
    SecurityContext securityContext;

    @GET
    public String getUserPrincipal() {
        return securityContext.getUserPrincipal().getName();
    }
}

Ou si vous voulez de la sécurité hors de la boîte avec les annotations de ces docs.

Maillot vous permet également de personnaliser la SecurityContext:

Le SecurityContext peuvent être récupérés directement à partir de ContainerRequestContext via getSecurityContext() la méthode. Vous pouvez également remplacez la valeur par défaut SecurityContext dans un contexte de demande avec un custom à l'aide de la setSecurityContext(SecurityContext) de la méthode. Si vous définissez un personnalisé SecurityContext instance dans votre ContainerRequestFilter, ce contexte de sécurité de l'instance va être utilisée pour l'injection dans JAX-RS ressources champs de la classe. De cette façon, vous pouvez mettre en œuvre une coutume filtre d'authentification qui peuvent d'installation de votre propre SecurityContext être utilisé. Pour assurer l'exécution rapide de votre authentification personnalisée filtre de requête, définir le filtre de priorité pour l'AUTHENTIFICATION à l'aide les constantes de Priorités. Une exécution rapide de vous d'authentification filtre veillera à ce que tous les autres filtres, des ressources, des ressources méthodes et sous-localisateurs de ressources va exécuter avec votre personnalisé SecurityContext instance.

Voir des exemples sur la façon de demande d'utilisation des filtres avec Jersey. Et vérifier mon exemple suivant:

import javax.annotation.Priority;
import javax.ws.rs.Priorities;

@Provider
@Priority(Priorities.AUTHENTICATION)
public class AuthRequestFilter implements ContainerRequestFilter {
    @Context
    HttpServletRequest webRequest;

    @Override
    public void filter(ContainerRequestContext requestContext) throws IOException {
        final HttpSession session = webRequest.getSession();

        requestContext.setSecurityContext(new SecurityContext() {
            @Override
            public Principal getUserPrincipal() {
                return new PrincipalImpl((String)session.getAttribute("USER_NAME"));
            }

            @Override
            public boolean isUserInRole(String s) {
                return false;
            }

            @Override
            public boolean isSecure() {
                return false;
            }

            @Override
            public String getAuthenticationScheme() {
                return null;
            }
        });
    }
}

Avertissement! Cela a été introduit en Jersey 2.4. Glassfish 4.0.0 utilise l'ancien Maillot 2.0, par conséquent, vous devrez mettre à niveau Jersey à l'aide de ces conseils (il n'est pas prouvé à travailler très bien). Ou la meilleure façon est de télécharger les nightly build de Glassfish 4.0.1. mais il n'est pas complètement stable pour le moment. J'espère que la nouvelle version sera bientôt disponible.

Mise à JOUR: À l'heure actuelle (2014-02-14) Glassfish 4.0.1 nightly build utilise Jersey 2.5.1 et le contexte de l'injection fonctionne très bien.

Answer 4

La réponse de Jack sur les sessions est correct. Elles sont spécifiques au conteneur que vous exécutez dans, bien que la Servlet spec au moins vous donne la portabilité entre JavaEE conteneurs.

Comme pour la sécurité, vous avez au moins la possibilité de le séparer de votre JAX-RS code spécifique en utilisant JaaS (Java Authentication and Authorization Service) et un filtre de servlet. Le filtre peut être utilisé pour appliquer l'authentification HTTP et, sur la réussite de l'authentification, de l'installation de la JaaS Sujet avec le cas échéant des Directeurs d'école. Votre JAX-RS ressources pouvez vérifier pour les Directeurs d'école sur le Sujet. Comme vous contrôlez l'ensemble de la pile, vous devriez être en mesure de s'appuyer sur un utilisateur authentifié dans vos ressources (mais faire ce test!), et vous pouvez appliquer des autorisations basées sur l'opération en cours dans la ressource de code.

Answer 5

J'ai résolu ce problème en demandant aux clients d'ajouter l'en-tête Authorization et de le tester dans la méthode REST comme suit:

 @GET
@PRODUCES(MediaType.APPLICATION_JSON)
public String returnClients(@Context HTTPServletRequest request(
    String auth = request.getHeader("Authorization");
    Account acc = null;
    if (auth!=null) {
       Account acc = Utils.LoginAccount(auth);
    }
    if (acc == null)
     // not logged in, handle it gracefully
 

De cette façon, il y a authentification sans démarrer une session.