Java 2 Security

La fonctionnalité Sécurité Java™ 2 est prise en charge dans WebSphere Application Server Liberty. Sécurité Java 2 fournit un mécanisme de contrôle d'accès à granularité fine qui accroît l'intégrité totale du système en vérifiant les droits avant d'accorder l'accès à certaines ressources système protégées.

Sécurité Java 2 est indépendant de l'autorisation basée rôle de Java Platform, Enterprise Edition. Sécurité Java 2 protège l'accès aux ressources système telles que les entrées et sorties de fichier, les sockets et les propriétés, tandis que la sécurité de Java Platform, Enterprise Edition protège l'accès aux ressources Web telles que les servlets et les fichiers JSP.

Sécurité Java 2 pour déployeurs et administrateurs

Avant d'activer Sécurité Java 2, vous devez vous assurer que toutes les applications disposent des permissions requises, sinon elles pourraient ne pas s'exécuter. Par défaut, des permissions sont attribuées aux applications d'après la spécification Java Platform, Enterprise Edition 7.0. Si une application n'est pas préparée pour Sécurité Java 2 ou si le fournisseur d'application ne fournit pas un fichier permissions.xml avec l'application, celle-ci peut générer des exceptions de contrôle d'accès Sécurité Java 2 au moment de l'exécution lorsque Sécurité Java 2 est activé. Même si l'application est en cours d'exécution, il est possible qu'elle ne fonctionne pas correctement.

Sécurité Java 2 pour les développeurs d'applications

Les développeurs d'application doivent connaître les permissions accordées dans la stratégie WebSphere par défaut et celles requises par les API du SDK Java. Vous devez déterminer si les API appelées par votre application nécessitent ou non des permissions supplémentaires. Pour plus d'informations sur les API Java requérant des permissions, voir Permissions in the Java 2 SDK.
Les droits sont ajoutés à une application par le biais du fichier permissions.xml, et le codebase associé aux droits répertoriés dépend de l'emplacement du fichier. Pour une application .war autonome, le fichier permissions.xml est regroupé sous le répertoire META-INF et tous les droits spécifiés s'appliquent à tous les modules inclus dans le fichier .war. Pour une application .ear, le fichier permissions.xml est regroupé directement sous le répertoire META-INF pour le fichier .ear lui-même, et les droits spécifiés s'appliquent à tous les modules inclus dans le fichier .ear.
Remarque : Dans le cas d'une application .ear, les fichiers permissions.xml qui sont regroupés sous le répertoire META-INF de tout module autre que le fichier .ear sont ignorés.

[17.0.0.2 and later]Lorsque vous travaillez avec des applications OSGi contenant des bundles d'applications Web (WAB), les autorisations sont ajoutées au moyen du fichier permissions.perm. Si le WAB n'a pas de fichier permissions.perm, java.security.AllPermission est utilisée par défaut.

Activation de Sécurité Java 2

Les fonctions Sécurité Java 2 font partie de l'extension du noyau et elles sont activées au moment de l'amorçage par la mise à jour du fichier bootstrap.properties à l'aide de la propriété websphere.java.security.

Si la propriété websphere.java.security est spécifiée dans le fichier bootstrap.properties, Sécurité Java 2 est imposé ; sinon, aucune vérification des droits n'est effectuée.

Indication de droits d'accès limités

Liberty fournit un mécanisme permettant d'indiquer des droits d'accès restreints lors de l'exécution d'un composant Web ou d'un composant d'application EJB. Des droits d'accès restreints garantissent qu'aucune instance de ces droits n'est accordée à un bundle ou une application. Un mécanisme empêche les applications de s'accorder elles-mêmes des droits autres que ceux qu'elles doivent avoir, par exemple le droit de quitter la machine virtuelle.
Les droits restreints sont spécifiés dans les fichiers server.xml et client.xml. L'exemple ci-après montre comment la propriété PropertyPermission utilisée pour écrire la propriété système os.name est restreinte. Cette syntaxe est identique dans les fichiers server.xml et client.xml :
<javaPermission className="java.security.PropertyPermission" name="os.name" actions="write" restriction="true" />

Octroi de droits

Les bundles OSGi peuvent auto-réguler les droits qui sont octroyés aux bibliothèques/classes au sein de chaque bundle via le fichier permissions.perm.

Les applications peuvent aussi auto-réguler l'octroi des droits via le fichier permissions.xml, ou en spécifiant les octrois de droits dans les fichiers server.xml et client.xml.

Droits du bundle OSGi

La spécification OSGi fournit un mécanisme pour indiquer des droits d'un bundle via le fichier permissions.perm dans le répertoire OSGI-INF de ce bundle. Ce mécanisme permet un contrôle d'accès à granularité fine des droits du bundle.
Le fichier permissions.perm indique le nombre maximum de droits requis par les bundles.
Important : Un fichier permissions.perm vide équivaut à l'absence du fichier permissions.perm. Vérifiez que le fichier permissions.perm n'est pas vide si voulez des droits restreints.

Déclaration de droits dans les fichiers server.xml et client.xml pour les applications

Les droits pour lesquels aucun codebase n'est spécifié, qui sont définis dans les fichiers server.xml et client.xml s'appliquent à toutes les applications présentes sur le serveur Liberty.
Vous pouvez spécifier les droits à octroyer dans les fichiers server.xml et client.xml comme illustré dans l'exemple suivant. Dans cet exemple, la propriété PropertyPermission qui active toutes les propriétés système pour la lecture est accordée :
<javaPermission className="java.util.PropertyPermission"  name="*" actions="read" />
Vous pouvez indiquer les droits à restreindre dans les fichiers server.xml et client.xml. L'exemple ci-après montre comment la propriété PropertyPermission utilisée pour écrire la propriété système os.name est restreinte. Cette syntaxe est identique dans les fichiers server.xml et client.xml :
<javaPermission className="java.security.PropertyPermission" name="os.name" actions="write" restriction="true" />
Notes :
  • Pour un droit restreint, restriction est défini sur true.
  • Si une application essaie de s'octroyer elle-même un droit qui est défini comme droit restreint, le droit restreint est prioritaire sur cet octroi et il ne l'autorise pas.

Déclaration de droits dans le fichier permissions.xml pour les applications

Le fichier permissions.xml est un nouveau fichier introduit par la spécification Java EE7. Il est fourni sous le répertoire META-INF d'une application.

Pour les applications fournis en tant que fichier .war autonome, les droits qui sont spécifiés au niveau de META-INF WAR s'appliquent à tous les modules et à toutes les bibliothèques qui sont fournis au sein du fichier .war.

Pour les applications qui sont des packages d'un fichier .ear, la déclaration de droits doit figurer au niveau du fichier .ear. Cet ensemble de droits s'applique à tous les modules et à toutes les bibliothèques qui sont fournis au sein du fichier .ear ou des modules qu'il contient. Tout fichier permissions.xml fourni sans ces modules est ignoré, qu'un fichier permissions.xml soit ou non fourni pour le fichier .ear lui-même.

Pour les applications fournies das un fichier .rar, la déclaration de droits doit figurer au niveau de META-INF RAR.

Option no-rethrow

Lorsque la sécurité Java 2 est activée, le gestionnaire de sécurité du JDK renvoie par défaut une exception java.security.AccessControl en cas de violation des permissions. Si l'exception n'est pas traitée, elle peut entraîner une défaillance de l'environnement d'exécution. Une option no-rethrow est disponible pour aider les développeurs lors de la préparation de leurs applications pour Java 2 Security. L'option no-rethrow permet de consigner l'exception AccessControl dans les fichiers console.log et messages.log mais elle ne provoque pas de défaillance des applications. L'option no-rethrow est activée par l'indication de websphere.java.security.norethrow=true dans le fichier bootstrap.properties. L'option no-rethrow n'est pas activée par défaut,vous devez donc activer cette propriété en l'indiquant dans le fichier bootstrap.properties.
Remarque : Comme cette propriété ne permet pas au gestionnaire de sécurité de renvoyer l'exception, du point de vue technique il n'applique pas la sécurité Java 2. L'option no-rethrow ne doit pas être utilisée dans un environnement de production.

Mises à jour dynamiques

Les mises à jour dynamiques des fichiers de droits, tels que permissions.perm, permissions.xml, server.xml et client.xml ne sont pas prises en charge. Pour les mises à jour de droits, le serveur Liberty doit être redémarré.

Icône indiquant le type de rubrique Rubrique de concept

Nom du fichier : cwlp_java2security.html