Migration de la stratégie de sécurité Java 2
Cette rubrique fournit une aide pour la migration de la stratégie de sécurité Java™ 2.
Pourquoi et quand exécuter cette tâche
Versions précédentes de WebSphere Application Server
WebSphere Application Server utilise le gestionnaire de sécurité Java 2 dans l'environnement d'exécution du serveur pour empêcher les applications d'entreprise d'appeler les méthodes System.exit et System.setSecurityManager. Ces deux API Java ont des effets indésirables lorsqu'elles sont appelées par des applications d'entreprise. L'API System.exit, par exemple, provoque l'arrêt prématuré de la machine virtuelle Java, ce qui n'est pas recommandé pour le serveur d'applications.
Pour prendre correctement en charge la sécurité Java 2, l'intégralité de l'exécution du serveur doit être marquée comme privilégiée (les appels de l'API doPrivileged étant insérés aux emplacements corrects) et doit identifier les ensembles de droits ou les règles par défaut). Le code de l'application n'est pas privilégié et dépend des stratégies définies dans les fichiers de règles. L'instrumentation doPrivileged est importante et nécessaire pour la prise en charge de la sécurité Java 2. Sans cette instrumentation, vous devez accorder au code d'application les droits requis par le module d'exécution du serveur. Cette situation est due à la conception et à l'algorithme utilisé par la sécurité Java 2 pour appliquer les vérifications des droits d'accès. Reportez-vous à l'algorithme des droits d'accès de vérification de la sécurité Java 2.
- java.lang.RuntimePermission(exitVM)
- java.lang.RuntimePermission(setSecurityManager)
Ces droits d'accès sont refusés au code de l'application, quel que soit le contenu de la stratégie de sécurité Java 2. Toutefois, ces droits d'accès sont accordés à l'exécution du serveur. Aucune autre vérification de droit n'est appliquée.
- java.net.SocketPermission
- java.net.NetPermission
Toutefois, le module d'exécution du serveur du produit n'est pas entièrement marqué correctement comme privilégié. Vous devez accorder au code de l'application tous les droits (et non pas seulement les deux spécifiés précédemment) pour que l'application d'entreprise puisse être exécutée correctement. Cette stratégie de sécurité Java 2 pour les applications d'entreprise est très souple.
Nouveautés
La sécurité Java 2 est totalement prise en charge dans WebSphere Application Server, ce qui signifie que tous les droits sont appliqués. La stratégie de sécurité Java 2 par défaut pour l'application d'entreprise constitue l'ensemble de droits recommandés définis par la spécification Java Platform, Enterprise Edition (Java EE) version 1.4. Voir le fichier racine_profil/config/cells/nom_cellule/nodes/nom_noeud/app.policy pour en savoir plus sur la stratégie de sécurité Java 2 par défaut qui est attribuée aux applications d'entreprise. Cette stratégie est beaucoup plus stricte que celles des versions précédentes.
Toutes les stratégies sont déclaratives. Le gestionnaire de sécurité du produit gère toutes les stratégies déclarées dans les fichiers de règles. Il existe une exception à cette règle : l'accès aux droits déclarés dans le fichier racine_profil/config/cells/nom_cellule/filter.policy est refusé aux applications d'entreprise.
N'utilisez pas la permission setSecurityManager dans le code d'application pour définir un gestionnaire de sécurité. Lorsqu'une application utilise la permission setSecurityManager, cela provoque un conflit avec le gestionnaire de sécurité interne de WebSphere Application Server. Si vous devez définir un gestionnaire de sécurité dans une application pour des raisons de RMI, vous devez également activer l'option Utiliser la sécurité Java 2 pour limiter l'accès aux applications par les ressources locales dans la page Sécurité globale dans la console d'administration de WebSphere Application Server. WebSphere Application Server enregistre alors un gestionnaire de sécurité. Le code d'application peut vérifier si ce gestionnaire de sécurité est enregistré à l'aide de l'API System.getSecurityManager().
Migration des propriétés système
- java.security.policy. Chemin absolu du fichier de règles (action requise). Cette propriété système contient les droits système (droits accordés à la machine Java Virtual Machine [JVM] et au module d'exécution serveur du produit) et les droits d'application d'entreprise. Migrez la stratégie de sécurité Java 2 de l'application d'entreprise vers Version 9.0. Pour la migration de la stratégie de sécurité Java 2, reportez-vous à la procédure de migration de la stratégie de sécurité Java 2.
- enableJava2Security. Permet d'activer la mise en application de la sécurité Java 2 (aucune action requise). Cette propriété du système est obsolète ; un indicateur dans l'API de configuration WebSphere permet de contrôler s'il est nécessaire d'activer la sécurité Java 2. Activez cette option via la console d'administration.
- was.home. Etendu au répertoire d'installation de WebSphere Application Server (une action peut être requise). Cette propriété système est déconseillée et remplacée par les propriétés ${user.install.root} et ${was.install.root}. Si le répertoire contient des données propres à l'instance, ${user.install.root} est utilisée ; sinon ${was.install.root} est utilisée. Ces propriétés peuvent être utilisées indifféremment pour les environnements WebSphere Application Server ou WebSphere Application Server, Network Deployment. Reportez-vous à la procédure de migration des stratégies de sécurité Java 2.
Migration de la stratégie de sécurité Java 2
Il n'existe pas de méthode simple pour migrer automatiquement le fichier de règles Java vers Version 9.0. Cela est dû au fait que des droits système et des droits d'application coexistent dans le même fichier de règles. Copiez manuellement la stratégie de sécurité Java 2 des applications d'entreprise dans un fichier was.policy ou app.policy. Toutefois, la migration de la stratégie de sécurité Java 2 vers un fichier was.policy représente la meilleure méthode car les symboles ou l'attribut code relatif sont utilisés à la place de l'attribut code absolu. Cela a de nombreux avantages. Accordez les droits définis dans le fichier was.policy uniquement à une application d'entreprise spécifique, et les droits définis dans le fichier app.policy à toutes les applications d'entreprise exécutées sur le noeud auquel le fichierapp.policy appartient.
Pour plus d'informations sur la gestion des stratégies, voir Fichiers de règles de sécurité Java 2.
L'exemple ci-après illustre la migration d'une stratégie de sécurité Java 2 à partir d'une version antérieure. Il comprend le fichier de règles de la sécurité Java 2 de l'application d'entreprise app1.ear et les droits d'accès système, droits accordés à la machine JVM (Java virtual machine) et à l'environnement d'exécution du serveur.
L'emplacement par défaut du fichier de règles de sécurité Java 2 est racine_profil/properties/java.policy.
Les droits par défaut sont omis pour plus
de clarté :
L'emplacement par défaut du fichier de règles de sécurité Java 2 est racine_profil/properties/java.policy.
Les droits par défaut sont omis pour plus
de clarté :
// Pour les exemples de produit
grant codeBase "file:${racine_serveur_app}/installedApps/app1.ear/-" {
permission java.security.SecurityPermission "printIdentity";
permission java.io.FilePermission "${racine_serveur_app}${/}temp${/}fichier.txt",
"read";
};
Dans un souci de clarté, tous les droits d'accès indiqués dans cet exemple sont migrés au niveau de l'application. Toutefois, vous pouvez accorder des droits d'accès à un niveau plus granulaire au niveau de composant (Web, beans enterprise, connecteur ou fichier JAR (Java) d'utilitaire) ou à un composant spécifique.