Configuration du fichier was.policy pour la sécurité Java 2
Vous devez mettre à jour le fichier was.policy si l'application doit accéder à des ressources particulières.
Avant de commencer
profile_root/config/cells/cell_name/applications/
ear_file_name/deployments/application_name/META-INF/was.policy
Pour obtenir la liste des fichiers de règles disponibles pris en charge par WebSphere Application Server Version 6.1, voir les fichiers de règles de sécurité Java 2.
L'union des droits
d'accès contenus dans les fichiers ci-dessous concerne l'application d'entreprise
WebSphere
Application Server :
- les fichiers de règles spécifiés dans les propriétés policy.url.* dans le fichier java.security,
- les fichiers app.policy gérés par les services de configuration et de réplication de fichiers,
- le fichier server.policy,
- le fichier java.policy,
- le fichier was.policy,
- la spécification de droits d'accès du fichier ra.xml,
- la bibliothèque partagée, qui correspond au fichier library.policy.
Les modifications apportées à ces fichiers sont répliquées sur d'autres noeuds dans la cellule.
Symbole | Définition |
---|---|
file:${application} | Les droits d'accès s'appliquent à toutes les ressources utilisées au sein de l'application. |
file:${jars} | Les droits d'accès s'appliquent à tous les fichiers JAR (Java archive) utilitaires de l'application |
file:${ejbComponent} | Les droits d'accès s'appliquent aux ressources EJB de l'application. |
file:${webComponent} | Les droits d'accès s'appliquent aux ressources Web au sein de l'application. |
file:${connectorComponent} | Les droits d'accès s'appliquent aux ressources du connecteur au sein de l'application. |
Dans WebSphere Application Server, les droits d'accès aux unités d'exécution appropriées doivent être spécifiés dans le fichier was.policy ou app.policy pour
les applications qui manipulent des unités d'exécution.
Si les droits d'accès aux unités d'exécution ne sont pas spécifiés, l'application ne peut pas manipuler d'unités d'exécution et WebSphere Application
Server crée une exception java.security.AccessControlException. Si vous ajoutez les droits d'accès au
fichier was.policy pour une application spécifique, vous n'avez pas besoin de relancer
WebSphere
Application Server. Un administrateur doit ajouter le code ci-dessous à un fichier was.policy ou app.policy pour qu'une application puisse manipuler des unités d'exécution :
grant codeBase "file:${application}" {
permission java.lang.RuntimePermission "stopThread";
permission java.lang.RuntimePermission "modifyThread";
permission java.lang.RuntimePermission "modifyThreadGroup";
};
Un administrateur peut ajouter les droits d'accès aux unités d'exécution au fichier
app.policy, mais toute modification des droits d'accès implique le redémarrage de
WebSphere
Application Server.Important : Les mots clés des principaux Signed By et JAAS (Java Authentication and Authorization Service) ne sont pas pris en charge dans le fichier was.policy. Le mot clé Signed By est pris en charge dans les fichiers de règles java.policy, server.policy,
et client.policy. Le mot clé de principal JAAS est pris en charge dans un fichier de règles JAAS lorsqu'il est spécifié par la propriété système java.security.auth.policy de la machine virtuelle Java. Vous pouvez définir de manière statique les fichiers de règles d'autorisation dans le fichier java.security.auth.policy avec auth.policy.url.n=URL, où URL est l'emplacement de la règle d'autorisation.
Outre ces blocs, vous pouvez indiquer le nom du module
pour les paramètres de granularité.
Par exemple
grant codeBase "file:DefaultWebApplication.war" {
permission java.security.SecurityPermission "printIdentity";
};
grant codeBase "file:IncCMP11.jar" {
permission java.io.FilePermission
"${user.install.root}${/}bin${/}DefaultDB${/}-",
"read,write,delete";
};
Symbole | Définition |
---|---|
${app.installed.path} | Chemin d'accès à l'emplacement de l'installation de l'application. |
${was.module.path} | Chemin d'accès à l'emplacement d'installation du module. |
${current.cell.name} | Nom de celluleactuel |
${current.node.name} | Nom de noeud actuel |
${current.server.name} | Nom de serveur actuel |
Pourquoi et quand exécuter cette tâche
Conseil : Les erreurs
de syntaxe dans les fichiers de règle entraînent l'échec du serveur d'applications. Portez une attention particulière lors de
l'édition de ces fichiers de règles.
Procédure
Résultats
Exemple
![[IBM i]](../images/iseries.gif)
![[z/OS]](../images/ngzos.gif)
java.security.AccessControlException: access denied (java.io.FilePermission
${was.install.root}/java/ext/mail.jar read)
![[z/OS]](../images/ngzos.gif)
![[IBM i]](../images/iseries.gif)
Remarque : Les exemples ci-après sont répartis sur plusieurs lignes à des fins d'illustration uniquement. Entrez
les droits d'accès sur une seule ligne.
![[IBM i]](../images/iseries.gif)
![[z/OS]](../images/ngzos.gif)
java.security.AccessControlException: access denied (java.io.FilePermission
${was.install.root}/java/ext/mail.jar read)
Lorsqu'un programme Java reçoit cette exception et que l'ajout de ce droit est justifié, ajoutez le droit d'accès suivant au fichier was.policy :
![[IBM i]](../images/iseries.gif)
![[z/OS]](../images/ngzos.gif)
grant codeBase "file:user_client_installed_location" {
permission java.io.FilePermission
"${was.install.root}$(/)java$(/)jre$(/)lib$(/)ext$(/)mail.jar", "read";
};
Pour déterminer s'il est nécessaire d'ajouter un droit d'accès, voir Exception de contrôle d'accès pour la sécurité Java 2.