Sécurité des URL du portlet
WebSphere Application Server autorise l'accès direct aux URL du portlet, tout comme les servlets. Cette section traite de la sécurité lors de l'accès aux portlets par le biais d'URL.
Dans le domaine de la sécurité, les portlets sont traités de la même façon que les servlets. La sécurité des portlets se fonde principalement sur le mécanisme de sécurité des servlets sous-jacent. Toutefois, les informations de sécurité relatives aux portlets sont enregistrées dans le fichier portlet.xml tandis que les fichiers JSP du servlet sont enregistrés dans le fichier web.xml. De plus, lorsque vous prenez des décisions d'accès concernant les portlets, les informations de sécurité éventuellement contenues dans le fichier web.xml sont associées à celles contenues dans le fichier portlet.xml.
La sécurité des portlets doit prendre en charge à la fois la sécurité par programme, qui correspond à isUserInRole, et la sécurité déclarative. La sécurité par programme est identique à celle qui s'applique aux servlets. Pour les portlets cependant, la méthode isUserInRole utilise les informations provenant de l'élément security-role-ref dans portlet.xml. Les deux autres méthodes utilisées par la sécurité par programme, getRemoteUser et getUserPrincipal, se comportent de la même façon que lors de l'accès à un servlet. Elles renvoient les informations relatives à l'utilisateur authentifié ayant accès au portlet.
- L'élément auth-constraint, qui répertorie les noms des rôles pouvant accéder aux ressources, n'existe pas dans le fichier portlet.xml. Ce dernier contient uniquement l'élément user-data-constraint (contrainte de données utilisateur) qui indique le type de sécurité TLS (HTTP ou HTTPS) nécessaire pour accéder au portlet.
- Les informations security-constraint (contraintes de sécurité) enregistrées dans le fichier portlet.xml contiennent l'élément portlet-collection (collection de portlets), tandis que le fichier web.xml file contient l'élément web-resource-collection (collection de ressources Web). L'élément portlet-collection contient une simple liste de noms de portlet, tandis que l'élément web-resource-collection contient des éléments url-patterns (masques d'URL), ainsi que les méthodes HTTP devant être protégées.
Le conteneur de portlets ne traite pas directement l'authentification utilisateur. Par exemple, il ne vous demande pas de collecter les informations de justificatif. En revanche, il doit utiliser le conteneur de servlets sous-jacent pour le mécanisme d'authentification des utilisateurs. Il n'existe donc pas d'élément auth-constraint dans les informations security-constraint du fichier portlet.xml.
Dans WebSphere Application Server, lors de l'accès à un portlet par le biais d'une URL, l'authentification des utilisateurs est traitée sur la base des informations security-constraint de ce portlet dans le fichier web.xml. Ainsi, pour qu'un utilisateur soit authentifié auprès d'un portlet, le fichier web.xml doit contenir les informations security-constraint relatives à ce portlet, associées aux éléments auth-constraints appropriés. Si un élément auth-constraint correspondant n'existe pas dans le fichier web.xml, l'authentification n'est pas requise pour le portlet. Dans ce cas, l'accès non authentifié est autorisé, comme dans le cas d'un masque d'URL pour un servlet qui ne contient pas d'élément auth-constraints dans le fichierweb.xml. Un élément auth-constraint pour un portlet peut être spécifié directement en utilisant le nom du portlet indiqué dans l'élément url-pattern ou indirectement par le biais d'un élément url-pattern qui implique le portlet.
Les exemples ci-dessous indiquent comment les informations security-constraint contenues dans les fichiers portlet.xml et web.xml d'une application de portlet peuvent être utilisées pour prendre des décisions concernant les portlets. L'élément security-role-ref, qui est utilisé pour les appels isUserInRole, n'est pas décrit dans cette rubrique, car il est utilisé comme pour les servlets.
Dans les exemples ci-dessous (sauf indication contraire), quatre portlets (MonPortlet1, MonPortlet2, MonPortlet3, MonPortlet4) sont définis dans le fichier portlet.xml. Lorsque l'accès aux portlets s'effectue de manière directe par le biais d'URL, les portlets sont sécurisés en combinant les informations éventuellement contenues dans le fichier web.xml.
Tous les exemples présentent le contenu des fichiers web.xml et portlet.xml. Utilisez les outils corrects lors de la création de ces fichiers de descripteur de déploiement comme s'il s'agissait d'assembler une application de portlet.
Exemple 1 : Le fichier web.xml ne contient pas de données security-constraint
<security-constraint>
<display-name>Portlets sécurisés</display-name>
<portlet-collection>
<portlet-name>MyPortlet1</portlet-name>
<portlet-name>MyPortlet3</portlet-name>
</portlet-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
Dans cet exemple, lorsque vous accédez à un élément quelconque sous MonPortlet1 et MonPortlet3 et que l'accès à ces derniers s'effectue par le biais d'un protocole HTTP non sécurisé, un réacheminement se produit par l'intermédiaire du protocole HTTPS sécurisé. L'élément transport-guarantee (garantie de transport) est configuré pour utiliser des connexions sécurisées. Pour MonPortlet2 et MonPortlet4, l'accès (HTTP) non sécurisé est autorisé car l'élément transport-guarantee n'est pas configuré. Il n'existe pas d'informations security-constraint correspondante pour les quatre portlets dans le fichier web.xml. Les utilisateurs peuvent donc accéder à ces portlets sont être authentifiés ni autorisés. La seule sécurité mise en oeuvre dans cette instance est la sécurité TLS via SSL (Secure Sockets Layer) pour MonPortlet1 et MonPortlet3.
URL | Protection du transport | Authentification des utilisateurs | Autorisation basée sur le rôle |
---|---|---|---|
/MonPortlet1/* | HTTPS | Aucun | Aucun |
/MonPortlet2/* | Aucun | Aucun | Aucun |
/MonPortlet3/* | HTTPS | Aucun | Aucun |
/MonPortlet4/* | Aucun | Aucun | Aucun |
Exemple 2 : Le fichier web.xml contient les données security-constraint spécifiques du portlet
<security-constraint id="SecurityConstraint_1">
<web-resource-collection id="WebResourceCollection_1">
<web-resource-name>Protected Area</web-resource-name>
<url-pattern>/MonPortlet1/*</url-pattern>
<url-pattern>/MonPortlet2/*</url-pattern>
</web-resource-collection>
<auth-constraint id="AuthConstraint_1">
<role-name>Employee</role-name>
</auth-constraint>
</security-constraint>
- Un élément url-pattern étant utilisé dans le fichier web.xml, le nom du portlet a été légèrement modifié. MonPortlet1 devient /MonPortlet1/*, ce qui indique que tout les éléments sous l'URL MonPortlet1 sont protégés. Cela correspond aux informations contenues dans le fichier portlet.xml car le code du module d'exécution de la sécurité convertit l'élément portlet-name (nom de portlet) dans le fichier portlet.xml en élément url-pattern (par exemple, MonPortlet1 en /MonPortlet1/*), même pour l'élément transport-guarantee (garantie de transport).
- L'élément http-method (méthode http) du fichier web.xml n'est pas utilisé dans l'exemple car toutes les méthodes HTTP doivent être protégées.
URL | Protection du transport | Authentification des utilisateurs | Autorisation basée sur le rôle |
---|---|---|---|
MonPortlet1/* | HTTPS | Oui | Oui (Employé) |
MonPortlet2/* | Aucun | Oui | Oui (Employé) |
MonPortlet3/* | HTTPS | Aucun | Aucun |
MonPortlet4/* | Aucun | Aucun | Aucun |
Exemple 3 : Le fichier web.xml contient des données security-constraint génériques impliquant tous les portlets.
<security-constraint id="SecurityConstraint_1">
<web-resource-collection id="WebResourceCollection_1">
<web-resource-name>Protected Area</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint id="AuthConstraint_1">
<role-name>Manager</role-name>
</auth-constraint>
</security-constraint>
Dans cet exemple, /* indique que toutes les ressources qui ne contiennent pas d'élément security-constraints explicite spécifique doivent être protégées par le rôle Gestionnaire (Manager), conformément aux règles de correspondance des masques d'URL. Etant donné que le fichier portlet.xml contient des informations security-constraint spécifiques pour MonPortlet1 et MonPortlet3, ces deux portlets ne sont pas protégés par le rôle Gestionnaire, mais uniquement par le transport HTTPS. Etant donné que le fichier portlet.xml ne peut pas contenir les informations auth-constraint, tout portlet qui contient des éléments security-contraints devient non protégé lorsqu'une URL (/* par exemple) est répertoriée dans le fichier web.xml en raison des règles de correspondance d'URL.
Dans le cas précédent, les utilisateurs peuvent accéder aux portlets MonPortlet1 et MonPortlet3 sans être authentifiés. Toutefois, étant donné que les portlets MonPortlet2 et MonPortlet4 n'ont pas d'information security-constraints définie dans le fichier portlet.xml, le masque /* est utilisé pour la mise en correspondance et les portlets sont protégés par le rôle Gestionnaire qui requiert l'authentification des utilisateurs.
URL | Protection du transport | Authentification des utilisateurs | Autorisation basée sur le rôle |
---|---|---|---|
MonPortlet1/* | HTTPS | Aucun | Aucun |
MonPortlet2/* | Aucun | Oui | Oui (Gestionnaire) |
MonPortlet3/* | HTTPS | Aucun | Aucun |
MonPortlet4/* | Aucun | Oui | Oui (Gestionnaire) |
<security-constraint id="SecurityConstraint_1">
<web-resource-collection id="WebResourceCollection_1">
<web-resource-name>Protected Area</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint id="AuthConstraint_1">
<role-name>Manager</role-name>
</auth-constraint>
</security-constraint>
<security-constraint id="SecurityConstraint_2">
<web-resource-collection id="WebResourceCollection_2">
<web-resource-name>Protection pour MonPortlet1</web-resource-name>
<url-pattern>/MonPortlet1/*</url-pattern>
</web-resource-collection>
<auth-constraint id="AuthConstraint_1">
<role-name>Manager</role-name>
</auth-constraint>
</security-constraint>
Dans ce cas, MonPortlet1 est protégé par le rôle Gestionnaire (Manager) et l'authentification est requise. L'élément data-constraint CONFIDENTIAL s'applique également à ce portlet étant donné que les informations contenues dans les fichiers web.xml et portlet.xml sont combinées. MonPortlet3 n'étant pas répertorié explicitement dans le fichier web.xml, celui-ci n'est toujours pas protégé par le rôle Gestionnaire et l'authentification des utilisateurs n'est pas requise.
URL | Protection du transport | Authentification des utilisateurs | Autorisation basée sur le rôle |
---|---|---|---|
MonPortlet1/* | HTTPS | Oui | Oui (Gestionnaire) |
MonPortlet2/* | Aucun | Oui | Oui (Gestionnaire) |
MonPortlet3/* | HTTPS | Aucun | Aucun |
MonPortlet4/* | Aucun | Oui | Oui (Gestionnaire) |