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

La sécurité Java™ 2 utilise plusieurs fichiers de règles pour déterminer les droits accordés à chaque programme Java. Le fichier was.policy est un fichier de règles spécifique aux applications d'entreprise WebSphere Application Server. Ce fichier est imbriqué dans le fichier .EAR META-INF/was.policy. Le fichier was.policy se trouve dans :
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.

Tableau 1. Symboles définis pour associer des listes de droits d'accès à un type de ressource spécifique. Plusieurs symboles réservés sont définis pour associer les listes de droits d'accès à un type de ressource spécifique.
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";
};
Tableau 2. Symboles imbriqués fournis pour indiquer le chemin d'accès et le nom de java.io.FilePermission. Cinq symboles imbriqués sont fournis pour indiquer le chemin d'accès et le nom de java.io.FilePermission. Ces symboles permettent une spécification de droits d'accès souple. Le chemin complet du fichier est spécifié une fois l'application installée.
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

Si les droits d'accès par défaut pour l'application d'entreprise suffisent, aucun action n'est requise. Les droits d'accès par défaut correspondent à une union de droits d'accès définis dans les fichiers java.policy, server.policy et app.policy. Si une application doit accéder à des ressources spécifiques, mettez à jour le fichier was.policy. Les deux premières étapes impliquent la création d'un fichier de règles.
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

  1. Créez ou modifiez un fichier was.policy en utilisant l'outil de règles. Pour plus d'informations, voir Utilisation de PolicyTool pour éditer des fichiers de règles pour la sécurité Java 2.
  2. Intégrez le fichier was.policy dans le fichier EAR (Enterprise ARchive).

    Pour plus d'informations, voir Ajout du fichier was.policy aux applications pour la sécurité Java 2.

    Les instructions suivantes indiquent comment importer un fichier was.policy.
    1. Importez le fichier EAR dans un outil d'assemblage.
    2. Ouvrez la vue Navigateur de projets.
    3. Développez le fichier EAR et cliquez sur META-INF. Un fichier was.policy peut se trouver dans le répertoire META-INF. Pour supprimer ce fichier, cliquez avec le bouton droit de la souris sur son nom et sélectionnez Supprimer.
    4. Dans la vue Navigateur de projets, cliquez sur Hiérarchie J2EE.
    5. Pour importer le fichier was.policy, cliquez avec le bouton droit de la souris sur le répertoire Modules dans le descripteur de déploiement et sélectionnez Importer > Importer > Système de fichiers.
    6. Cliquez sur Next.
    7. Entrez le chemin du fichier was.policy dans la zone De ou cliquez sur Parcourir pour rechercher le fichier.
    8. Vérifiez que le répertoire de chemin indiqué dans la zone Dans le répertoire contient le répertoire META-INF correct.
    9. Cliquez sur Terminer.
    10. Pour valider le fichier EAR, cliquez avec le bouton droit de la souris sur le fichier EAR qui contient le répertoire Modules et cliquez sur Exécuter la validation.
    11. Pour sauvegarder le nouveau fichier EAR, cliquez dessus avec le bouton droit de la souris et cliquez sur Exporter > Exporter le fichier EAR. Si vous ne sauvegardez pas le fichier EAR révisé, ce dernier contient le nouveau fichier was.policy. Toutefois, en cas d'altération de l'espace de travail, vous risquez de perdre le fichier EAR révisé.
    12. Pour générer le code de déploiement, cliquez avec le bouton droit de la souris sur le fichier EAR et cliquez sur Générer le code de déploiement.
  3. Mettez à jour une application déjà installée s'il en existe une. Modifiez le fichier was.policy avec l'outil de règles. Pour plus d'informations, voir Utilisation de PolicyTool pour éditer des fichiers de règles pour la sécurité Java 2.[z/OS]
    1. Extrayez le fichier de règles. Entrez la commande suivante à partir d'une ligne de commande :
      wsadmin> set obj [$AdminConfig extract profiles/profile_name/cells/cell_name
      /application/ear_file_name/deployments/application_name
      /META_INF/was.policy c:/temp/test/was.policy]

      Entrez les trois lignes précédentes sur une seule ligne. Elles sont fournies ici à des fins d'illustration uniquement.

    2. Modifiez le fichier extrait was.policy à l'aide de l'outil de règles. Pour plus d'informations, voir Utilisation de PolicyTool pour éditer des fichiers de règles pour la sécurité Java 2.
    3. Archivez le fichier de règles. Entrez les commandes suivantes à l'invite :
      wsadmin> $AdminConfig checkin profiles/profile_name/cells/cell_name/application/
      ear_file_name/deployments/application_name/META_INF/was.policy 
      c:/temp/test/was.policy $obj

      Entrez les trois lignes précédentes sur une seule ligne. Elles sont fournies ici à des fins d'illustration uniquement.

Résultats

Le fichier was.policy mis à jour est appliqué à l'application une fois que celle-ci a été relancée.

Exemple

[IBM i][z/OS]
java.security.AccessControlException: access denied (java.io.FilePermission 
${was.install.root}/java/ext/mail.jar read)
[z/OS][IBM i]Si une application doit accéder à une ressource spécifique non définie comme ressource par défaut dans les fichiers java.policy, server.policy et app.policy, supprimez le fichier was.policy de cette application. Lorsque des droits d'accès manquent, l'exception java.security.AccessControlException est générée. Les droits d'accès manquants sont répertoriés dans les données de l'exception :
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][z/OS]
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][z/OS]
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.

Que faire ensuite

Redémarrez toutes les applications pour que la mise à jour du fichier app.policy soit appliquée.

Icône indiquant le type de rubrique Rubrique de tâche



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tsec_waspolicyfile
Nom du fichier : tsec_waspolicyfile.html