Annotations de sécurité
Les annotations constituent un mécanisme puissant de programmation résultant de la recommandation JSR-175. Une annotation est une manière standard d'inclure des comportements de sécurité pris en charge tout en autorisant la génération automatique du code source et des fichiers de configuration.
Scénario | Règles |
---|---|
Métadonnées de sécurité dans un descripteur de déploiement uniquement | Aucune fusion n'est nécessaire, les métadonnées de sécurité du descripteur de déploiement sont propagées. |
Métadonnées de sécurité dans des annotations uniquement | Aucune fusion n'est nécessaire, les métadonnées de sécurité définies avec des annotations sont propagées. |
Métadonnées de sécurité dans un descripteur de déploiement et des annotations | Les métadonnées du descripteur de déploiement et des annotations sont fusionnées. Les métadonnées des annotations sont remplacées par le même type de données à partir du descripteur de déploiement. |
- @DeclareRoles (servlet 2.5 et supérieures, et EJB 3)
L'implémentation MergeAction trouve toutes les classes annotées avec l'annotation DeclareRoles. Dans chaque classe annotée pour chaque nom de rôle spécifié, si les rôles de sécurité répertoriés dans le descripteur de déploiement ne contiennent pas de SecurityRole avec le nom de rôle annoté, un nouveau SecurityRole est créé et ajouté à cette liste de rôles de sécurité.
- @RunAs (servlet 2.5 et supérieures, et EJB 3)
L'implémentation MergeAction trouve toutes les classes avec l'annotation RunAs. Pour chaque classe annotée, elle trouve le servlet ou l'EJB (Enterprise Java Bean) associé à la classe donnée. Elle détermine ensuite si un élément d'exécution est défini dans le descripteur de déploiement pour le servlet ou l'EJB. Si aucun élément d'exécution n'est trouvé, un nouvel élément est créé et ajouté au descripteur de déploiement. Si un élément d'exécution est trouvé, le système l'utilise plutôt que d'en créer un. Le nom de rôle utilisé dans l'annotation RunAs doit être défini dans le descripteur de déploiement.
- @DenyAll (EJB 3 uniquement)
L'implémentation MergeAction trouve toutes les méthodes annotées avec l'annotation DenyAll. Pour chaque méthode annotée, si elle n'est pas incluse dans la liste des méthodes exclues du descripteur de déploiement, et qu'aucune MethodPermission n'existe dans le descripteur de déploiement, un nouveau MethodElement est créé et ajouté à cette liste de méthodes exclues dans le descripteur de déploiement.
- @PermitAll (EJB 3 uniquement)
L'implémentation MergeAction trouve toutes les classes et méthodes annotées avec l'annotation PermitAll. Pour chaque classe annotée, elle trouve l'EJB (Enterprise Java Bean) associé à la classe donnée. Elle recherche ensuite le sous-ensemble de MethodElements dans la liste de toutes les MethodPermissions définies dans le descripteur de déploiement pour cet EJB. Si aucun MethodElement ayant un nom de méthode générique (“*”) n'est trouvé et qu'aucune méthode générique n'existe dans la liste des méthodes exclues ou dans celles des MethodElements avec des rôles de sécurité, une nouvelle MethodPermission et un nouveau MethodElement sont créés. La nouvelle MethodPermission est marquée comme non vérifiée et ajoutée à la liste MethodPermission dans le descripteur de déploiement. Le nouveau MethodElement est ajouté à la liste MethodElement de la nouvelle MethodPermission non vérifiée. Une action similaire est effectuée pour toutes les méthodes annotées. Au lieu d'un MethodElement générique, la signature de méthode doit correspondre exactement à la signature de la méthode annotée.
- @RolesAllowed (EJB 3 uniquement)
L'implémentation MergeAction trouve toutes les classes et méthodes avec l'annotation RolesAllowed. Pour chaque classe annotée, elle trouve l'EJB associé à la classe donnée. Elle trouve ensuite le sous-ensemble de MethodElements dans la liste de toutes les MethodPermissions définies dans le descripteur de déploiement pour cet EJB. Si aucun MethodElement ayant un nom de méthode générique (“*”) n'est trouvé et qu'aucune méthode générique n'existe dans la liste des méthodes exclues ou dans celles des MethodElements non vérifiées, une nouvelle MethodPermission et un nouveau MethodElement sont créés. Si une MethodPermission existe pour cet EJB avec exactement les mêmes rôles que ceux trouvés dans l'annotation, cette MethodPermission sera utilisée au lieu d'en créer une nouvelle. Pour chaque nom de rôle spécifié dans l'annotation, un nouveau SecurityRole est créé et ajouté à la liste SecurityRole dans la MethodPermission. Si la MethodPermission a été créée récemment, elle est ajoutée à la liste MethodPermission dans le descripteur de déploiement. Le nouveau MethodElement est ajouté à la liste MethodElement de la MethodPermission. Un traitement similaire est effectué pour toutes les méthodes annotées. Au lieu d'un MethodElement générique, la signature de méthode doit correspondre exactement à la signature de la méthode annotée. De plus, pour chaque nom de rôle spécifié dans l'annotation, si la liste du descripteur de déploiement des rôles de sécurité ne contient pas de SecurityRole avec le nom de rôle annoté, un nouveau SecurityRole est également créé et ajouté à cette liste de rôles de sécurité.
- @ServletSecurity (servlet 3.0 uniquement)Remarque : La prise en charge de l'annotation ServletSecurity pour le servlet 3.0 est une nouveauté de cette édition de WebSphere Application Server.
Lorsqu'une application est déployée, l'implémentation MergeAction de ServletSecurity trouve tous les servlets avec l'annotation ServletSecurity. Pour chaque servlet annoté, cette implémentation trouve le servlet associé à la base de la classe donnée sur l'annotation WebServlet. Si le paramètre RolesAllowed dans l'annotation ServletSecurity est introuvable dans le descripteur de déploiement, un attribut role-name est créé pour le rôle dans le descripteur de déploiement.
Lorsqu'une application démarre, le WebContainer contrôle tous les servlets à l'aide des annotations RunAs, declareRoles et ServletSecurity, puis définit ces annotations sur la méthode setServletSecurity() de l'annotation ServletRegistration. Le WebContainer signale au composant de sécurité qu'il doit contrôler toutes les annotations ServletRegistration comportant des modèles d'URL et des contraintes de sécurité. Le composant de sécurité détermine ensuite si un modèle d'URL est défini dans le descripteur de déploiement. Si ce n'est pas le cas, les contraintes de sécurité et le rôle RunAs du modèle d'URL sont créés, puis utilisés. Si une correspondance exacte est déjà définie dans le descripteur de déploiement, les contraintes de sécurité et le rôle RunAs du modèle d'URL du descripteur de déploiement sont utilisés à la place des données d'annotation.
Remarque : Lorsque la propriété du système d'authentification Web, com.ibm.wsspi.security.web.webAuthReq, est définie sur persisting, vous pouvez vous connecter à une URL non protégée si un nom d'utilisateur et un mot de passe valides sont fournis.L'annotation de servlet Inherited est une annotation de métadonnées. Ne la mentionnez pas dans la classe. Si une sous-classe ne comporte pas d'annotation de sécurité, elle hérite automatiquement l'annotation de sécurité de la classe parent. La sous-classe peut écraser les annotations de sécurité parent en spécifiant ses annotations de sécurité.
L'exemple suivant s'applique à toutes les méthodes HTTP sans contraintes :@WebServlet ("/Exemple") @ServletSecurity public class Example extends HttpServlet { …… }
L'exemple suivant s'applique à toutes les méthodes HTTP sans élément <auth-constraint> ni TransportGuarantee confidentiel :@WebServlet ("/Example") @ServletSecurity(@HttpConstraint(transportGuarantee = TransportGuarantee.CONFIDENTIAL)) public class Example extends HttpServlet { …… }
L'exemple suivant s'applique à toutes les méthodes HTTP avec tous les accès refusés :@WebServlet ("/Example") @ServletSecurity(@HttpConstraint(EmptyRoleSemantic.DENY)) public class Example extends HttpServlet { …… }
L'exemple suivant s'applique à toutes les méthodes HTTP, sauf pour les valeurs GET et POST sans contraintes. Pour GET, l'élément <auth-constraint> nécessite l'appartenance à ALL ROLE. Pour POST, tous les accès sont refusés.@WebServlet (name="Exemple", urlPatterns={"/Exemple"}) @ServletSecurity((httpMethodConstraints = { @HttpMethodConstraint(value = "GET", rolesAllowed = “ALL ROLE"), @HttpMethodConstraint(value="POST“, emptyRoleSemantic = EmptyRoleSemantic.DENY)) }) public class Example extends HttpServlet { …… }
L'exemple suivant s'applique à toutes les méthodes HTTP à l'exception de GET ; l'élément <auth-constraint> nécessite l'appartenance à ALL ROLE, et la méthode GET n'a pas de contrainte.@WebServlet (name="Exemple", urlPatterns={"/Exemple"}) @ServletSecurity(value = @HttpConstraint(rolesAllowed = "ALL ROLE"), httpMethodConstraints = @HttpMethodConstraint("GET")) public class Example extends HttpServlet { …… }
L'exemple suivant s'applique à toutes les méthodes HTTP à l'exception de TRACE ; l'élément <auth-constraint> nécessite l'appartenance à ALL ROLE, et pour TRACE, tous les accès sont refusés.@WebServlet (name="Exemple", urlPatterns={"/Exemple"}) @ServletSecurity(value = @HttpConstraint(rolesAllowed = "ALL ROLE"), httpMethodConstraints = @HttpMethodConstraint(value="TRACE", emptyRoleSemantic = EmptyRoleSemantic.DENY)) public class Example extends HttpServlet { …… }