Conseils de résolution des incidents liés à la sécurité des services Web

Pour résoudre les incidents liés à la sécurité des services Web, contrôlez les configurations à l'aide des outils d'assemblage pour faire correspondre les configurations de demande et de réponse client et serveur.

La résolution des incidents liés à la sécurité des Services Web sera optimale si vous contrôlez les configurations à l'aide des outils d'assemblage afin de pouvoir faire correspondre les configurations de demande et de réponse client et serveur. Ces configurations doivent correspondre. Une configuration d'expéditeur de la demande client doit correspondre à une configuration de destinataire de demande serveur. Pour que le chiffrement aboutisse, la clé publique du destinataire doit être exportée à l'expéditeur et être configurée correctement dans les informations de chiffrement. Pour l'authentification, vous devez définir la méthode utilisée par le client dans le mappage de connexion du serveur.

Les étapes ci-dessous incluent une liste d'étapes d'identification et de résolution des incidents génériques que vous pouvez effectuer.

Etapes nécessaires pour cette tâche

  1. Vérifiez que les extensions de sécurité client et les extensions de sécurité serveur correspondent sur chaque appel en aval pour les expéditeurs et destinataires suivants :
    • Expéditeur de la demande et destinataire de la demande
    • Expéditeur de la réponse et destinataire de la réponse
  2. Vérifiez que lorsque l'option Ajouter l'horodatage créé est activée au niveau du client, l'option Ajouter l'horodatage reçu est configurée pour le serveur. Vous devez configurer les extensions de sécurité avec un outil d'assemblage.
  3. Vérifiez que les liaisons de sécurité client et les liaisons de sécurité serveur sont correctement configurées. Lorsque la méthode d'authentification client est Signature, assurez-vous que le serveur dispose d'un mappage de connexion. Lorsque le client utilise la clé publique cn=Bob,o=IBM,c=US pour chiffrer le corps, vérifiez que ce sujet est un certificat personnel dans le fichier de clés serveur afin qu'il puisse déchiffrer le corps avec la clé privée. Vous pouvez configurer les liaisons de sécurité à l'aide d'un outil d'assemblage ou de la console d'administration WebSphere Application Server.
  4. Recherchez dans le fichier SystemOut.log dans le répertoire ${USER_INSTALL_ROOT}/logs/server1 (server1 change en fonction du nom du serveur) des messages pouvant fournir des informations sur le problème.
    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.
  5. Activez la fonction de trace pour la sécurité des services Web en utilisant la spécification de trace suivante :
    com.ibm.xml.soapsec.*=all=enabled:com.ibm.ws.webservices.*=all=enabled: com.ibm.wsspi.wssecurity.
    *=all=enabled:com.ibm.ws.security.*=all=enabled: SASRas=all=enabled

    Type the previous two lines as one continuous line.

Errors when securing web services

The following errors might occur when you secure web services:

"CWWSS6811E: The key identifier <identifier name> retrieved from the message is different from the key identifier <identifier name> acquired from the keystore" key mismatch error message displays

Cause:

The sample keystore files included with the product have been updated because some of the certificates are due to expire. If the keys are used in a mixed cluster environment, a key mismatch error occurs. For example:
com.ibm.wsspi.wssecurity.core.SoapSecurityException: CWWSS6521E: The Login failed 
because of an exception: javax.security.auth.login.LoginException: CWWSS6811E: 
The key identifier TVpC640XSSc= retrieved from the message is different from the
 key identifier QdZLf+KjrUg= acquired from the keystore Path: 
C:\WebSphere\AppServer\profiles\AppSrv01//etc/ws-security/samples/enc-receiver.jceks."
The keystore files included with the product are intended as samples and should not be used in a production environment. However, if you use the sample files to test a mixed cluster environment, the files should be synchronized to prevent the key mismatch error. The keystore files are located in a sub-directory under the profile directory. For example:

racine_profil/etc/ws-security/samples/dsig-sender.ks
racine_profil/etc/ws-security/samples/dsig-receiver.ks
racine_profil/etc/ws-security/samples/enc-sender.jceks
racine_profil/etc/ws-security/samples/enc-receiver.jceks
racine_profil/etc/ws-security/samples/intca2.cer

where profile_root is the home directory for a particular instantiated WebSphere Application Server profile.
The sample keystore files are also located in the installation directory:

racine_serveur_app/etc/ws-security/samples/dsig-sender.ks
racine_serveur_app/etc/ws-security/samples/dsig-receiver.ks
racine_serveur_app/etc/ws-security/samples/enc-sender.jceks
racine_serveur_app/etc/ws-security/samples/enc-receiver.jceks
racine_serveur_app/etc/ws-security/samples/intca2.cer

where app_server_root is the location of the WebSphere Application Server installation.

Solution:

You can work around the key mismatch error by manually copying the keystore files from the Version 7.0 and later nodes in the mixed cluster to the Version 6.1 Feature Pack for web services nodes. This ensures that Version 7.0 and later nodes and Version 6.1 Feature Pack for web services nodes are using the same keystore files. Another workaround is to move the Version 7.0 and later keystore files to a common directory location, then modify all bindings to point to the common location for the keystore files.

CWWSI5061E: The SOAP body is not signed error message displays

Cause:

This error usually occurs whenever the SOAP security handler does not load properly, and does not sign the SOAP body. The SOAP security handler is typically the first validation that occurs on the server-side, so many problems can cause this message to display. The error might be caused by invalid actor URI configurations.

Solution:

You can configure the actor Universal Resource Identifier (URI) at the following locations within the assembly tool:

  • From the web services client editor within the assembly tool for client configurations:
    • Click Security Extensions > Client Service Configuration Details and indicate the actor information in the ActorURI field.
    • Click Security Extensions > Request Sender Configuration section > Details and indicate the actor information in the Actor field.
  • From the Web Services Editor within the assembly tool for server configurations:
    • Click Security Extensions > Server Service Configuration section. Verify that the actor URI has the same actor string as the client-side.
    • Click Security Extensions > Response Sender Service Configuration Details > Details and indicate the actor information in the Actor field.

The actor information on both the client and the server must refer to the same string. When the actor fields on the client and the server match, the request or response is acted upon instead of being forwarded downstream. The actor fields might be different when you have web services acting as a gateway to other web services. However, in all other cases, verify that the actor information matches on the client and server. When the web services implementation is acting as a gateway and it does not have the same actor configured as the request passing through the gateway, this web services implementation does not process the message from the client. Instead, it sends the request downstream. The downstream process that contains the correct actor string processes the request. The same situation occurs for the response. Therefore, it is important that you verify that the appropriate client and server actor fields are synchronized.

Additionally, the error can appear when you do not specify that the body is signed in the client configuration. To sign the body part of the message using the web service client editor in the assembly tool, click Security Extensions > Request Sender Configuration > Integrity and select the message parts to sign.

CWWSI5075E: No security token found that satisfies any one of the authentication methods error message displays

Solution:

Verify that the client and server login configuration information matches in the security extensions. Also, verify that the client has a valid login binding and that the server has a valid login mapping in the security bindings. You can check this information by looking at the following locations in the assembly tool:

  • From the web services client editor within the assembly tool for client configurations:
    • Click Security Extensions > Request Sender Configuration > Login Configuration verify the authentication method.
    • Click Port Binding > Security Request Sender Binding Configuration > Login Binding verify the authentication method and other parameters.
  • From the Web Services Editor within the assembly tool for server configurations:
    • Click Security Extensions > Request Receiver Service Configuration Details > Login Configuration and verify the authentication method.
    • Click Binding Configurations > Request Receiver Binding Configuration Details > Login Mapping and verify the authentication method and other parameters.

Also, make sure that the actor URI specified on the client and server matches. You can configure the actor URI at the following locations within the assembly tool:

  • From the web services client editor within the assembly tool for client configurations:
    • Click Security Extensions > Client Service Configuration Details and indicate the actor information in the ActorURI field.
    • Click Security Extensions > Request Sender Configuration section > Details and indicate the actor information in the Actor field.
  • From the web services editor within the assembly tool for server configurations:
    • Click Security Extensions > Server Service Configuration section. Make sure that the Actor URI field has the same actor string as the client side.
    • Click Security Extensions > Response Sender Service Configuration Details > Details and indicate the actor information in the Actor field.

CWWSI5094E: No UsernameToken of trusted user was found or the login failed for the user while the TrustMode is BasicAuth error message displays

Cause:

This situation occurs when you have IDAssertion configured in the login configuration as the authentication method.

Solution:

On the sending web service, configure a trusted basic authentication entry in the login binding. Then, on the server side, verify that the trusted ID evaluator has a property set that contains the user name of this basic authentication entry.

To configure the client for identity assertion, read about configuring the client for identity assertion when specifying the method and configuring the client for identity assertion collecting the authentication method.

To configure the server for identity assertion, read about configuring the server to handle identity assertion authentication and configuring the server to validate identity assertion authentication information

CWSCJ0053E: Authorization failed for /UNAUTHENTICATED error message displays

Cause:

The following authorization error occurs with UNAUTHENTICATED as the security name:
CWSCJ0053E: Authorization failed for /UNAUTHENTICATED while invoking (Home)com/ibm/wssvt/tc/
pli/ejb/Beneficiary findBeneficiaryBySsNo(java.lang.String):2 securityName: /UNAUTHENTICATED;accessID: 
null is not granted any of the required roles: AgentRole

This situation occurs because a login configuration is not being configured or web services Security is not configured from a client to a server. When the request arrives at the server and authentication information is not received, the UNAUTHENTICATED user is set on the thread. Authorization returns this error if there are any roles assigned to the resource except for the special "Everyone" role, which supports access by anyone.

If the client successfully authenticates to an Enterprise JavaBeans (EJB) file, but the EJB file calls a downstream EJB file that is not configured with Web Services Security or transport security, such as HTTP user ID and password, an error can occur for this downstream request.

Solution:

Using the assembly tool, verify that the enterprise archive (EAR) file for both client and server has the correct security extensions and security bindings. For more information, consult the following topics:
  • Configuring the client security bindings using an assembly tool
  • Configuring the security bindings on a server acting as a client using the administrative console
  • Configuring the server security bindings using an assembly tool
  • Configuring the server security bindings using the administrative console

To configure the client for identity assertion, read about configuring the client for identity assertion when specifying the method and configuring the client for identity assertion collecting the authentication method.

WSWS3243I: Info: Mapping Exception to WebServicesFault error message is displayed when you specify the value type local name and the URI for a token consumer or the token generator

Cause:

The Value type URI is not required for the following predefined value type local names:
  • Username token
  • X509 certificate token
  • X509 certificates in a PKIPath
  • A list of X509 certificates and CRLs in a PKCS#7

Solution:

If you specify one of the previous value type local names, do not enter a value for the Value type URI field.

Invalid URI: The format of the URI could not be determined error message might display when you use a Microsoft .NET client that accesses a web service for WebSphere Application Server

Cause:

The following exception message might display when you use a Microsoft .NET client that accesses a web service for WebSphere Application Server.
Invalid URI: The format of the URI could not be determined.
Exception type:
System.UriFormatException 
at System.Uri.Parse() 
at System.Uri..ctor(String uriString, Boolean dontEscape) 
at System.Uri..ctor(String uriString) 
at Microsoft.Web.Services2.SoapInputFilter.CanProcessHeader(XmlElement header, SoapContext context) 
at Microsoft.Web.Services2.Security.SecurityInputFilter.ProcessMessage(SoapEnvelope envelope) 
at Microsoft.Web.Services2.Pipeline.ProcessInputMessage(SoapEnvelope envelope) 
at Microsoft.Web.Services2.InputStream.GetRawContent() 
at Microsoft.Web.Services2.InputStream.get_Length() 
at System.Xml.XmlScanner..ctor(TextReader reader, XmlNameTable ntable) 
at System.Xml.XmlTextReader..ctor(String url, TextReader input, XmlNameTable nt) 
at System.Xml.XmlTextReader..ctor(TextReader input) 
at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, 
WebResponse response, Stream responseStream, Boolean asyncCall) 
Within WebSphere Application Server, Web Services Security is enabled and uses the ActorURI attribute. This error occurs because Microsoft .NET Web Services Enhancements (WSE) Version 2.0 Service Pack 3 does not support a relative URI value for the ActorURI attribute. WSE Version 2.0 Service Pack 3 supports an absolute Uniform Resource Identifier (URI) for this attribute only.

Solution:

To work with a Microsoft .NET client, you must configure this attribute as an absolute URI. An example of an absolute URI is: abc://myWebService. An example of a relative URI is: myWebService.

To configure ActorURI attribute for use with WebSphere Application Server, use the IBM assembly tool to complete the following steps:
  1. Open the Web Services Editor, click the Extensions tab and expand Server Service Configuration.
  2. Enter the full absolute URI in the Actor field.
  3. Expand Response Generator Service Configuration Details > Details.
  4. Enter the full absolute URI in the Actor field.
To learn more, see the assembly tools information. .

WSEC5502E: Unexpected element as the target element error message displays

Cause:

If the following error displays, the cause may be an X.509 token that is in a message, but doesn't have a matching token consumer configured. This error can occur on either consumer or provider JAX-RPC applications.
com.ibm.wsspi.wssecurity.SoapSecurityException: WSEC5502E: Unexpected element as the target element: wsse:BinarySecurityToken
The cause of this error is that either an X.509 token is configured, and an X.509v3 token is received, or an X.509v3 token is configured, and an X.509 token is received. This happens most often when receiving X.509v3 tokens from Microsoft .NET. To determine if this is the cause of the problem, follow these steps:
  1. Obtain a WS-Security trace for the process that is producing the message. For more information on how to implement the WS-Security trace, read about tracing web services.
  2. Check to see if the trace contains information about the incoming SOAP message:
    1. From the point of the exception, search backwards for the term soapenv:env.
    2. From that point, search backwards for the term X509.
    3. Note the type of the X.509 security token, either #X509 or #X509v3.
  3. If the trace does not contain information about the incoming SOAP message, for example, because the trace is incomplete, search backwards for the term Target's value type is, starting at the point of the exception. This search locates the part of the trace that shows which security token was being processed at the time of the error. Note the type of the security token, either #X509 or #X509v3.
  4. Check the type of X.509 security token that is specified in the consumer configuration:
    1. From the point of the exception, search backwards for the term WSSConsumerConfig.
    2. Now search forward for the term #X509.
    3. Note the type of the configured X.509 security token consumer, either #X509 or #X509v3.
  5. If the configured token consumer does not match the type of the incoming security token, then this confirms that a security token type mismatch is the cause of the error.

Solution:

The configured token consumer must match the type as specified for the inbound security token. If the cause of the error, as determined in the previous steps, is determined to be a security token type mismatch, then you must change either the consumer or the provider configuration for WS-Security to ensure that the token types match.

WSEC6664E: Null is not allowed to PKIXBuilderParameters. The configuration of TrustAnchor and CertStoreList are not correct exception displays

Cause:

The certificate path setting is not configured properly.

Solution:

Configure the certificate path setting by completing the following steps:
  1. In the administrative console, click Security > Web services.
  2. Under the Default consumer binding heading, click Signing information > configuration_name.
  3. Select either the Trust any or Dedicated signing information option.

    If you select the Dedicated signing information option, select both a trust anchor and a certificate store from the configurations that are provided in the drop-down lists.

  4. Click OK and Save to the master configuration.

WSE567: The incoming Username token must contain both a nonce and a creation time for the replay detection feature Microsoft .NET error displays

Cause:

In this scenario, you have a web services client for WebSphere Application Server and a Microsoft .NET web service. The Microsoft .NET web service has a ws-security constraint for a username token configured. The following exception is thrown from the Microsoft .NET server:

WSE567: The incoming username token must contain both a nonce and a creation time for the replay detection feature.

By default, the Microsoft .NET web service validates the nonce and the timestamp for the username token. However, it is optional for you to configure the nonce and timestamp properties for a web service client that is using WebSphere Application Server.

Solution:

Complete the following steps to add the nonce and timestamp properties for a username token on a web service client for WebSphere Application Server. These steps involve an assembly tool.
  1. Open the web service client deployment descriptor and click the WS-Binding tab.
  2. Expand the Security Request Generator Binding Configuration > Token Generatorsections.
  3. Click the name of the username token that you already created and click Edit.
  4. In the Properties section of the Token Generator window, click Add.
  5. Enter com.ibm.wsspi.wssecurity.token.username.addNonce in the Name field to provide the name of the nonce property.
  6. Enter true in the Value field.
  7. Click Add.
  8. Enter com.ibm.wsspi.wssecurity.token.username.addTimestamp in the Name field to provide the name of the timestamp property.
  9. In the Value field, enter true.
  10. Click OK and save the client deployment descriptor.

Java 2 Security exceptions occur when using the com.ibm.wsspi.wssecurity.auth.token package with Java 2 Security enabled

Cause:

An application creates Java™ 2 Security exceptions while using the com.ibm.wsspi.wssecurity.auth.token.* package when Java 2 Security is enabled.

New Java 2 permissions have been set for various public methods of the com.ibm.wsspi.wssecurity.auth.token.* package on WebSphere Application Server Version 6.1. If your application uses one of the public methods from these classes that are protected by Java 2 Security permissions and it does not have the appropriate permissions, the application will fail. The exception message provides information that identifies the classes and public methods that are affected with the corresponding new Java 2 Security permission.

Solution:

Grant permission in the was.policy file for the application:
  1. Use the PolicyTool to edit the policy files. Follow the appropriate steps for your operating system.
  2. Add all of the permissions to the was.policy file that gets packaged in the enterprise archive (EAR) file for your application. If you want finer granularity for the permissions in the was.policy file for your application, enable the permissions that are necessary for your application based upon the classes that you need.
    For example, if you need to access only the methods for the X509BSToken, you would add the following permissions to the was.policy file:
    grant codeBase "file:${application}" {
       permission com.ibm.websphere.security.WebSphereRuntimePermission
         "wssecurity.X509BSToken.setBytes";
       permission com.ibm.websphere.security.WebSphereRuntimePermission
         "wssecurity.X509BSToken.setCert";
      permission com.ibm.websphere.security.WebSphereRuntimePermission 
        " wssecurity.WSSToken.setTrusted";
      permission com.ibm.websphere.security.WebSphereRuntimePermission 
         "wssecurity.WSSToken.addAttribute";
      permission com.ibm.websphere.security.WebSphereRuntimePermission 
         "wssecurity.WSSToken.setUsedTokenConsumer";
    };
  3. Mettez le fichier was.policy à jour dans le fichier EAR de votre application.
  4. Désinstallez l'application de WebSphere Application Server et réinstallez-la avec le nouveau fichier EAR et le fichier was.policy actualisé.

Une exception est susceptible de se produire si l'intégrité ou la confidentialité est vérifiée pour un élément SOAP

Cause :

Si un client vérifie l'intégrité ou la confidentialité d'un élément SOAP mais que l'élément ne se trouve pas dans le message, une exception est émise.

Si le client demande l'application d'une signature ou d'un chiffrement à un élément SOAP, l'élément SOAP doit toujours être présent. La présence de cet élément n'est pas facultative. Par exemple, si la configuration spécifie que l'intégrité ou la confidentialité doit être appliquée à l'élément wscontext. Si wscontext n'est pas contenu dans le message, l'exception suivante est émise :

com.ibm.wsspi.wssecurity.SoapSecurityException: WSEC5636W: Objects 
à traiter introuvables avec le dialecte 
[http://www.ibm.com/websphere/webservices/wssecurity/dialect-was] 
et le mot clé [wscontext]

Solution :

Les développeurs du client doivent s'assurer que les éléments SOAP ciblés pour vérification d'intégrité ou de confidentialité sont toujours contenus dans le message SOAP. Si vous ne pouvez pas garantir que l'élément SOAP sera toujours présent, ne ciblez pas les éléments SOAP pour vérification d'intégrité ou de confidentialité.

Le client émet des exceptions liées à la différence des modèles de programmation JSR-101 et JSR-109.

Cause :

Parfois, des exceptions de sortie client sont produites lors de l'exécution du client. Les exceptions émises par le client peuvent être dues aux différences existant entre les modèles de programmation JSR-101 et JSR-109.

Vous pouvez configurer n'importe quelle contrainte de sécurité (jeton de nom d'utilisateur, jeton X509, signature et chiffrement des éléments SOAP, etc.). Par exemple, vous pouvez configurer le jeton de nom d'utilisateur pour un service et un client WebSphere Application Server. Le client est configuré pour envoyer un jeton de nom d'utilisateur dans une requête et le serveur est configuré pour recevoir un jeton de nom d'utilisateur. Mais si le client n'envoie pas de jeton de nom d'utilisateur, le serveur rejette la requête. Si le client n'effectue pas de recherche de noms JNDI (JavaJava Naming and Directory Interface), il ne s'agit probablement pas d'un client JSR-109. S'il ne s'agit pas d'un client JSR-109, le client ne reçoit pas les informations de configuration JSR-109 (notamment les informations de configuration de la sécurité) et la requête échoue.

Pour le modèle de programmation JSR-109, l'appel commence par la recherche JNDI qui permet de lier les informations de configuration de la sécurité. Pour le modèle de programmation JSR-101, aucune recherche JNDI n'est effectuée ; les informations de configuration de la sécurité ne peuvent pas être liées.

Solution :

Ce comportement n'est pas un problème avec les modèles de programmation JSR-101 et JSR-109. La sécurité des services Web ne fournit pas les informations de configuration de sécurité WebSphere Application Server à un client JSR-101.

L'implémentation de la sécurité des Services Web doit être réalisée comme suit :
  • La sécurité des services Web n'est pas prise en charge pour un client JSR-101.
  • Vous pouvez seulement configurer un client JSR-109 pour utiliser la sécurité des Services Web.

Si le client requiert la sécurité des Services Web, il doit s'agir d'un client JSR-109.

Une erreur "WSSecurityCon E WSEC5514E: Une exception s'est produite lors du traitement du message WS-Security" s'affiche.

Cause :

Le client géré n'a pas accès au descripteur de déploiement de services Web car l'appel lookup() n'a pas utilisé l'interface JNDI (Java Naming and Directory Interface). Sans l'appel lookup(), le client ne peut pas accéder au descripteur de déploiement. La configuration de la sécurité des services Web se trouve dans le descripteur de déploiement des services Web. Vous trouverez ci-dessous une exception détaillée qui est créée :
00000046 WebServicesFa 1 
com.ibm.ws.webservices.engine.WebServicesFault makeUserFault 
MakeUserFault:     com.ibm.wsspi.wssecurity.SoapSecurityException: 
WSEC5720E: Une partie de message requise [{0}] n'est pas signée.
	at com.ibm.wsspi.wssecurity.SoapSecurityException.format(SoapSecurityException.java:143)
	at com.ibm.ws.webservices.wssecurity.dsig.VerifiedPartChecker.invoke(VerifiedPartChecker.java:
263)
	at com.ibm.ws.webservices.wssecurity.core.WSSConsumer.checkRequiredIntegrity(WSSConsumer.java:
1430)
	at com.ibm.ws.webservices.wssecurity.core.WSSConsumer.invoke(WSSConsumer.java:545)
	at com.ibm.ws.webservices.wssecurity.handler.WSSecurityConsumerBase.invoke(WSSecurityConsumerB
ase.java:85)
	at com.ibm.ws.webservices.wssecurity.handler.GlobalSecurityHandler.handleRequest6(GlobalSecuri
tyHandler.java:406)

Solution :

Pour les clients gérés, la recherche du service s'effectue via une recherche JNDI (Java Naming and Directory Interface). Consultez la documentation sur la configuration d'un élément UsernameToken, de la sécurité des services Web, de la sécurité des Services Web de signature numérique et de la sécurité des services Web du jeton LTPA (Lightweight Third-Party Authentication). Vous trouverez ci-dessous un exemple de recherche de contexte compatible JSR 109 :

InitialContext ctx = new InitialContext();
FredsBankServiceLocator locator
    =(FredsBankService)ctx.lookup("java:comp/env/service/FredsBankService");
FredsBank fb = locator.getFredsBank(url);
long balance = fb.getBalance();  

Lorsque vous instanciez une recherche de contexte pour un client géré, n'utilisez pas new() en tant que localisateur de service. Voici un exemple qui n'est pas compatible JSR 109 (nouvel élément ServiceLocator) :

Properties prop = new Properties();
InitialContext ctx = new InitialContext(prop);
FredsBankServiceLocator locator = new FredsBankServiceLocator();
FredsBank fb = locator.getFredsBank(url);
long balance = fb.getBalance(); 

Affichage du message d'erreur WSEC6500E: Aucun candidat n'est utilisé pour la connexion.

Cause :

Cette situation peut se présenter dans l'un des cas suivants :
  • La sécurité des applications est activée, mais le message SOAP entrant ne contient pas le jeton de sécurité requis qui est spécifié pour le service dans la partie appelant du destinataire.
  • Un client de service Web appelle les services Web à l'aide de la sécurité des services Web et la sécurité des applications est désactivée sur le serveur d'applications qui héberge le service Web.

Par exemple, un service Web peut être configuré pour l'authentification en utilisant un jeton Username ou LTPA. Toutefois, il est déployé sur un serveur d'applications où la sécurité globale est désactivée. Lorsque le service Web est appelé par un client de service Web, qui fournit le jeton Username ou LTPA requis, l'appel de service Web échoue. L'erreur suivante peut être renvoyée au client de service Web :

<soapenv:Fault>   
<faultcode xmlns:p55="http://docs.oasis-open.org/wss/2004/01/oasis-
      200401-wss-wssecurity-secext-1.0.xsd">p55: FailedAuthentication  
</faultcode>   
<faultstring>  
<![CDATA[com.ibm.wsspi.wssecurity.SoapSecurityException:   
WSEC6500E: There is no candidate used to login.]]>   
</faultstring>   
<detail encodingStyle=""/>   
</soapenv:Fault>

Solution :

Si la sécurité des applications est activée sur le serveur d'applications qui héberge le service Web, vérifiez dans la configuration de la partie appelant du destinataire relative à la sécurité des services Web que le client est correctement configuré pour envoyer le jeton de sécurité requis par le service Web.

Si la sécurité des applications n'est pas activée sur le serveur d'applications qui héberge le service Web, procédez de l'une des manières suivantes :
  • Activez la sécurité des applications sur le serveur d'applications qui héberge le service Web.
  • Définissez la propriété personnalisée com.ibm.wsspi.wssecurity.config.disableWSSIfApplicationSecurityDisabled de la sécurité des services Web dans le service Web.

La propriété com.ibm.wsspi.wssecurity.config.disableWSSIfApplicationSecurityDisabled permet à la sécurité des Services Web de ne pas traiter l'en-tête WS-Security si la sécurité des applications est désactivée. Cela permet aux administrateurs systèmes et aux programmeurs d'applications de déboguer des aspects de leurs services dans un environnement non sécurisé sans avoir à supprimer les informations WS-Security de leurs descripteurs de déploiement. Cette propriété n'est à utiliser qu'à des fins de diagnostics et non dans un environnement de production.

Les valeurs admises pour cette propriété sont true et false. La valeur par défaut est false.

Les liaisons au niveau application, serveur et cellule constituent les niveaux de liaison proposés par WebSphere Application Server.

Pour configurer les liaisons au niveau du serveur (par défaut), procédez comme suit :
  1. Cliquez sur Serveurs > Serveurs d'applications > <nom_serveur>.
  2. Dans la section Sécurité, cliquez sur Services Web : Liaisons par défaut pour la sécurité des services Web.
  3. Effectuez l'une des actions suivantes :
    • Cliquez sur Liaisons de destinataire par défaut > Propriétés (peut s'appliquer à la totalité des applications de la cellule).
    • Cliquez sur Propriétés supplémentaires > Propriétés (peut s'appliquer à la totalité des applications de la cellule).
Pour configurer les liaisons au niveau de la cellule et accéder aux liaisons par défaut au niveau cellule :
  1. Cliquez sur Sécurité > Services Web.
  2. Dans la section Liaisons de générateur par défaut ou Liaisons de destinataire par défaut, cliquez sur Propriétés.
  3. Dans la section Sécurité, cliquez sur Services Web : Liaisons par défaut pour la sécurité des services Web.
  4. Procédez de l'une des manières suivantes, dans les emplacements suivants par ordre de priorité :
    • Cliquez sur Liaisons de destinataire par défaut > Propriétés.
    • Cliquez sur Propriétés supplémentaires > Propriétés.
Pour configurer une propriété système de la JVM :
  1. Cliquez sur Serveurs > Serveurs d'applications > <nom_serveur>.
  2. Sous Infrastructure du serveur, cliquez sur Gestion des processus et Java > Définition des processus.
  3. Sous Propriétés supplémentaires, cliquez sur Machine virtuelle Java.
  4. Sous Propriétés supplémentaires, cliquez sur Propriétés personnalisées.

L'identificateur de clé SHA-1 du jeton Kerberos n'a pas été consommé ou a été généré incorrectement sans propriété personnalisée.

Cause :

Selon la spécification OASIS standard Web Services Security Kerberos Token Profile v1.1, vous pouvez utiliser un chiffrement en base 64 d'une valeur de clé transformée SHA-1 pour spécifier un identificateur de clé pour un jeton Kerberos AP-REQ. SHA-1 est une fonction de hachage cryptographique qui transforme une entrée et renvoie une chaîne de taille fixe. Quand le client et le fournisseur de services ont échangé un premier message de services Web, l'identificateur de clé SHA-1 est utilisé comme référence externe du jeton d'authentification Kerberos. Pour utiliser SHA-1 de cette manière, vous devez configurer une propriété personnalisée dans les liaisons de règles afin de générer et consommer l'identificateur de clé SHA-1. La propriété personnalisée com.ibm.wsspi.wssecurity.kerberos.attach.hashKeySupportToken est ajoutée aux liaisons du consommateur du jeton de service et au créateur du jeton client. Cette propriété permet à l'application de créer et consommer correctement l'identificateur de clé SHA-1 pendant les échanges suivants de messages de services Web quand le jeton Kerberos est utilisé comme jeton d'authentification.

Solution :

Si une application crée ou consomme un identificateur de clé SHA-1 pour chaque échange de message de services Web, affectez à la propriété personnalisée com.ibm.wsspi.wssecurity.kerberos.attach.hashKeySupportToken la valeur true dans le créateur de jeton et les liaisons du consommateur de jeton pour cette application.

Pour définir la propriété personnalisée à l'aide de la console d'administration, effectuez les opérations suivantes :
  1. Cliquez sur Services > Ensembles de règles.
  2. Cliquez sur Liaisons générales de l'ensemble de règles du fournisseur >nom_liaison.
  3. Cliquez sur la règle WS-Security dans la table des règles.
  4. Cliquez sur Authentification et protection dans la section Liaisons de la règle de sécurité.
  5. Sous Jetons d'authentification, cliquez sur le nom du consommateur de jeton ou du créateur de jeton.
  6. Dans la section Propriétés personnalisées, entrez la propriété personnalisée com.ibm.wsspi.wssecurity.kerberos.attach.hashKeySupportToken et la valeur true.
  7. Cliquez sur OK, puis sur Sauvegarder.
Remarque : Sachez qu'il existe un risque d'attaque par introduction qui peut intercepter la clé SHA-1 pendant les échanges de messages. Pour protéger la clé SHA-1, utilisez une sécurité au niveau du transport, par exemple SSL, ou au niveau du message avec signature et chiffrement.

Le jeton binaire AP_REQ Kerberos V5 n'est pas créé ou consommé correctement en l'absence de la propriété personnalisée.

Cause :

Quand des applications de service Web Microsoft® demandent des messages avec un jeton Kerberos, vous devez configurer une propriété personnalisée dans les liaisons de règles pour le jeton AP_REQ Kerberos V5 afin de générer et consommer le jeton. Ajoutez la propriété personnalisée com.ibm.wsspi.wssecurity.kerberos.attach.apreq aux liaisons du consommateur du jeton de service et au créateur du jeton client. Activer cette propriété permet à l'application de créer et consommer le jeton AP_REQ Kerberos pour chaque message de demande des services Web.

Solution :

Si une application crée ou consomme un jeton AP_REQ Kerberos V5 pour chaque message de demande des services Web, affectez à la propriété personnalisée com.ibm.wsspi.wssecurity.kerberos.attach.apreq la valeur true dans les liaisons du générateur de jeton et du consommateur de jeton pour cette application, comme suit :
  • Pour interopérer avec les applications client Microsoft .NET, affectez à la propriété personnalisée la valeur true dans les liaisons du consommateur de jeton pour le service cible.
  • Pour interopérer avec les services Microsoft .NET, affectez à la propriété personnalisée la valeur true dans les liaisons du créateur de jeton client.
  • Si une application crée le jeton AP_REQ Kerberos pour chaque message des services Web, affectez à la propriété personnalisée la valeur true à la fois dans les liaisons du générateur de jeton client et dans les liaisons du consommateur de jeton de service.
Remarque : La création et la consommation d'un jeton AP_REQ pour chaque message de demande des services Web a un impact sur les performances du produit, en particulier sur le traitement des messages et l'utilisation de la mémoire.
Pour définir cette propriété à l'aide de la console d'administration, effectuez les opérations suivantes :
  1. Dans la console d'administration, cliquez sur Services > Ensembles de règles.
  2. Cliquez sur Liaisons générales de l'ensemble de règles du fournisseur >nom_liaison.
  3. Cliquez sur la règle WS-Security dans la table des règles.
  4. Cliquez sur Authentification et protection dans la section Liaisons de la règle de sécurité.
  5. Sous Jetons de protection, cliquez sur le nom du consommateur de jeton ou du créateur de jeton.
  6. Dans la section Propriétés personnalisées, entrez la propriété personnalisée com.ibm.wsspi.wssecurity.kerberos.attach.apreq et la valeur appropriée (true).

Au lieu d'émettre une exception CertPath, un chemin de certification valide est élaboré sur Sun Solaris lorsqu'un certificat non valide est utilisé.

Cause :

Les applications de services Web pour lesquelles WS-Security est activé sur un système Sun Solaris risquent de générer un chemin de certification valide même si un certificat non valide a été utilisé. En cas de non-concordance entre la clé du certificat d'une demande et celle qui est extraite sur le serveur, un message d'erreur doit être émis. Mais, lorsque les certificats diffèrent en tout sauf en ce qui concerne le nom distinctif et que le fournisseur utilisé est le fournisseur Sun, le chemin de certification est renvoyé comme étant valide. Ce problème ne se pose pas si le fournisseur utilisé pour la sécurité est IBMCertPath. IBMCertPath est le fournisseur de sécurité par défaut sur tous les systèmes à l'exception de Sun Solaris, ce qui explique que ce problème ne se produit que sur ce système.

  • Lorsque le service Web est déployé sur des systèmes autres que Sun, le fournisseur de chemin de certification renvoyé par défaut est celui d'IBM (IBMCertPath). Lorsque le code fonctionne correctement, l'exception suivante apparaît lorsque les clés ne concordent pas :
    WSEC5085E: Unable to build a valid CertPath:  java.security.cert.CertPathBuilderException:  
    impossible de trouver un chemin de certification valide pour la cible demandée
  • Lorsque le service Web est déployé sur Sun Solaris, la méthode java.security.cert.CertPathBuilder.build renvoie par défaut le fournisseur CertPath de Sun à la place d'IBMCertPath. Le fournisseur Sun de sécurité se contente de vérifier le nom distinctif (DN) sans vérifier les signatures.

    La requête doit échouer en raison de la clé incorrecte. Toutefois, l'élément CertPath non valide est renvoyé comme étant non valide car seul le nom distinctif a été vérifié. Les applications de services Web s'exécutant sur Sun Solaris peuvent générer par erreur un CertPath valide si elles reçoivent en entrée des données erronées différentes en tous points du certificat se trouvant côté serveur, sauf en ce qui concerne le nom distinctif.

Solution :

La nouvelle propriété suivante a été ajoutée pour WebSphere Application Server version 6.0.2 et ultérieure : com.ibm.wsspi.wssecurity.config.CertStore.Provider

Cette propriété permet à la sécurité des services Web, lorsqu'ils s'exécutent dans WebSphere Application Server sur Solaris, d'utiliser le fournisseur IBMCertPath à la place du fournisseur Sun CertPath. Cette propriété correspond au fournisseur de sécurité que la sécurité des services Web doit utiliser lors de l'utilisation de points d'ancrage sécurisés et lorsque le fournisseur de sécurité de l'espace de stockage des certificats a été spécifié conjointement avec l'espace de stockage des certificats.

Si l'élément com.ibm.wsspi.wssecurity.config.CertStore.Provider et un fournisseur de sécurité sont spécifiés pour l'espace de stockage des certificats, le fournisseur de sécurité de l'espace de stockage des certificats remplace le paramètre de com.ibm.wsspi.wssecurity.config.CertStore.Provider.

Les demandes de chiffrement matérielles avec exceptions liées aux cartes doivent utiliser un logiciel de chiffrement pour exécuter les demandes avec succès

Cause :

Des exceptions liées aux périphériques de chiffrement matériels peuvent être rencontrées lorsque la machine est en forte charge. Les demandes aboutissent car le logiciel de chiffrement est utilisé à la place de l'opération spécifique ayant reçu l'exception. Toutefois, le périphérique de chiffrement matériel n'est pas utilisé.

Les exceptions suivantes ont été rencontrées lors de l'exécution de tests de charge :
CWWSS5601E :  L'exception suivante est survenue lors du déchiffrement du message : 
com.ibm.pkcs11.PKCS11Exception: Une autre opération est déjà active
et
CWWSS5601E: L'exception suivante est survenue lors du déchiffrement du message : Le descripteur de clé n'est pas valide :
com.ibm.pkcs11.PKCS11Exception: Le descripteur de clé n'est pas valide

Cet incident se produit lorsque la carte de chiffrement matérielle traite un grand nombre d'opérations.

Solution :

Il n'existe pas de solution palliative connue. Cependant, les demandes aboutissent car le chiffrement logiciel est utilisé lorsque le chiffrement matériel échoue dans une opération.


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