Exception de contrôle d'accès pour la sécurité Java 2

Le comportement de la sécurité Java™ 2 est défini par les règles de sécurité associées. Les règles de sécurité sont une matrice de contrôle d'accès qui définit les ressources systèmes auxquelles certaines bases de code peuvent accéder et les composants qui doivent les signer. Les règles de la sécurité Java 2 sont déclaratives et appliquées par la méthode java.security.AccessController.checkPermission.

L'exemple ci-après illustre l'algorithme de la méthode java.security.AccessController.checkPermission. Pour consulter l'intégralité de l'algorithme, reportez-vous à l'algorithme de vérification des droits d'accès de la sécurité Java 2 dans la rubrique Sécurité : Ressources pour l'apprentissage.

i = m;
while (i > 0) {
if (caller i's domain does not have the permission)
throw AccessControlException;
else if (caller i is marked as privileged)
return;
i = i - 1;
};

L'algorithme requiert que toutes les classes (ou appelants) de la pile d'appels disposent des droits indiqués lorsqu'une méthode java.security.AccessController.checkPermission est exécutée. Sinon, la requête est refusée et une exception java.security.AccessControlException est générée. Toutefois, si l'appelant est considéré comme privilégié et que la classe (appelant) dispose des droits d'accès, l'algorithme renvoie les données et ne traite pas l'ensemble de la pile d'appels. Les classes suivantes (appelants) n'ont pas besoin des droits d'accès requis.

Une exception java.security.AccessControlException est générée lorsque certaines classes de la pile d'appels ne possèdent pas les droits d'accès requis lors de l'exécution d'une méthode java.security.AccessController.checkPermission. Pour corriger l'exception java.security.AccessControlException, deux solutions sont disponibles :
  • Si l'application appelle une API (Application Programming Interface, interface de programme d'application) protégée par la sécurité Java 2, accordez les autorisations requises aux règles de sécurité Java 2 de l'application. Si l'application n'appelle pas directement des API protégées par la sécurité Java 2, les droits requis résultent d'un effet secondaire liée à des API tiers qui accèdent aux ressources protégées par la sécurité Java 2.
  • Si l'application reçoit le droit requis, son accès est plus étendu que ce qu'il devrait être. Dans ce cas, il est probable que le code tiers qui accède à la ressource protégée par la sécurité Java 2 n'est pas correctement défini comme élément privilégié.

Exemple de pile d'appels

L'exemple ci-après de pile d'appels où le code de l'application utilise une bibliothèque utilitaire d'API tiers pour mettre à jour le mot de passe. L'exemple suivant permet uniquement d'illustrer ce point. La sélection de l'emplacement approprié pour définir le code comme privilégié varie en fonction des applications et des situations. Cette décision requiert une connaissance approfondie du domaine et une maîtrise parfaite des questions de sécurité. Un certain nombre de publications et de manuels sont disponibles sur ce sujet et il est vivement recommandé de s'y reporter pour obtenir des informations plus détaillées.
Dans cet exemple, la pile d'appels indique à quel endroit le code de l'application utilise une bibliothèque d'API tiers pour mettre à jour le mot de passe. L'exemple suivant illustre ce point. Le choix des emplacements où le code sera marqué comme réservé dépend de chaque application et de chaque situation. Cette décision demande de très bien connaître le domaine et la sécurité pour être pertinente.

Vous pouvez faire appel à l'utilitaire PasswordUtil pour redéfinir le mot de passe d'un utilisateur. L'utilitaire entre l'ancien mot de passe et le nouveau mot passe deux fois pour s'assurer que la valeur correcte a été entrée. Si l'ancien mot de passe correspond à celui indiqué dans le fichier de mots de passe, le nouveau mot de passe est stocké et le fichier de mot de passe est mis à jour. Supposons qu'aucun élément de la pile ne soit défini comme étant un élément privilégié. Selon l'algorithme de la méthode java.security.AccessController.checkPermission, l'application échoue sauf si toutes les classes de la pile d'appels disposent de droits write dans le fichier de mots de passe. L'application client n'est pas être autorisée à écrire des données directement dans le fichier de mots de passe ni à le mettre à jour à tout moment.

Toutefois, si la méthode PasswordUtil.updatePasswordFile définit le code qui accède au fichier de mots de passe comme étant privilégié, l'algorithme de vérification des droits d'accès ne contrôle pas les droits requis des classes qui appellent la méthode PasswordUtil.updatePasswordFile tant que la classe PasswordUtil dispose des droits requis. L'application client peut mettre à jour un mot de passe sans accorder l'autorisation nécessaire pour écrire dans le fichier de mots de passe.

La définition du code en tant qu'élément privilégié est une fonction extrêmement souple et puissante. Si cette fonction n'est pas utilisée correctement, la sécurité générale du système peut être compromise et des éléments risquent de ne pas être protégés. Il est nécessaire de l'utiliser avec la plus grande prudence.

Résolution de l'exception java.security.AccessControlException

Comme indiqué précédemment, vous disposez de deux solutions pour corriger une exception java.security.AccessControlException. Etudiez ces solutions au cas par cas afin de déterminer laquelle est la mieux adaptée :
  1. Accorder les droits d'accès manquants à l'application.
  2. Définir une partie du code comme étant privilégiée (après avoir étudié les risques qui peuvent en résulter).

Icône indiquant le type de rubrique Rubrique de concept



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=csec_access
Nom du fichier : csec_access.html