Les utilisateurs peuvent configurer des fichiers de règles de sécurité Java™ 2 de sorte que les droits requis soient accordés à l'application d'entreprise WebSphere Application Server spécifiée.
Avant de commencer
La sécurité Java 2 utilise plusieurs fichiers de règles pour déterminer les
droits accordés à chaque programme Java.
Pour obtenir
la liste des fichiers de règles disponibles pris en charge par WebSphere Application Server, voir la rubrique relative aux fichiers de règles de sécurité Java 2.
WebSphere Application Server gère deux types de fichiers de règles : les fichiers de règles dynamiques et les fichiers de règles statiques. Ces
derniers fournissent les droits par défaut. Les fichiers de règles dynamiques fournissent les droits de
l'application. Six fichiers de règles dynamiques sont fournis :
Tableau 1. fichiers de règles dynamiques. Le tableau suivant répertorie les fichiers de règles dynamiques.Nom du fichier de règles |
Description |
app.policy |
Contient les droits par défaut de toutes les
applications d'entreprise de la cellule. Remarque : Les mises à jour du fichier app.policy s'appliquent uniquement aux applications d'entreprise sur le noeud auquel le fichier app.policy appartient.
|
was.policy |
Contient les droits propres à une application d'entreprise WebSphere Application
Server. Ce fichier fait partie d'un
fichier EAR. |
ra.xml |
Contient les droits propres à une application d'entreprise WebSphere Application Server. Ce fichier fait
partie d'un fichier RAR. |
spi.policy |
Contient des droits pour l'interface SPI (Service Provider
Interface) ou les ressources tierces intégrées à WebSphere Application
Server. Par
défaut, tous les droits sont accordés. Mettez à jour ce fichier avec précaution lorsque la cellule requiert
davantage de protection contre l'interface SPI. Ce fichier est appliqué à tous les SPI définis dans le fichier resources.xml. |
library.policy |
Contient les droits de la bibliothèque partagée
des applications d'entreprise. |
filter.policy |
Contient la liste des droits à filtrer dans les
fichiers was.policy et app.policy de la cellule. Ce mécanisme de filtrage s'applique uniquement aux fichiers
was.policy et app.policy. |
Dans WebSphere Application Server, les applications
doivent disposer de droits d'accès appropriés, indiqués dans le fichier
was.policy ou
app.policy aux 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. Le fichier
app.policy s'applique à un noeud défini. Si vous modifiez les droits d'accès dans un fichier
app.policy, vous devez intégrer la nouvelle règle de l'unité d'exécution au même fichier sur les autres noeuds. De même, si vous ajoutez des droits d'accès aux unités d'exécution au fichier
app.policy, vous devez redémarrer WebSphere Application Server pour appliquer les nouveaux droits d'accès. Toutefois, si vous ajoutez des droits d'accès au fichier
was.policy pour une application spécifique, il est inutile de redémarrer 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";
};
Important : Le mot de passe Signed By n'est pas pris en charge dans les fichiers de règles
suivants : app.policy, spi.policy, library.policy, was.policy
et filter.policy. En revanche, il est pris en charge dans les fichiers de règles java.policy, server.policy
et client.policy. Le service JAAS (Java Authentication and Authorization Service) n'est pas pris en charge dans les fichiers app.policy, spi.policy, library.policy, was.policy et filter.policy. Toutefois, le mot clé principal JAAS est pris en charge dans un fichier de règles JAAS lorsqu'il est spécifié par la propriété système de la machine virtuelle Java(JVM) java.security.system propertyauth.policy .
Vous pouvez définir de manière statique les fichiers de règles d'autorisation dans java.security.auth.policy avec auth.policy.url.n=URL, où URL constitue l'emplacement de la règle d'autorisation.
Procédure
- Identifiez le fichier de règles à mettre à jour.
Conseil : Choisissez le fichier de règles ayant la plus petite portée.
Vous n'avez pas besoin d'accorder des droits supplémentaires
aux programmes Java Java et de protéger les ressources. Vous pouvez mettre à
jour le fichier ra.xml ou le fichier was.policy au lieu
du fichier app.policy.
Utilisez les symboles spécifiques aux composants ($(composantEjb),
${composantWeb},${composantConnecteur} et ${jar}) au lieu des
symboles ${application}. Mettez à jour les fichiers de règles dynamiques, plutôt que les fichiers de règles statiques.
Ajoutez tous les droits d'accès que vous n'accorderez jamais à l'application d'entreprise WebSphere Application Server de la cellule au fichier filter.policy.
Voir la rubrique Droits d'accès au fichier filter.policy.
- Redémarrez WebSphere Application Server.
Résultats
Les droits requis sont accordés à l'application
d'entreprise WebSphere Application
Server spécifiée.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
Exemple
Si une application d'entreprise WebSphere Application Server
d'une cellule requiert des droits, certains fichiers de règles dynamiques doivent être mis à jour. 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 d'exception ci-après, qui apparaissent
sur une seule ligne, mais sont scindés en sections pour des raisons de lisibilité.
![[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 cette autorisation est justifié, ajoutez une autorisation à un fichier de règles dynamiques approprié.
![[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";
};
Les lignes d'information précédentes sur les droits d'accès sont scindées à titre d'illustration. Entrez le droit d'accès sur une ligne.
Pour savoir s'il faut ajouter un droit d'accès, voir la rubrique Exception de contrôle d'accès pour la sécurité Java 2.