Sécurité Java 2

La fonctionnalité Java™ 2 Security est prise en charge dans WebSphere® Application Server Liberty. La sécurité Java 2 fournit un mécanisme de contrôle d'accès à granularité fine basé sur des règles qui augmente l'intégrité globale du système en vérifiant les droits d'accès avant d'autoriser l'accès à certaines ressources système protégées.

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

Java 2 Security pour les déployeurs et les administrateurs

Avant d'activer la sécurité Java 2, vous devez vous assurer que toutes les applications disposent des droits requis, sinon les applications risquent de 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 la sécurité Java 2 ou si le fournisseur d'application ne fournit pas de fichier permissions.xml dans le cadre de l'application, l'application peut générer des exceptions de contrôle d'accès Java 2 Security lors de l'exécution lorsque la sécurité Java 2 est activée. 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'applications 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 qui requièrent des droits d'accès, voir Droits d'accès dans le SDK Java 2.
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 dans le répertoire META-INF de tout module autre que .ear sont ignorés.

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 , la règle par défaut est java.security.AllPermission.

Activation de la sécurité Java 2

Les fonctions de sécurité Java 2 font partie de l'extension du noyau et sont activées lors de l'amorçage en mettant à jour le fichier bootstrap.properties avec la propriété websphere.java.security .

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

Indication de droits d'accès limités

Liberty fournit un mécanisme permettant de spécifier des droits restreints lorsqu'il exécute un composant d'application Web ou 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 n'est pas équivalent à aucun 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 d'accès sans codebase spécifié, qui sont définis dans les fichiers server.xml et client.xml , s'appliquent à toutes les applications sur ce 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" />
Remarques :
  • 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: Etant donné que cette propriété n'autorise pas le gestionnaire de sécurité à émettre l'exception, le gestionnaire de sécurité n'applique techniquement 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. Les mises à jour des droits d'accès nécessitent un redémarrage du serveur Liberty .