Erreurs à la suite de l'activation de la sécurité

Utilisez ces informations si vous rencontrez des erreurs après l'activation de la sécurité.

Remarque : Cette rubrique fait référence à un ou plusieurs des fichiers journaux de serveur d'applications. Il est recommandé de configurer le serveur de telle sorte qu'il utilise l'infrastructure de journalisation et de trace HPEL (High Performance Extensible Logging) à la place des fichiers SystemOut.log, SystemErr.log, trace.log et activity.log sur les systèmes distribués et IBM® i. Vous pouvez également utiliser HPEL conjointement avec vos fonctions de journalisation z/OS natives. Si vous utilisez l'infrastructure HPEL, vous pouvez accéder à toutes les informations de journalisation et de trace en utilisant l'outil de ligne de commande LogViewer à partir de votre répertoire bin de profil de serveur. Pour plus d'informations sur l'utilisation de HPEL, voir les informations sur l'utilisation de HPEL en vue du traitement des incidents liés aux applications.
Type d'erreur signalée

[AIX Solaris HP-UX Linux Windows][IBM i]Pour des conseils d'ordre général sur le diagnostic et la résolution des incidents liés à la sécurité, voir Résolution des incidents liés au composant de sécurité.

Le service de support IBM dispose de documents et d'outils qui peuvent vous aider à collecter plus rapidement les informations dont vous avez besoin pour résoudre votre incident. Avant d'ouvrir un rapport d'incident, consultez la page du service de support :

Erreur d'authentification lors de l'accès à une page Web

Les causes possibles des erreurs d'authentification sont les suivantes :
  • Nom d'utilisateur ou mots de passe incorrects. Vérifiez la validité du nom d'utilisateur et du mot de passe.
  • Erreur de configuration de la sécurité : Le type du registre des utilisateurs n'est pas correctement défini. Vérifier la propriété Registre des utilisateurs dans sécurité administrative les paramètres de sécurité globale de la console d'administration. Assurez-vous que la propriété Registre des utilisateurs indiquée est correct.
  • Erreur programme interne. Si l'application client est un programme Java™ autonome, il est possible qu'elle ne regroupe pas ou n'envoie pas correctement les données d'identification.

[AIX Solaris HP-UX Linux Windows][IBM i]Si la configuration du registre des utilisateurs, l'ID utilisateur et le mot de passe semblent corrects, utilisez la fonction de trace de WebSphere Application Server pour déterminer la cause de l'incident. Pour activer le traçage de sécurité, utilisez la spécification de traçage com.ibm.ws.security.*=all=enabled.

Erreur d'autorisation lors de l'accès à une page Web

Lorsqu'un utilisateur ne peut pas accéder à une ressource à laquelle il devrait pouvoir accéder, cela signifie que l'une des procédures de configuration n'a probablement pas été effectuée. Reportez-vous à la rubrique Autorisation de l'accès pour des rôles d'administration.

et plus particulièrement :
  • Vérifiez les rôles requis pour la ressource Web contactée.
  • Contrôlez la table d'autorisation et assurez-vous que l'utilisateur ou le groupe auquel appartient l'utilisateur détient l'un des rôles requis.
  • Visualisez les rôles requis pour la ressource Web dans le descripteur de déploiement associé.
  • Consultez la table d'autorisation de l'application contenant la ressource Web à l'aide de la console d'administration.
  • Essayez d'utiliser une identité possédant les rôles requis pour vérifier si cet utilisateur peut accéder aux ressources qui posent problème.
  • Si vous devez accorder à l'utilisateur un ou plusieurs des rôles requis, utilisez la console d'administration pour effectuer cette opération, puis arrêtez et redémarrez l'application.

[AIX Solaris HP-UX Linux Windows][IBM i]Si l'utilisateur détient les rôles requis, mais qu'il ne peut toujours pas accéder aux ressources sécurisées, activez le traçage de la sécurité, à l'aide de la spécification de trace com.ibm.ws.security.*=all=enabled. Collectez les données de trace pour obtenir des informations complémentaires.

L'authentification échoue lorsque les pages de codes sont différentes entre le client et le serveur

Lorsqu'un client utilise une page de codes différente de celle du serveur et que des caractères non US-ASCII sont utilisés pour l'ID utilisateur et le mot de passe lors d'une authentification standard, le connexion échoue. L'en-tête HTTP n'inclut pas les informations de méthode de codage nécessaires pour convertir les données codées, de telle sorte que le serveur ne sait pas comment décoder correctement les informations.
Utilisez un formulaire de connexion reposant sur des paramètres POST qui sont dans le texte de corps HTML. Le codage du texte est envoyé par le navigateur et peut alors être décodé correctement.
Remarque : Les clients de services Web ne sont pas capables d'utiliser la connexion par formulaire pour résoudre ce problème. Les utilisateurs doivent s'assurer que les pages de codes sont cohérentes entre le client et le serveur.

Message d'erreur : CWSCJ0314E: La stratégie de sécurité Java 2 actuelle a signalé une violation potentielle sur le serveur

Si vous trouvez sur votre serveur des erreurs similaires à :
Message d'erreur : CWSCJ0314E: La stratégie de sécurité Java 2 en cours
a signalé une violation potentielle 
des droits
d'accès Java 2. Pour plus d'informations, reportez-vous au guide d'identification des incidents.
{0}Droits/:{1}Code/:{2}{3}Trace de pile/:{4}Emplacement de base du code/:{5}
La méthode checkPermission du gestionnaire de sécurité Java a signalé une exception SecurityException.

L'exception signalée peut être critique pour le système sécurisé. Activez le traçage de la sécurité pour déterminer le code ayant éventuellement violé la stratégie de sécurité. Une fois le code fautif détecté, vérifiez si l'opération tentée est autorisée par la sécurité Java 2 en examinant tous les fichiers de règles de sécurité Java 2 applicables ainsi que le code d'application.

Vous pouvez obtenir un rapport plus détaillé en configurant le traçage RAS en mode débogage ou en définissant une propriété Java.
  • [AIX Solaris HP-UX Linux Windows][IBM i]Reportez-vous à la rubrique relative à l'activation du traçage pour obtenir les instructions requises pour configurer le traçage RAS (Reliability Availability Serviceability) en mode débogage, ou
  • Spécifiez la propriété suivante dans le panneau Serveurs > Types de serveurs > Serveurs d'application WebSphere > nom_serveur > Gestion des processus et Java > Définition des processus > Machine virtuelle Java dans le panneau Arguments JVM génériques de la console d'administration :
    • Ajoutez l'option d'exécution java.security.debug
    • Valeurs admises :
      access
      Affiche toutes les informations de débogage, y compris les droits requis, le code, la pile et l'emplacement de la base de code.
      stack
      Affiche les informations de débogage, y compris le droit requis, le code et la pile.
      échec
      Affiche les informations de débogage, y compris le droit requis et le code.

Pour une description des règles de sécurité Java, reportez-vous à la documentation Java 2 Security sur le site http://www.ibm.com/developerworks/java/jdk/security/

Conseil : Si l'application s'exécute avec une interface de programmation d'application (API) Java Mail, ce message n'a probablement aucun caractère de gravité. Vous pouvez actualiser le fichier racine application Enterprise installée/META-INF/was.policy afin d'accorder à l'application les droits suivants :
  • permission java.io.FilePermission "${user.home}${/}.mailcap", "read";
  • permission java.io.FilePermission "${user.home}${/}.mime.types", "read";
  • permission java.io.FilePermission "${java.home}${/}lib${/}mailcap", "read";
  • permission java.io.FilePermission "${java.home}${/}lib${/}mime.types", "read";

Affichage du message d'erreur CWMSG0508E : Le service de sécurité du serveur JMS n'a pas pu authentifier l'ID utilisateur :" dans le fichier journal SystemOut.log au démarrage d'un serveur d'applications

Cette erreur survient lorsque vous installez l'exemple API de JMS (Java Message Service) et que vous activez ensuite la sécurité. Vous pouvez suivre les instructions de la page de configuration et d'exécution, dans la documentation correspondante sur l'exemple JMS, pour configurer l'exemple de sorte qu'il fonctionne avec la sécurité WebSphere Application Server.

Vous pouvez vérifier l'installation de l'exemple de bean MDB (Message-Driven Bean) en lançant le programme d'installation, puis en sélectionnant Personnaliser, et en examinant les composants déjà installés dans la fenêtre Sélectionner les composants à installer. L'exemple de JMS est présenté en tant qu'Exemple de MDB sous Embedded Messaging.

Vous pouvez également procéder à la vérification de l'installation en utilisant la console d'administration pour ouvrir les propriétés du serveur d'applications contenant les exemples. Sélectionnez MDBSamples, puis cliquez sur Désinstaller.

Affichage du message d'erreur CWSCJ0237E : Un ou plusieurs des principaux attributs de configuration de LTPAServerObject sont null ou non disponibles après activation de la sécurité et démarrage du serveur d'applications

Cette erreur peut survenir lorsque vous sélectionnez LTPA (Lightweight Third Party Authentication) comme mécanisme d'authentification, sans générer les clés LTPA. Les clés LTPA sont utilisées pour le chiffrement du jeton LTPA.

Pour résoudre l'incident, procédez comme suit :
  1. Cliquez sur Sécurité > Sécurité globale > Authentification > Mécanismes d'authentification et expiration > LTPA.
  2. Entrez un mot de passe quelconque.
  3. Entrez le même mot de passe dans la zone Confirmation du mot de passe.
  4. Cliquez sur Appliquer.
  5. Cliquez sur Génération de clés.
  6. Cliquez sur Sauvegarder.

L'exception AccessControlException est signalée dans le fichier SystemOut.log

Cet incident est lié au composant Sécurité Java 2 de WebSphere Application Server, la structure de sécurité de niveau API implémentée dans WebSphere Application Server. Une exception similaire à celle spécifiée ci-après s'affiche. Le message d'erreur et le numéro peuvent varier.
[AIX Solaris HP-UX Linux Windows]
CWSRV0020E: [Servlet Error]-[validator]: Failed to load servlet: 
java.security.AccessControlException: access denied 
(java.io.FilePermission 
app_server_root/systemApps/isclite.ear/isclite.war/WEB-INF/validation.xml read) 
[z/OS]
CWSRV0020E: [Servlet Error]-[validator]: Failed to load servlet: 
java.security.AccessControlException: access denied  
(java.io.FilePermission 
/WebSphere/V6R1M0/AppServer/systemApps/isclite.ear/isclite.war/WEB-INF/validation.xml read)
[IBM i]
CWSRV0020E: [Servlet Error]-[validator]: Failed to load servlet: 
java.security.AccessControlException: access denied  
(java.io.FilePermission 
app_server_root/systemApps/isclite.ear/isclite.war/WEB-INF/validation.xml read)

[AIX Solaris HP-UX Linux Windows][IBM i]Vous trouverez des explications sur la sécurité Java 2, sur les modalités et les raisons de son activation ou de sa désactivation, sur ses rapports avec les fichiers de stratégie et la manière de modifier ces fichiers, dans la rubrique Sécurité Java 2 du centre de documentation. Vous y apprendrez que la sécurité Java 2 n'est pas uniquement utilisée par ce produit mais elle peut également être implémentée par les développeurs d'applications. Les administrateurs pourront être amenés à solliciter les développeurs lorsque cette exception est créée alors qu'un client tente d'accéder à une ressource hébergée par WebSphere Application Server.

Les causes possibles de ces erreurs comprennent :
  • Erreurs de syntaxe dans un fichier de stratégie.
  • Erreurs de syntaxe dans des spécifications de droits d'accès du fichier ra.xml regroupées dans un fichier .rar. Ce cas s'applique aux adaptateurs de ressources qui prennent en charge l'accès connecteur à CICS ou à d'autres ressources.
  • Le droit d'accès requis par une application ne figure pas dans un fichier de stratégie ou dans les spécifications de droits d'accès du fichier ra.xml regroupées dans un fichier .rar
  • Le chemin d'accès aux classes n'est pas défini correctement, ce qui empêche la création des droits d'accès au fichier resource.xml de SPI (Service Provider Programming Interface).
  • Un bloc doPrivileged prenant en charge l'accès à une ressource est manquant dans une bibliothèque appelée par une application, ou dans l'application.
  • Le droit d'accès n'est pas spécifié dans le fichier de stratégie approprié.
Pour résoudre ces incidents, procédez comme suit :
  • Vérifiez dans tous les fichiers de stratégie associés si le droit d'accès désigné dans l'exception, par exemple java.io.FilePermission, est spécifié.
  • Recherchez une exception ParserException associée dans le fichier SystemOut.log donnant des détails sur l'erreur de syntaxe.
    [AIX Solaris HP-UX Linux Windows]Exemple :
    CWSCJ0189E: Caught ParserException while creating template for application policy
    
    profile_root/config/cells/cell_name/nodes/node_name/app.policy
    [z/OS]
    CWSCJ0189E: Caught ParserException while creating template for application policy
    
    /WebSphere/V6R1M0/AppServer1/profiles/profile_name/config/cells/cell_name/nodes/node_name/app.policy.
    [IBM i]
    CWSCJ0189E: Caught ParserException while creating template for application policy
    
    profile_root/config/cells/cell_name/nodes/node_name/app.policy
    Où :
    • [z/OS]V6R1M0 représente la version de WebSphere Application Server que vous utilisez.
    • nom_cellule représente le nom de la cellule.
    • nom_profil représente le nom de votre profil.
    • nom_noeud représente le nom de votre noeud.
    L'exception est la suivante : com.ibm.ws.security.util.ParserException: line 18: attendu ';', rencontré 'grant'
  • Recherchez un message similaire à : CWSCJ0325W : Le droit d'accès droit d'accès indiqué dans le fichier de stratégie n'est pas résolu.
  • Vérifiez dans la pile d'appels quelle méthode ne détient pas le droit d'accès. Identifiez le chemin d'accès aux classes de cette méthode. Si vous éprouvez des difficultés à identifier la méthode, activez l'option Rapport de sécurité Java2.
    • [AIX Solaris HP-UX Linux Windows][IBM i]Configuration du traçage RAS en indiquant com.ibm.ws.security.core.*=all=enabled, ou une propriété Java property.java.security.debug. Les valeurs autorisées pour la propriété java.security.debug sont les suivantes :
      access
      Imprimez toutes les informations de débogage, y compris : autorisation requise, code, pile et emplacement du code.
      stack
      Imprimez les informations de débogage, y compris : autorisation requise, code et pile.
      échec
      Imprimez les informations de débogage, y compris : autorisation requise et code.
    • Le rapport affiche :
      Droit d'accès
      Le droit d'accès manquant.
      Code
      La méthode qui pose problème.
      Trace de pile
      L'emplacement où s'est produite la violation d'accès.
      Emplacement du code
      Détail de chaque cadre de pile.
      [AIX Solaris HP-UX Linux Windows]En général, le droit d'accès et le code suffisent à identifier l'incident. L'exemple suivant illustre un rapport :
      Permission: 
      app_server_root/logs/server1/SystemOut_02.08.20_11.19.53.log : 
      access denied (java.io.FilePermission 
      app_server_root/logs/server1/SystemOut_02.08.20_11.19.53.log delete) 
      
      Code: 
       com.ibm.ejs.ras.RasTestHelper$7  in  
      {file:app_server_root/installedApps/app1/JrasFVTApp.ear/RasLib.jar
      } 
      
      Stack Trace: 
      
      java.security.AccessControlException: access denied (java.io.FilePermission 
      app_server_root/logs/server1/SystemOut_02.08.20_11.19.53.log delete
      ) 
              at java.security.AccessControlContext.checkPermission
                                    (AccessControlContext.java(Compiled Code)) 
              at java.security.AccessController.checkPermission
                                    (AccessController.java(Compiled Code))
              at java.lang.SecurityManager.checkPermission
                                    (SecurityManager.java(Compiled Code)) 
                                     . 
      Code Base Location: 
      
      com.ibm.ws.security.core.SecurityManager : 
      file:/app_server_root/plugins/com.ibm.ws.runtime_6.1.0.jar
      
        ClassLoader: com.ibm.ws.bootstrap.ExtClassLoader 
        Permissions granted to CodeSource 
      (file:/app_server_root/plugins/com.ibm.ws.runtime_6.1.0.jar <no certificates>
      
        { 
          (java.util.PropertyPermission java.vendor read); 
          (java.util.PropertyPermission java.specification.version read); 
          (java.util.PropertyPermission line.separator read); 
          (java.util.PropertyPermission java.class.version read); 
          (java.util.PropertyPermission java.specification.name read); 
          (java.util.PropertyPermission java.vendor.url read); 
          (java.util.PropertyPermission java.vm.version read); 
          (java.util.PropertyPermission os.name read); 
          (java.util.PropertyPermission os.arch read); 
         } 
         ( This list continues.)
      [z/OS]
      Permission: 
      /WebSphere/AppServer/logs/server1/SystemOut_02.08.20_11.19.53.log : 
      access denied (java.io.FilePermission 
      WebSphere/AppServer/logs/server1/SystemOut_02.08.20_11.19.53.log delete) 
      
      Code: 
       com.ibm.ejs.ras.RasTestHelper$7  in  
      {file:/WebSphere/AppServer/installedApps/app1/JrasFVTApp.ear/RasLib.jar} 
      
      Stack Trace: 
      
      java.security.AccessControlException: access denied (java.io.FilePermission 
      
      /WebSphere/AppServer/logs/server1/SystemOut_02.08.20_11.19.53.log delete) 
              at java.security.AccessControlContext.checkPermission
                                    (AccessControlContext.java(Compiled Code)) 
              at java.security.AccessController.checkPermission
                                    (AccessController.java(Compiled Code))
              at java.lang.SecurityManager.checkPermission
                                    (SecurityManager.java(Compiled Code)) 
                                     . 
      Code Base Location: 
      
      com.ibm.ws.security.core.SecurityManager : 
      
      file:/WebSphere/AppServer/lib/securityimpl.jar
        ClassLoader: com.ibm.ws.bootstrap.ExtClassLoader 
        Permissions granted to CodeSource 
      (file:/WebSphere/AppServer/lib/securityimpl.jar <no certificates>
        { 
          (java.util.PropertyPermission java.vendor read); 
          (java.util.PropertyPermission java.specification.version read); 
          (java.util.PropertyPermission line.separator read); 
          (java.util.PropertyPermission java.class.version read); 
          (java.util.PropertyPermission java.specification.name read); 
          (java.util.PropertyPermission java.vendor.url read); 
          (java.util.PropertyPermission java.vm.version read); 
          (java.util.PropertyPermission os.name read); 
          (java.util.PropertyPermission os.arch read); 
         } 
         ( This list continues.)
      [IBM i]
      Permission: 
      profile_root/logs/server1/SystemOut_02.08.20_11.19.53.log : 
      access denied (java.io.FilePermission 
      profile_root/logs/server1/SystemOut_02.08.20_11.19.53.log delete) 
      
      Code: 
       com.ibm.ejs.ras.RasTestHelper$7  in  
      {file:profile_root/installedApps/app1/JrasFVTApp.ear/RasLib.jar
      } 
      
      Stack Trace: 
      
      java.security.AccessControlException: access denied (java.io.FilePermission 
      profile_root/logs/server1/SystemOut_02.08.20_11.19.53.log delete
      ) 
              at java.security.AccessControlContext.checkPermission
                                    (AccessControlContext.java(Compiled Code)) 
              at java.security.AccessController.checkPermission
                                    (AccessController.java(Compiled Code))
              at java.lang.SecurityManager.checkPermission
                                    (SecurityManager.java(Compiled Code)) 
                                     . 
      Code Base Location: 
      
      com.ibm.ws.security.core.SecurityManager : 
      file:app_server_root/plugins/com.ibm.ws.runtime_6.1.0.jar
      
        ClassLoader: com.ibm.ws.bootstrap.ExtClassLoader 
        Permissions granted to CodeSource 
      (file:app_server_root/plugins/com.ibm.ws.runtime_6.1.0.jar <no certificates>
        { 
          (java.util.PropertyPermission java.vendor read); 
          (java.util.PropertyPermission java.specification.version read); 
          (java.util.PropertyPermission line.separator read); 
          (java.util.PropertyPermission java.class.version read); 
          (java.util.PropertyPermission java.specification.name read); 
          (java.util.PropertyPermission java.vendor.url read); 
          (java.util.PropertyPermission java.vm.version read); 
          (java.util.PropertyPermission os.name read); 
          (java.util.PropertyPermission os.arch read); 
         } 
         ( This list continues.)
      Permission: 
      profile_root/logs/server1/SystemOut_02.08.20_11.19.53.log : 
      access denied (java.io.FilePermission 
      profile_root/logs/server1/SystemOut_02.08.20_11.19.53.log delete) 
      
      Code: 
       com.ibm.ejs.ras.RasTestHelper$7  in  
      {file:profile_root/installedApps/app1/JrasFVTApp.ear/RasLib.jar} 
      
      Stack Trace: 
      
      java.security.AccessControlException: access denied (java.io.FilePermission 
      
      profile_root/logs/server1/SystemOut_02.08.20_11.19.53.log delete) 
              at java.security.AccessControlContext.checkPermission
                                    (AccessControlContext.java(Compiled Code)) 
              at java.security.AccessController.checkPermission
                                    (AccessController.java(Compiled Code))
              at java.lang.SecurityManager.checkPermission
                                    (SecurityManager.java(Compiled Code)) 
                                     . 
      Code Base Location: 
      
      com.ibm.ws.security.core.SecurityManager : 
      
      file:app_server_root/plugins/com.ibm.ws.runtime_6.1.0.jar
        ClassLoader: com.ibm.ws.bootstrap.ExtClassLoader 
        Permissions granted to CodeSource 
      (file:app_server_root/plugins/com.ibm.ws.runtime_6.1.0.jar <no certificates>
        { 
          (java.util.PropertyPermission java.vendor read); 
          (java.util.PropertyPermission java.specification.version read); 
          (java.util.PropertyPermission line.separator read); 
          (java.util.PropertyPermission java.class.version read); 
          (java.util.PropertyPermission java.specification.name read); 
          (java.util.PropertyPermission java.vendor.url read); 
          (java.util.PropertyPermission java.vm.version read); 
          (java.util.PropertyPermission os.name read); 
          (java.util.PropertyPermission os.arch read); 
         } 
         ( This list continues.)
      Permission: 
      profile_root
      /logs/server1/SystemOut_02.08.20_11.19.53.log : 
      access denied (java.io.FilePermission 
      profile_root
      /logs/server1/SystemOut_02.08.20_11.19.53.log delete) 
      
      Code: 
       com.ibm.ejs.ras.RasTestHelper$7  in  
      {file:profile_root
      /installedApps/app1/JrasFVTApp.ear/RasLib.jar} 
      
      Stack Trace: 
      
      java.security.AccessControlException: access denied (java.io.FilePermission 
      
      profile_root
      /logs/server1/SystemOut_02.08.20_11.19.53.log delete) 
              at java.security.AccessControlContext.checkPermission
                                    (AccessControlContext.java(Compiled Code)) 
              at java.security.AccessController.checkPermission
                                    (AccessController.java(Compiled Code))
              at java.lang.SecurityManager.checkPermission
                                    (SecurityManager.java(Compiled Code)) 
                                     . 
      Code Base Location: 
      
      com.ibm.ws.security.core.SecurityManager : 
      
      file:app_server_root/plugins/com.ibm.ws.runtime_6.1.0.jar
        ClassLoader: com.ibm.ws.bootstrap.ExtClassLoader 
        Permissions granted to CodeSource 
      (file:app_server_root/plugins/com.ibm.ws.runtime_6.1.0.jar <no certificates>
        { 
          (java.util.PropertyPermission java.vendor read); 
          (java.util.PropertyPermission java.specification.version read); 
          (java.util.PropertyPermission line.separator read); 
          (java.util.PropertyPermission java.class.version read); 
          (java.util.PropertyPermission java.specification.name read); 
          (java.util.PropertyPermission java.vendor.url read); 
          (java.util.PropertyPermission java.vm.version read); 
          (java.util.PropertyPermission os.name read); 
          (java.util.PropertyPermission os.arch read); 
         } 
         ( This list continues.)
      Où :
      • app1 représente le nom de votre application.
      • app_server_root represents the installation root directory for WebSphere Application ServerWebSphere Application Server, Network Deployment.
      • racine_profil représente l'emplacement et le nom d'un profil particulier de votre système.
      • profile1 ou la variable nom_profil représente le nom de votre profil.
      • server1 ou la variable nom_serveur représente le nom de votre serveur d'applications.
  • Si la méthode est SPI, vérifiez dans le fichier resources.xml si le chemin d'accès aux classes est correct.
  • Pour confirmer que tous les fichiers de stratégie sont correctement chargés ou quel droit d'accès a été accordé à chaque chemin d'accès aux classes, activez le traçage avec com.ibm.ws.security.policy.*=all=enabled. Tous les droits d'accès chargés sont répertoriés dans le fichier trace.log. Recherchez les fichiers app.policy,was.policy et ra.xml. Pour vérifier la liste des droits d'accès d'un chemin d'accès aux classes, recherchez la Stratégie en vigueur pour chemin d'accès aux classes.
  • Si le fichier de stratégie ou le fichier ra.xml contiennent des erreurs de syntaxe, corrigez-les avec l'outil policytool. Evitez de modifier la stratégie manuellement, sous peine d'erreurs de syntaxe.

  • Un droit d'accès répertorié comme Non résolu n'est pas pris en compte. Vérifiez que le nom du droit d'accès indiqué est correct.
  • Si le chemin d'accès aux classes indiqué dans le fichier resource.xml est incorrect, rectifiez-le.
  • Si un droit d'accès requis ne figure ni dans les fichiers de stratégie ni dans le fichier ra.xml, examinez le code de l'application pour vérifier si vous devez ajouter ce droit. Dans l'affirmative, ajoutez-le dans le fichier de stratégie adéquat ou dans le fichier ra.xml.
  • Si le droit n'est pas accordé en dehors de la méthode spécifique accédant à cette ressource, modifiez le code de façon à utiliser un bloc doPrivileged.
  • [AIX Solaris HP-UX Linux Windows][IBM i]Si ce droit figure dans un fichier de stratégie ou dans un fichier ra.xml et qu'il a été correctement chargé, mais que la liste du chemin d'accès aux classes ne contient toujours pas le droit d'accès, il est possible que le droit d'accès ne se trouve pas à l'emplacement requis. Lisez attentivement la rubrique Sécurité Java 2 du centre de documentation pour déterminer dans quel fichier de stratégie ou ra.xml ce droit d'accès doit être défini.
Conseil : Si l'application s'exécute avec l'API Java Mail, vous pouvez actualiser le fichier racine application Enterprise installée/META-INF/was.policy afin d'accorder à l'application les droits suivants :
  • permission java.io.FilePermission "${user.home}${/}.mailcap", "read";
  • permission java.io.FilePermission "${user.home}${/}.mime.types", "read";
  • permission java.io.FilePermission "${java.home}${/}lib${/}mailcap", "read";
  • permission java.io.FilePermission "${java.home}${/}lib${/}mime.types", "read";

Message d'erreur : CWSCJ0336E : L'authentification a échoué pour l'utilisateur {0} en raison de l'exception suivante {1}

Ce message d'erreur apparaît lorsque l'ID utilisateur indiqué est introuvable dans le registre d'utilisateurs LDAP (Lightweight Directory Access Protocol). Pour résoudre ce problème :
  1. Vérifiez que l''ID utilisateur et le mot de passe sont corrects.
  2. Vérifiez que l'ID utilisateur existe dans le registre.
  3. Vérifiez que le nom distinctif de base est correct.
  4. Vérifiez que le filtre utilisateur est correct.
  5. Vérifiez que le nom distinctif de liaison et le mot de passe associé sont corrects. Si le nom distinctif de liaison et le mot de passe ne sont pas indiqués, ajoutez-les et réessayez.
  6. Vérifiez que le nom d'hôte et le type LDAP sont corrects.
Si le problème persiste, adressez-vous à l''administrateur du registre d'utilisateurs.

Message d'erreur : Une exception inattendue s'est produite lors de l'initialisation du collaborateur de sécurité.java.lang.SecurityException: AuthConfigFactory error: java.lang.ClassNotFoundException: org.apache.geronimo.components.jaspi.AuthConfigFactoryImpl

Ce message d'erreur s'affiche lorsqu'il manque une entrée pour le fournisseur JASPI dans votre fichier java.security. L'emplacement par défaut du fichier java.security est rép_install/properties. Editez le fichier java.security et ajoutez-lui les lignes suivantes :
#
# Nom qualifié complet de la classe d'implémentation de la fabrique JASPI par défaut.
#
authconfigprovider.factory=com.ibm.ws.security.jaspi.ProviderRegistry
Remarque : Cette erreur s'affiche uniquement si vous définissez de façon explicite l'utilisation de cette classe par votre configuration. Sinon, vous risquez de voir s'afficher le message d'erreur SECJ8032W ci-dessous.

Message d'erreur : SECJ8032W: L'implémentation AuthConfigFactory n'est pas définie à l'aide de la classe d'implémentation de fabrique JASPI par défaut

Ce message d'erreur s'affiche si l'implémentation de la fabrique JASPI n'est pas définie. L'implémentation de la fabrique JASPI par défaut a été définie lors de l'exécution du serveur. Toutefois, JASPI risque de ne pas fonctionner pour un client.

Pour corriger cette erreur, définissez le nom qualifié complet de la classe d'implémentation de la fabrique JASPI par défaut en tant que valeur pour la propriété authconfigprovider.factory dans le fichier java.security, comme dans l'exemple ci-dessous.
#
# Nom qualifié complet de la classe d'implémentation de la fabrique JASPI par défaut.
#
authconfigprovider.factory=com.ibm.ws.security.jaspi.ProviderRegistry

Message d'erreur : SECJ0352E : Impossible d'obtenir les utilisateurs correspondant au modèle {0} en raison de l'exception suivante {1}

Ce message d'erreur d'authentification apparaît lorsqu'un référentiel de compte utilisateur externe est corrompu ou indisponible et que WebSphere Application Server est incapable d'authentifier le nom d'utilisateur dans le référentiel. En général, les messages d'erreur d'authentification sont suivis d'informations complémentaires indiquant la nature ou la cause du problème, telles que :

Assurez-vous que les utilisateurs correspondant au modèle existent dans le registre. Si l'incident persiste, contactez votre technicien de maintenance.

Si le référentiel de compte utilisateur est corrompu ou si l'utilisateur perd la connectivité entre WebSphere Application Server et un référentiel de compte utilisateur externe, il se peut que les informations complémentaires ne fournissent pas clairement une action de l'utilisateur. Le référentiel de compte utilisateur externe, appelé référentiel dans le présent document, peut être un produit Lightweight Directory Access Protocol (LDAP).
Pour résoudre ce problème, vous devrez peut-être réinstaller le référentiel et vérifier qu'il est correctement installé en testant la connexion.
ATTENTION :
Passez aux étapes suivantes uniquement si vous vous êtes assuré que tous les paramètres de configuration relatifs à WebSphere Application Server sont corrects.
Pour résoudre ce problème, procédez comme suit :
  1. Redémarrez le référentiel et WebSphere Application Server.
  2. Testez la connexion au référentiel. Si le tentative de connexion échoue encore, il est peut-être nécessaire de réinstaller le référentiel.
  3. Si des diagnostics sont fournis avec le référentiel, exécutez-les afin d'éviter la réinstallation du référentiel.
    Avertissement : Si les étapes précédentes ne résolvent pas ce problème, vous devrez peut-être réinstaller le référentiel. Avant cela, générez la liste complète de tous les utilisateurs et groupes configurés ; vous devrez remplir à nouveau ces zones après la réinstallation.
  4. Si nécessaire, réinstallez le référentiel corrompu.
  5. Remplissez les utilisateurs et groupes de votre liste dans le référentiel nouvellement installé.
  6. Redémarrez le référentiel et WebSphere Application Server.
  7. Dans la console d'administration, sélectionnez Sécurité > Sécurité globale, puis le référentiel de compte utilisateur approprié. Par exemple, si vous utilisez un référentiel de protocole LDAP autonome, sélectionnez Référentiel LDAP autonome.
  8. Cliquez sur Tester les connexions pour vous assurer que WebSphere Application Server peut se connecter au référentiel.

Echec de validation du jeton LTPA en raison de clés ou d'un type de jeton non valide

Si la désérialisation de contexte de sécurité échoue et renvoie une exception WSSecurityException contenant le message Validation of LTPA token failed due to invalid keys or token type, cette propriété doit avoir la valeur true.

Erreurs generateKeys lors de l'utilisation de l'outil de gestion des profils pour créer un nouveau profil

Lorsque vous créez un nouveau profil à l'aide de l'outil de gestion des profils ou de l'utilitaire manageprofiles de ligne de commande, un message d'erreur indiquant une réussite partielle ou un échec apparaît. Le message d'erreur, situé dans le fichier install_dir/logs/manageprofiles/nom_profil_create.log, peut indiquer une erreur dans la tâche generateKeysforSingleProfile ou dans la tâche generateKeysForCellProfile.

L'outil de création des profils et l'utilitaire manageprofiles appellent plusieurs tâches. La tâche generateKeysForSingleProfile est appelée lorsque vous créez un serveur d'applications autonome ou un profil de gestionnaire de déploiement. La tâche generateKeysForCellProfile est appelée lorsque vous créez un profil de cellule. Ces deux tâches sont les premières à appeler les commandes wsadmin. Bien que le journal indique une erreur dans l'une de ces tâches, l'erreur peut en réalité provenir d'un échec des commandes wsadmin et non d'une erreur dans les tâches de sécurité.

Pour déterminer la cause réelle du problème, révisez les informations fournies dans les fichiers suivants :

  • le fichier install_dir/logs/manageprofiles/nom_profil_create.log qui indique le code d'erreur de l'échec
  • le fichier install_dir/logs/manageprofiles/nom_profil/keyGeneration.log
  • le fichier install_dir/logs/manageprofiles/nom_profil/wsadminListener.log

Certains rôles de sécurité ne sont pas immédiatement disponibles pour une application sécurisée quand Tivoli Access Manager est activé dans LDAP.

Dans certains cas, certains rôles de sécurité ne sont pas immédiatement disponibles quand vous déployez une application sécurisée et que Tivoli Access Manager est activé dans LDAP.

Vous pouvez voir alors s'afficher une erreur comme celle-ci :
"Exception: java.lang.OutOfMemoryError"
Pour corriger cet incident, procédez comme suit :
  1. Augmentez la taille minimale et la taille maximale du segment de mémoire Java.
    1. Dans la console d'administration, sélectionnez Serveurs > types de serveurs > Serveurs d'applications WebSphere > serveur1.
    2. Sélectionnez Infrastructure du serveur > Gestion des processus et Java > Définition des processus.
    3. Sélectionnez Machine virtuelle Java.
    4. Fixez la taille initiale des segments de mémoire à 512 Mo et la taille maximale des segments de mémoire à 1024 Mo.
    5. Cliquez sur OK, puis sur Sauvegarder.
    6. Redémarrez WebSphere Application Server.
  2. Pendant que WebSphere Application Server est arrêté, optimisez le réglage des performances de Tivoli Access Manager.
    1. Dans le répertoire config/cells/CELLNAME, ajoutez les propriétés suivantes dans le fichier amwas.amjacc.template.properties :
      com.tivoli.pd.as.jacc.DBRefresh=0
      com.tivoli.pd.as.jacc.AuthTableRemoteMode=yes
      com.tivoli.pd.as.rbpf.NoUncheckedRoles=true

      Les performances de Tivoli Access Manager seront meilleures après cette reconfiguration.

    2. Comme un gestionnaire imbriqué Tivoli Access Manager est déjà configuré, vous pouvez mettre à jour les fichiers de configuration générés avec les propriétés ci-dessus. Pour chaque instance de WebSphere Application Server présente dans le ND (dmgr, NAs et serveurs), sélectionnez le répertoire profiles/NAME/etc/tam et exécutez les actions suivantes :
      Dans chaque fichier dont le nom se termine par amjacc.properties, ajoutez les trois propriétés ci-après :
      com.tivoli.pd.as.jacc.DBRefresh=0
      com.tivoli.pd.as.jacc.AuthTableRemoteMode=yes
      com.tivoli.pd.as.rbpf.NoUncheckedRoles=true

      Dans chaque fichier dont le nom se termine par pdperm.properties, mettez à jour la propriété appsvr-dbrefresh et remplacez-la par appsvr-dbrefresh=0

      Dans chaque fichier dont le nom se termine par authztable.pdperm.properties, mettez à jour la propriété appsvr-mode et remplacez-la par appsvr-mode=remote

  3. Redémarrez la cellule.

Impossible d'utiliser les paramètres de sécurité globale une fois le superdomaine sécurisé défini comme sensible

Si vous ajoutez un superdomaine sécurisé, puis décidez ultérieurement de définir ce superdomaine comme "sensible" depuis la console d'administration, une entrée inboundTrustedAuthenticationRealm vide risque d'être générée dans le fichier domain-security.xml. Cette définition vide entrante ou sortante de superdomaine sécurisé dans le fichier domain-security.xml bloque l'utilisation des paramètres de sécurité globale pour ce domaine.

Pour résoudre le problème, procédez comme suit :
  1. Supprimez le domaine en cours.
  2. Créez un nouveau domaine.
  3. N'ajoutez pas le superdomaine incorrect comme "sécurisé".

Les noms de superdomaine de sécurité globale mis à jour sont en double

Lors de la mise à jour des noms de superdomaine de sécurité globale, les noms de superdomaine du domaine de sécurité d'application sont également mis à jour avec les mêmes noms de superdomaine

Dans WebSphere Application Server version 8.0, vous pouvez configurer une instance unique d'un référentiel fédéré au niveau domaine dans un environnement à plusieurs domaines de sécurité en plus de disposer d'une instance au niveau global. Toutefois, si le registre d'utilisateurs des référentiels fédérés est configuré au niveau global, ou si les noms de superdomaine sont modifiés au niveau global une fois les domaines de sécurité configurés, les noms de superdomaine de tous les domaines de sécurité utilisant des référentiels fédérés sont également mis à jour. De ce fait, tous les domaines utilisent le référentiel fédéré défini au niveau global.

Pour résoudre ce problème, mettez à jour les domaines de sécurité utilisant le référentiel fédéré avec le nom de superdomaine d'origine après avoir créé des référentiels fédérés, ou modifiez les noms de superdomaine au niveau global. Ce problème peut être évité si le référentiel fédéré au niveau global est configuré avant la configuration d'un référentiel fédéré dans un domaine de sécurité.

Remarque : Lors de la mise à jour des noms de superdomaine de sécurité globale, les noms de superdomaine du domaine de sécurité d'application ne sont pas mis à jour avec les mêmes noms de superdomaine dans le groupe de correctifs 2.

Des erreurs peuvent se produire lorsque la fonction de sécurité de niveau session est activée

Lorsque la fonction de sécurité de niveau session est activée (par défaut dans WebSphere Application Server Version 8.0), et si plusieurs sessions utilisent le même ID utilisateur, lorsqu'un utilisateur ferme une session, il est possible qu'une autre session reçoive le message d'erreur suivant quand un autre utilisateur s'étant connecté avec le même ID utilisateur se déconnecte :
SESN0008E: Un utilisateur authentifié comme anonyme a tenté d'accéder à une session détenue par l'utilisateur : {<utilisateur>}

Pour résoudre ce problème, vérifiez que l'utilisateur précédent est déconnecté avant qu'un autre utilisateur ne se connecte avec le même ID utilisateur.

Eviter les incidents Eviter les incidents: Ce problème peut également se produire dans certaines instances quand la fonction de sécurité de niveau session n'est pas activée. Dans ce cas, vérifiez que l'utilisateur précédent est déconnecté avant qu'un autre utilisateur ne se connecte avec le même ID utilisateur. gotcha
[z/OS]

FIN ANORMALE EC3 AVEC MOTIF=020F2001

Si la sécurité n'est pas activée immédiatement à l'aide des boîtes de dialogue zPMT ou des boîtes de dialogue de personnalisation ISPF lors de l'installation de WebSphere Application Server for z/OS, les définitions RACF ne seront pas été complètement générées. Lorsque la sécurité est activée ultérieurement à l'aide de la console d'administration, une instruction RACF manquante empêche le démarrage de la région de contrôle WebSphere Application Server. Pour plus de détails sur la résolution de ce problème, consultez l'APAR PK36598.


Icône indiquant le type de rubrique Rubrique de référence



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