Prise en charge de JACC dans WebSphere Application Server
WebSphere Application Server prend en charge la spécification JACC (Java™ Authorization Contract for Containers), qui permet à des fournisseurs de sécurité tiers de gérer les autorisations Java EE (Java Platform, Enterprise Edition).
La spécification JACC exige que les conteneurs du serveur d'applications et le fournisseur remplissent certains critères. Les conteneurs sont nécessaires pour transmettre au fournisseur les informations relatives aux règles de sécurité lors du déploiement d'applications et appeler le fournisseur pour toutes les décisions d'autorisation. Les fournisseurs sont nécessaires pour le stockage des informations relatives aux règles dans leur référentiel lors du déploiement d'applications. Les fournisseurs utilisent ensuite ces informations pour prendre des décisions d'autorisation lorsque le conteneur les appelle.
Décisions d'accès JACC
Lorsque la sécurité est activée et qu'un processus accède à un bean enterprise ou à une ressource Web, le conteneur d'EJB (Enterprise JavaBeans) ou le conteneur Web appelle le module d'exécution de la sécurité pour déterminer si l'accès doit être autorisé. Lorsque vous utilisez un fournisseur externe, la décision relative à l'autorisation d'accès est déléguée à ce fournisseur.
Conformément à la spécification JACC (Java Authorization Contract for Containers), l'objet droit d'accès est créé, les gestionnaires du contexte de règles appropriés sont enregistrés et l'identificateur du contexte de règles approprié (contextID) est défini. Un appel de la méthode d'objet java.security.Policy, implémentée par le fournisseur, est lancé pour prendre la décision d'accès.
Les sections suivantes indiquent comment le fournisseur est appelé pour des ressources Web et de bean enterprise.
Décisions d'accès pour les beans enterprise
- Il crée l'objet EJBMethodPermission à l'aide du nom de bean, du nom de méthode, du nom d'interface et de la signature de la méthode.
- Il crée l'ID de contexte et le définit sur l'unité d'exécution en utilisant la méthode PolicyContext.setContextID(contextID).
- Il enregistre les gestionnaires de contextes de règles requis, notamment le gestionnaire de contextes de règles du sujet.
- Il crée l'objet ProtectionDomain avec le principal dans le sujet. S'il n'existe pas de principal, la valeur null est transmise pour le nom de principal.
- La décision d'accès est déléguée au fournisseur JACC en appelant la méthode implies de l'objet Policy, qui est implémentée par le fournisseur. Les objets EJBMethodPermission et ProtectionDomain sont transmis à cette méthode.
- La vérification d'accès isCallerInRole suit également la même procédure, sauf qu'un objet EJBRoleRefPermission est créé au lieu d'un objet EJBMethodPermission.
Décisions d'accès pour les ressources Web
- Un objet WebResourcePermission est créé afin de déterminer si l'URI est désélectionné. Si le fournisseur prend en compte le sujet Everyone, il est sélectionné lui aussi.
- L'objet WebResourcePermission est construit avec la méthode urlPattern et HTTP qui a fait l'objet d'un accès.
- Un objet ProtectionDomain avec un nom de principal null est créé.
- La méthode Policy.implies du fournisseur JACC est appelée avec le droit d'accès et le domaine de protection. Si l'accès à l'URI est désélectionné ou si l'accès est accordé au sujet Everyone, le fournisseur autorise l'accès (renvoie la valeur true) dans la méthode implies. L'accès est ensuite accordé sans vérifications supplémentaires.
- Si l'accès n'est pas accordé à l'étape précédente, un objet WebUserDataPermission est créé et utilisé pour déterminer si l'URI (Uniform Resource Identifier) est interdit ou exclu ou s'il doit être redirigé à l'aide du protocole HTTPS.
- L'objet WebUserDataPermission est construit avec un accès urlPattern, l'appel de méthode HTTP et le type de transport de la demande. Si la demande est effectuée via HTTPS, le type de transport correspond à CONFIDENTIAL ; Sinon, la valeur null est transmise.
- Un objet ProtectionDomain avec un nom de principal null est créé.
- La méthode Policy.implies du fournisseur JACC est appelée avec le droit d'accès et le domaine de protection. Si la demande utilise le protocole HTTPS et que la méthode implies renvoie la valeur false, l'erreur 403 HTTP est renvoyée pour indiquer un droit d'accès interdit ou exclu. Dans ce cas, aucune autre vérification n'est effectuée. Si la demande n'utilise pas le protocole HTTPS et que la méthode implies renvoie la valeur false, la demande est redirigée via le protocole HTTPS.
- L'environnement de sécurité tente d'authentifier l'utilisateur. Si les informations d'authentification existent déjà (par exemple le jeton LTPA), elles sont utilisées. Sinon, vous devez entrer les justificatifs de l'utilisateur.
- Une fois que les justificatifs de l'utilisateur ont été validés, une dernière vérification d'autorisation est effectuée pour déterminer si l'utilisateur dispose des droits d'accès à l'URI.
- Comme à l'étape 1, l'objet WebResourcePermission est créé. L'objet ProtectionDomain contient maintenant le principal qui tente d'accéder à l'URI. Le gestionnaire du contexte des règles du sujet contient également des informations utilisateur, disponibles pour la vérification des accès.
- La méthode implies du fournisseur est appelée à l'aide de l'objet Permission et de l'objet ProtectionDomain créé précédemment. Si l'utilisateur reçoit les droits d'accès nécessaires pour accéder à la ressource, la méthode implies renvoie la valeur true. Si l'accès est refusé à l'utilisateur, la méthode implies renvoie la valeur false.
Pour plus d'informations sur ces droits d'accès, voir JSR-000115 Java Authorization Contract for Containers (Version 1.5 Maintenance Release).
Utilisation des informations du sujet pour la décision d'accès
Si le fournisseur s'appuie sur le sujet généré par WebSphere Application pour prendre la décision d'accès, il peut interroger les justificatifs publics du sujet afin d'obtenir le justificatif WSCredential. L'API WSCredential est utilisé pour obtenir des informations sur l'utilisateur, notamment son nom et les groupes auxquels il appartient. Ces informations sont utilisées pour prendre des décisions d'accès.
Si le fournisseur ajoute les informations requises au sujet, WebSphere Application Server peut les utiliser pour prendre la décision d'accès. Le fournisseur ajoute des informations au sujet à l'aide de la fonction TAI (Trust Association Interface) ou en intégrant des modules de connexion au serveur d'applications.
La section relative à la propagation des attributs de sécurité contient des informations complémentaires sur l'ajout des informations WebSphere Application Server requises au sujet. Pour plus d'informations, voir Propagation des attributs de sécurité parmi les serveurs d'applications.
Mises à jour de module dynamiques dans JACC
WebSphere Application Server prend en charge la mise à jour dynamique des modules Web dans certaines conditions. Si un module Web est mis à jour, supprimé ou ajouté à une application, seul ce module est arrêté et démarré, selon le cas. Les autres modules existants de l'application ne sont pas affectés et l'application elle-même n'est pas arrêté, puis relancée.
Lors de l'utilisation du moteur d'autorisation par défaut, les règles de sécurité sont modifiées dans les modules Web, l'application est arrêtée, puis relancée. Lorsque vous utilisez le mécanisme d'autorisation JACC (Java Authorization Contract for Containers), le comportement dépend des fonctionnalités prises en charge par un fournisseur. Si un fournisseur peut prendre en charge la modification dynamique des modules Web, seuls les modules Web sont affectés. Sinon, l'application est complètement arrêtée et relancée pour que les nouvelles modifications apportées aux modules Web soient prises en compte.
Un fournisseur peut indiquer s'il prend en charge les mises à jour dynamiques en configurant l'option Prend en charge les mises à jour de modules dynamiques dans le modèle de configuration JACC (pour plus d'informations, voir Autorisation de l'accès aux ressources Java EE à l'aide de Tivoli Access Manager). Cette option peut être activée ou désactivée via la console d'administration ou l'outil de scriptage. En général, la plupart des fournisseurs stockent les informations relatives aux règles dans leur référentiel externe afin de pouvoir prendre en charge ces mises à jour dynamiques. Cette option doit être activée par défaut pour la plupart des fournisseurs.
Lorsque l'option Prend en charge les mises à jour de modules dynamiques est activée et que le module Web contenant les rôles de sécurité est ajouté, modifié ou supprimé de manière dynamique, seuls les modules Web spécifiques sont affectés et relancés. Si l'option est désactivée, l'ensemble de l'application est relancée. Lorsque des mises à jour dynamiques sont effectuées, les informations relatives aux règles de sécurité des modules affectés sont transmises au fournisseur. Pour plus d'informations sur la propagation des règles de sécurité, voirPropagation des règles JACC.
Initialisation du fournisseur JACC
Si un fournisseur JACC (Java Authorization Contract for Containers) requiert une initialisation lors du démarrage du serveur, par exemple, pour permettre au code client de communiquer avec le code du serveur, l'interface com.ibm.wsspi.security.authorization.InitializeJACCProvider peut être implémentée par le fournisseur. Pour plus d'informations, voir Interfaces utilisées pour prendre en charge JACC.
Lorsque cette interface est implémentée, elle est appelée lors du démarrage du serveur. Les propriétés personnalisées du modèle de configuration JACC sont transmises à la méthode d'initialisation de cette implémentation. Vous pouvez les entrer à l'aide de la console d'administration ou l'outil de scriptage.
Lors de l'arrêt du serveur la méthode de nettoyage est appelée pour effectuer les opérations de nettoyage demandées par un fournisseur. L'implémentation de cette interface est facultative et elle n'est utilisée que si le fournisseur requiert une initialisation lors du démarrage du serveur.
Environnement doté de noeuds mixtes et JACC
Le mécanisme d'autorisation JACC (Java Authorization Contract for Containers) est une nouvelle fonction de WebSphere Application Server version 6 qui a été améliorée pour prendre en charge la dernière spécification JACC version 1.5 dans WebSphere Application Server version 9.
La configuration de JACC est effectuée au niveau de la cellule et est applicable à tous les noeuds et serveurs de cette cellule.
Si vous envisagez d'utiliser les fonctions du mécanisme d'autorisation JACC version 1.5, la cellule ne doit contenir que des noeuds version 9 et ultérieure. Cette restriction signifie qu'un environnement de noeud mixte contenant les noeuds de la version 8.5.x ou antérieure dans une cellule de la version 9 ou ultérieure est pris en charge pour le mécanisme d'autorisation JACC qui est basé sur le plus bas niveau de version pris en charge dans la cellule. Dans ce cas, il s'agit du mécanisme d'autorisation JACC version 1.4.