Ajout du fichier was.policy aux applications pour la sécurité Java 2

Un fichier was.policy peut s'avérer nécessaire pour que l'application puisse accéder aux ressources qui requièrent des droits d'accès supérieurs à ceux affectés par défaut dans le fichier app.policy par défaut.

Pourquoi et quand exécuter cette tâche

Lorsque la sécurité Java™ 2 est activée pour un serveur WebSphere Application Server, toutes les applications exécutées sur WebSphere Application Server sont soumises à un contrôle de sécurité avant tout accès aux ressources système. Un fichier was.policy peut s'avérer nécessaire pour que l'application puisse accéder aux ressources qui requièrent des droits d'accès supérieurs à ceux affectés par défaut dans le fichier app.policy par défaut. Par défaut, la fonction de sécurité du produit lit un fichier app.policy qui se trouve sur chaque noeud et accorde à toutes les applications les droits du fichier app.policy. Incluez tous les droits d'accès supplémentaires requis dans le fichier was.policy. Le fichier was.policy n'est nécessaire que si une application requiert des droits supplémentaires.

Le fichier de règles par défaut de toutes les applications est spécifié dans le fichier app.policy. Ce fichier est fourni par la sécurité du produit. Il est commun à toutes les applications de ce fichier. Ajoutez les nouveaux droits d'accès requis pour une application dans le fichier was.policy.

Le fichier app.policy fourni par WebSphere Application Server se trouve sur racine_serveur_app/config/cells/profile/nom_profil/config/nom_cellule/nodes/nom_noeud/app.policy. Le contenu du fichier app.policy est le suivant :

Avertissement : Dans l'exemple de code ci-dessous, les deux autorisations nécessaires à JavaMail sont scindées en deux à des fins d'illustration. Entrez les droits d'accès sur une seule ligne.
// Les droits
suivants s'appliquent à tous les composants de l'application.

grant codeBase "file:${application}" {
   // Les éléments suivants sont requis par JavaMail

  permission java.io.FilePermission "
        ${was.install.root}${/}lib${/}activation-impl.jar",
"read";

  permission java.io.FilePermission "
        ${was.install.root}${/}lib${/}mail-impl.jar","read";

  };
   // Les autorisations ci-dessous s'appliquent à tous les fichiers de l'utilitaire 
   //  .jar (autres que les fichiers EJB) dans l'application.
grant codeBase "file:${jars}" {
  permission java.net.SocketPermission "*", "connect";
  permission java.util.PropertyPermission "*", "read";
};

// Les droits suivants s'appliquent aux ressources du connecteur au
sein de l'application
grant codeBase "file:${connectorComponent}" {
  permission java.net.SocketPermission "*", "connect";
  permission java.util.PropertyPermission "*", "read";
};

// Les droits suivants s'appliquent à tous les modules web (fichiers .war) 
// de l'application.
grant codeBase "file:${webComponent}" {
  permission java.io.FilePermission "${was.module.path}${/}-", "read, write";  
       //  où "was.module.path" correspond au chemin d'installation du 
       //  module Web. Pour
connaître d'autres symboles, reportez-vous aux concepts de règles dynamique.
  permission java.lang.RuntimePermission "loadLibrary.*";
  permission java.lang.RuntimePermission "queuePrintJob";
  permission java.net.SocketPermission "*", "connect";
  permission java.util.PropertyPermission "*", "read";
};

// Les droits suivants s'appliquent à tous les modules EJB de l'application.
grant codeBase "file:${ejbComponent}" {
 permission java.lang.RuntimePermission "queuePrintJob";
 permission java.net.SocketPermission "*", "connect";
 permission java.util.PropertyPermission "*", "read";
};

Si des droits supplémentaires sont requis pour une application ou un ou plusieurs modules d'une application, utilisez le fichier was.policy de cette application. Utilisez par exemple la base de code ${application} et ajoutez les droits requis pour accorder des droits supplémentaires à toute l'application. De même, utilisez la base de code de ${webComponent} et de ${ejbComponent} pour affecter des autorisations supplémentaires à tous les modules web et tous les modules de bean enterprise (EJB) de l'application. Vous pouvez affecter des autorisations supplémentaires à chaque module (fichier .war ou .jar), selon les indications de l'exemple suivant.

Cet exemple illustre l'ajout d'autorisations supplémentaires pour une application dans le fichier was.policy :

Avertissement : Dans l'exemple de code ci-dessous, l'autorisation associée au module EJB a été scindée en deux lignes à des fins d'illustration. Entrez les droits d'accès sur une seule ligne.
// accorde des droits supplémentaires à un module Web
grant codeBase " file:aWebModule.war" {
 permission java.security.SecurityPermission "printIdentity";
};

// accorde des droits supplémentaires à un module EJB
grant codeBase "file:aEJBModule.jar"  {
    permission java.io.FilePermission "
       ${user.install.root}${/}bin${/}DefaultDB${/}-", "read,write,delete";   
    // où ${user.install.root} est la propriété système dont la valeur 
    // se trouve dans le répertoire racine_serveur_app.
 };

Pour utiliser un fichier was.policy pour votre application :

Procédure

  1. Créez un fichier was.policy à l'aide de l'outil de règles. Pour plus d'informations sur l'utilisation de l'outil de règles, voir Utilisation de PolicyTool pour éditer des fichiers de règles pour la sécurité Java 2.
  2. Ajoutez les droits requis dans le fichier was.policy à l'aide de l'outil de règles.
  3. Placez le fichier was.policy dans le fichier EAR (Enterprise Archive), dans le répertoire META-INF. Mettez à jour le fichier EAR de l'application à l'aide du fichier was.policy que vous venez de créer à l'aide de la commande jar.
  4. Vérifiez que le fichier was.policy est inséré et lancez un outil d'assemblage.
    [IBM i][z/OS]Remarque : Aucun outil d'assemblage n'est disponible. Utilisez un outil d'assemblage sur une autre plate-forme, comme Linux Intel ou Windows.
  5. Vérifiez que la syntaxe du fichier was.policy dans l'application est correcte. Dans un outil d'assemblage, cliquez à l'aide du bouton droit de la souris sur le module d'application d'entreprise et cliquez surExécuter la validation.

Résultats

Vous disposez maintenant d'un fichier EAR d'application prêt à être exécuté lorsque la sécurité Java 2 est activée.

Exemple

Cette étape est indispensable pour que les applications s'exécutent correctement lorsque la sécuritéJava 2 est activée. Si le fichier was.policy n'est pas créé et qu'il ne contient pas les droits requis, l'application risque de ne pas pouvoir accéder aux ressources système.

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, par exemple,

[IBM i][z/OS]
java.security.AccessControlException: access denied (java.io.FilePermission 
${was.install.root}/java/ext/mail.jar read)
Lorsqu'une application reçoit cette exception et que l'ajout de ces droits d'accès est justifié, incluez le droit d'accès dans le fichier was.policy, par exemple : [IBM i][z/OS]
grant codeBase "file:emplacement_installation_du_client_de_l'utilisateur" { 
  permission java.io.FilePermission 
"${was.install.root}$(/)java$(/)jre$(/)lib$(/)ext$(/)mail.jar", "read";
};

Les lignes d'information précédentes sur les droits sont coupées à titre d'illustration. Entrez le droit d'accès sur une ligne.

Que faire ensuite

Installez l'application.

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_waspolicy
Nom du fichier : tsec_waspolicy.html