Tipps zur Fehlerbehebung bei Web Services Security

Fehler bei Web Services Security können Sie am besten beheben, wenn Sie sich mit den Konfigurationen in Assembliertools vertraut machen, um die Konfigurationen von Client- und Serveranforderungen bzw. Client- und Serverantworten abzugleichen.

Fehler bei Web Services Security können Sie am besten beheben, wenn Sie sich mit den Konfigurationen in Assembliertools vertraut machen, um die Konfigurationen von Client- und Serveranforderungen bzw. Client- und Serverantworten abzugleichen. Diese Konfigurationen müssen übereinstimmen. Die Konfiguration des Senders einer Clientanforderung muss mit der Konfiguration des Empfängers einer Serveranforderung übereinstimmen. Damit die Verschlüsselung erfolgreich durchgeführt werden kann, muss der öffentliche Schlüssel des Empfängers zum Sender exportiert werden, außerdem muss dieser Schlüssel in den Verschlüsselungsdaten richtig konfiguriert sein. Für die Authentifizierung müssen Sie das Verfahren angeben, das vom Client in der Anmeldezuordnung des Servers verwendet wird.

Die folgenden Schritte umfassen eine Reihe von generischen Schritte zur Fehlerbehebung, die Sie ausführen können.

Schritte für diese Task

  1. Vergewissern Sie sich, dass die Sicherheitserweiterungen des Clients und die Sicherheitserweiterungen des Servers bei jedem Downstream-Aufruf hinsichtlich der folgenden Angaben übereinstimmen:
    • Anforderungssender und Anforderungsempfänger
    • Antwortsender und Antwortempfänger
  2. Vergewissern Sie sich, dass, wenn die Option Erstellte Zeitmarke hinzufügen auf der Clientseite aktiviert ist, für den Server die Option Empfangene Zeitmarke hinzufügen konfiguriert ist. Sie müssen die Sicherheitserweiterungen mit einem Assembliertool konfigurieren.
  3. Vergewissern Sie sich, dass die Clientsicherheitsbindungen und die Serversicherheitsbindungen ordnungsgemäß konfiguriert sind. Wenn "Signatur" als Authentifizierungsmethode für den Client verwendet wird, müssen Sie sich vergewissern, dass der Server eine entsprechende Anmeldezuordnung besitzt. Verwendet der Client den öffentlichen Schlüssel cn=Bob,o=IBM,c=US zur Verschlüsselung des Hauptteils, vergewissern Sie sich, dass dieses Subjekt ein persönliches Zertifikat im Server-Keystore ist und den Hauptteil mit dem privaten Schlüssel entschlüsseln kann. Sie können die Sicherheitsbindungen mit einem Assembliertool oder mit der Administrationskonsole von WebSphere Application Server konfigurieren.
  4. Überprüfen Sie, ob die Datei SystemOut.log im Verzeichnis ${USER_INSTALL_ROOT}/logs/server1 (die Angabe server1 ändert sich je nach Servername) Nachrichten mit Informationen zum Problem enthält.
    Anmerkung: Dieser Artikel referenziert eine oder mehrere Protokolldateien des Anwendungsservers. Alternativ dazu wird empfohlen, den Server so zu konfigurieren, dass er die HPEL-Protokoll- und -Traceinfrastruktur (High Performance Extensible Logging) verwendet und nicht die Dateien SystemOut.log , SystemErr.log, trace.log und activity.log auf verteilten oder IBM® i-Systemen. Sie können HPEL auch in Verbindung mit Ihren nativen z/OS-Protokolleinrichtungen verwenden. Wenn Sie HPEL verwenden, können Sie mit dem Befehlszeilentool LogViewer im Verzeichnis "bin" des Serverprofils auf alle Ihre Protokoll- und Tracedaten zugreifen. Weitere Informationen zur Verwendung von HPEL finden Sie in der Dokumentation zum Einsatz von HPEL für die Fehlerbehebung in Anwendungen.
  5. Trace für Web Services Security mit der folgenden Tracespezifikation aktivieren:
    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

    Geben Sie die vorherigen zwei Zeilen in nur einer Zeile ein.

Fehler beim Sichern von Web-Services

Folgende Fehler können beim Sichern von Web-Services auftreten:

Fehlernachricht zu abweichenden Schlüsseln wird angezeigt: "CWWSS6811E: Die aus der Nachricht abgerufene Schlüssel-ID <ID> ist nicht identisch mit der Schlüssel-ID <ID>, die aus dem Keystore-Pfad abgerufen wurde"

Ursache:

Die im Produkt enthaltenen Beispiel-Keystore-Dateien wurden aktualisiert, weil einige Zertifikate bald verfallen. Wenn die Schlüssel in einer heterogenen Clusterumgebung verwendet werden, tritt ein Fehler wegen abweichender Schlüssel auf. Beispiel:
com.ibm.wsspi.wssecurity.core.SoapSecurityException: CWWSS6521E: Die Anmeldung ist wegen einer Ausnahme fehlgeschlagen:
javax.security.auth.login.LoginException: CWWSS6811E:
Die aus der Nachricht abgerufene Schlüssel-ID TVpC640XSSc= ist nicht identisch mit der Schlüssel-ID
QdZLf+KjrUg=, die aus dem Keystore-Pfad
C:\WebSphere\AppServer\profiles\AppSrv01//etc/ws-security/samples/enc-receiver.jceks abgerufen wurde."
Die mit dem Produkt bereitgestellten Keystore-Dateien sind Beispiele und sollten in einer Produktionsumgebung nicht verwendet werden. Wenn Sie die Beispieldateien jedoch verwenden, um eine heterogene Clusterumgebung zu testen, müssen die Dateien synchronisiert werden, um den Fehler wegen abweichender Schlüssel zu verhindern. Die Keystore-Dateien befinden sich in einem Unterverzeichnis des Profilverzeichnisses. Beispiel:

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

Profilstammverzeichnis steht für das Ausgangsverzeichnis eines bestimmten instanziierten Profils von WebSphere Application Server.
Die Beispiel-Keystore-Dateien befinden sich ebenfalls im Installationsverzeichnis:

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

Stammverzeichnis_des_Anwendungsservers steht für die Installationsposition von WebSphere Application Server.

Lösung:

Sie können den Fehler wegen abweichender Schlüssel umgehen, indem Sie die Keystore-Dateien manuell von den Knoten der Version 7.0 und höher im heterogenen Cluster auf die Knoten mit Feature Pack for Web Services Version 6.1 kopieren. Auf diese Weise stellen Sie sicher, dass die Knoten der Version 7.0 und höher und die Knoten mit Feature Pack for Web Services Version 6.1 dieselben Keystore-Dateien verwenden. Eine andere Ausweichlösung ist die, die Keystore-Dateien der Version 7.0 und höher an eine allgemeine Verzeichnisposition zu verschieben und anschließend alle Bindungen so zu ändern, dass sie auf die allgemeine Position für die Keystore-Dateien verweisen.

Die Fehlernachricht "CWWSI5061E: Der SOAP-Body ist nicht signiert" wird angezeigt

Ursache:

Dieser Fehler tritt normalerweise auf, wenn der SOAP-Sicherheitshandler nicht ordnungsgemäß geladen und der SOAP-Hauptteil (Body) daher nicht signiert wird. Der SOAP-Sicherheitshandler führt normalerweise die erste serverseitige Validierung durch, d. h., eine Vielzahl von Fehlern können diese Nachricht auslösen. Der Fehler wird möglicherweise durch ungültige Actor-URI-Konfigurationen ausgelöst.

Lösung:

Sie können die Actor-URI mit dem Assembliertool an den folgenden Positionen konfigurieren.

  • Für Clientkonfigurationen im Editor für Web-Service-Clients des Assembliertools:
    • Klicken Sie auf Sicherheitserweiterungen > Konfigurationsdetails zum Client-Service, und geben Sie im Feld Actor-URI die Actor-Informationen an.
    • Klicken Sie auf Sicherheitserweiterungen > Konfiguration des Anforderungssenders > Details, und geben Sie im Feld Actor die Actor-Informationen an.
  • Für Serverkonfigurationen im Web-Services-Editor des Assembliertools:
    • Klicken Sie auf Sicherheitserweiterungen > Konfiguration des Server-Service. Vergewissern Sie sich, dass für die Actor-URI dieselbe Actor-Zeichenfolge angegeben ist wie auf der Clientseite.
    • Klicken Sie auf Sicherheitserweiterungen > Konfigurationsdetails zum Antwortsenderservice > Details, und geben Sie im Feld Actor die Actor-Informationen an.

Die Actor-Daten auf dem Client und dem Server müssen auf exakt dieselbe Zeichenfolge verweisen. Wenn die Actor-Felder auf Client und Server übereinstimmen, wird die Anforderung bzw. Antwort verarbeitet und nicht an einen Downstream-Server weitergeleitet. Möglicherweise unterscheiden sich die Actor-Felder, wenn Sie Web-Services verwenden, die als Gateway zu anderen Web-Services fungieren. In allen anderen Fällen müssen Sie jedoch sicherstellen, dass die Actor-Daten auf Client und Server übereinstimmen. Wenn die Web-Service-Implementierung als Gateway fungiert und für sie nicht derselbe Actor konfiguriert ist wie für die Anforderung, die durch das Gateway weitergeleitet wird, verarbeitet diese Web-Service-Implementierung die Nachricht vom Client nicht. Stattdessen sendet sie die Anforderung an einen Downstream-Server. Der Downstream-Prozess, der die richtige Actor-Zeichenfolge enthält, verarbeitet die Anforderung. Für die Antwort ergibt sich dieselbe Situation. Daher müssen Sie unbedingt überprüfen, ob die Actor-Felder des Clients und des Servers synchronisiert sind.

Der Fehler kann auch angezeigt werden, wenn Sie nicht angeben, dass der Hauptteil in der Clientkonfiguration signiert werden muss. Um den Hauptteil (Body) der Nachricht mit dem Editor für Web-Service-Clients im Assembliertool zu signieren, klicken Sie auf Sicherheitserweiterungen > Konfiguration des Anforderungssenders > Integrität und wählen Sie die zu signierenden Nachrichtenabschnitte aus.

Die Fehlernachricht "CWWSI5075E: Es wurde kein Sicherheitstoken gefunden, das für eines der Authentifizierungsverfahren geeignet ist" wird angezeigt

Lösung:

Vergewissern Sie sich, dass die Konfigurationsdaten für die Client- und die Serveranmeldung in den Sicherheitserweiterungen übereinstimmen. Überprüfen Sie auch, ob der Client eine gültige Anmeldebindung und der Server eine gültige Anmeldezuordnung in den Sicherheitsbindungen besitzen. Sie können die entsprechenden Einstellungen an den folgenden Positionen im Assembliertool überprüfen.

  • Für Clientkonfigurationen im Editor für Web-Service-Clients des Assembliertools:
    • Klicken Sie auf Sicherheitserweiterungen > Konfiguration des Anforderungssenders > Anmeldekonfiguration, und überprüfen Sie die Authentifizierungsmethode.
    • Klicken Sie auf Port-Binding > Sicherheitskonfiguration des Anforderungssenderbinding > Anmeldebinding, um die Authentifizierungsmethode und andere Parameter zu überprüfen.
  • Für Serverkonfigurationen im Web-Services-Editor des Assembliertools:
    • Klicken Sie auf Sicherheitserweiterungen > Konfigurationsdetails zum Anforderungsempfängerservice > Anmeldekonfiguration, und überprüfen Sie die Authentifizierungsmethode.
    • Klicken Sie auf Bindungskonfigurationen > Konfigurationsdetails zum Anforderungsempfängerbinding > Anmeldezuordnung, und überprüfen Sie die Authentifizierungsmethode und andere Parameter.

Außerdem müssen Sie sicherstellen, dass die auf Client und Server angegebenen Actor-URIs übereinstimmen. Sie können die Actor-URI mit dem Assembliertool an den folgenden Positionen konfigurieren.

  • Für Clientkonfigurationen im Editor für Web-Service-Clients des Assembliertools:
    • Klicken Sie auf Sicherheitserweiterungen > Konfigurationsdetails zum Client-Service, und geben Sie im Feld Actor-URI die Actor-Informationen an.
    • Klicken Sie auf Sicherheitserweiterungen > Konfiguration des Anforderungssenders > Details, und geben Sie im Feld Actor die Actor-Informationen an.
  • Für Clientkonfigurationen im Editor für Web-Services des Assembliertools:
    • Klicken Sie auf Sicherheitserweiterungen > Konfiguration des Server-Service. Vergewissern Sie sich, dass im Feld Actor-URI dieselbe Actor-Zeichenfolge angegeben ist wie auf der Clientseite.
    • Klicken Sie auf Sicherheitserweiterungen > Konfigurationsdetails zum Antwortsenderservice > Details, und geben Sie im Feld Actor die Actor-Informationen an.

Die Fehlernachricht "CWWSI5094E: Als TrustMode ist BasicAuth festgelegt, aber es wurde kein Benutzernamenstoken für den als vertrauenswürdig eingestuften Benutzer gefunden, oder die Anmeldung des Benutzers ist fehlgeschlagen" wird angezeigt

Ursache:

Diese Situation tritt ein, wenn in der Anmeldekonfiguration IDAssertion als Authentifizierungsmethode konfiguriert ist.

Lösung:

Konfigurieren Sie für den sendenden Web-Service in der Anmeldebindung einen anerkannten Basisauthentifizierungseintrag. Überprüfen Sie anschließend auf der Serverseite, dass für den Trusted-ID-Evaluator eine Eigenschaft gesetzt ist, die den Benutzernamen dieses Basisauthentifizierungseintrags enthält.

Zum Konfigurieren des Clients für die Identitätszusicherung lesen Sie die Informationen zum Konfigurieren des Clients für die Identitätszusicherung bei der Angabe der Methode und die Informationen zum Konfigurieren des Clients für die Identitätszusicherung beim Erfassen der Authentifizierungsmethode.

Zum Konfigurieren des Servers für die Identitätszusicherung lesen Sie die Informationen zum Konfigurieren des Servers für die Behandlung der Authentifizierung mit Identitätszusicherung und die Informationen zum Konfigurieren des Servers für die Validierung der Informationen für die Authentifizierung mit Identitätszusicherung.

Die Fehlernachricht "CWSCJ0053E: Authentifizierung für /UNAUTHENTICATED... fehlgeschlagen" wird angezeigt

Ursache:

Der folgende Berechtigungsfehler tritt mit dem Sicherheitsnamen UNAUTHENTICATED auf:
CWSCJ0053E: Authentifizierung für /UNAUTHENTICATED beim Aufrufen von (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 fehlgeschlagen

Diese Situation tritt normalerweise ein, wenn eine Anmeldekonfiguration nicht konfiguriert ist oder Web Services Security nicht von einem Client für den Server konfiguriert wurde. Wenn die Anforderung beim Server eingeht und keine Authentifizierungsdaten empfangen werden, wird der Benutzer UNAUTHENTICATED für den Thread gesetzt. Wenn der Ressource Rollen zugeordnet sind, wird dieser Fehler bei der Berechtigung zurückgegeben. Die einzige Ausnahme stellt die Sonderrolle "Alle" dar, die jedem Benutzer den Zugriff gestattet.

Wenn der Client sich an einer EJB-Datei (JavaBeans) authentifiziert, die EJB-Datei jedoch eine Downstream-EJB-Datei aufruft, die ohne Web Services Security oder Transportsicherheit (z. B. HTTP-Benutzer-ID und Kennwort) konfiguriert ist, kann für diese Downstream-Anforderung ein Fehler auftreten.

Lösung:

Überprüfen Sie mit dem Assembliertool, ob die EAR-Datei (Enterprise Archive) für den Client und den Server die richtigen Sicherheitserweiterungen und -bindungen besitzt. Weitere Informationen hierzu finden Sie in den folgenden Artikeln:
  • Clientsicherheitsbindungen mit einem Assembliertool konfigurieren
  • Sicherheitsbindungen in einem Server, der als Client auftritt, mit der Administrationskonsole konfigurieren
  • Serversicherheitsbindungen mit einem Assembliertool konfigurieren
  • Serversicherheitsbindungen über die Administrationskonsole konfigurieren

Zum Konfigurieren des Clients für die Identitätszusicherung lesen Sie die Informationen zum Konfigurieren des Clients für die Identitätszusicherung bei der Angabe der Methode und die Informationen zum Konfigurieren des Clients für die Identitätszusicherung beim Erfassen der Authentifizierungsmethode.

Die Fehlernachricht "WSWS3243I: Info: Ausnahme bei der Zuordnung zu WebServicesFault." wird angezeigt, wenn Sie den lokalen Namen und den URI des Wertetyps für einen Tokenkonsumenten oder den Tokengenerator angeben

Ursache:

Der URI des Wertetyps ist für die folgenden vordefinierten lokalen Namen von Wertetypen nicht erforderlich:
  • Benutzernamenstoken
  • X509-Zertifikatstoken
  • X509-Zertifikate im Format PKIPath
  • Liste mit X509-Zertifikaten und CRLs im Format PKCS#7

Lösung:

Wenn Sie einen der aufgeführten lokalen Namen für Wertetypen angeben, dürfen Sie im Feld "URI des Wertetyps" keinen Wert eingeben.

Bei Verwendung eines Microsoft .NET Clients, der auf einen Web-Service für WebSphere Application Server zugreift, wird eine Fehlernachricht wie die folgende angezeigt: "Ungültiger URI: URI-Format konnte nicht bestimmt werden".

Ursache:

Wenn Sie einen Microsoft .NET Client verwenden, der auf einen Web-Service für WebSphere Application Server zugreift, wird eine Fehlernachricht wie die folgende angezeigt:
Ungültige URI: URI-Format konnte nicht bestimmt werden.
Ausnahmetyp:
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) 
In WebSphere Application Server ist Web Services Security aktiviert und verwendet das Attribut ActorURI. Dieser Fehler tritt auf, weil Microsoft .NET Web Services Enhancements (WSE) Version 2.0 Service Pack 3 keinen relativen URI-Wert für das Attribut ActorURI unterstützt. WSE Version 2.0 Service Pack 3 unterstützt für dieses Attribut nur einen absoluten URI (Uniform Resource Identifier).

Lösung:

Für die Arbeit mit einem Microsoft .NET Client müssen Sie dieses Attribut als absoluten URI konfigurieren. Ein Beispiel für einen absoluten URI ist abc://myWebService. Ein Beispiel für einen relativen URI ist myWebService.

Zum Konfigurieren des Attributs "ActorURI" für die Verwendung mit WebSphere Application Server verwenden Sie das IBM Assembliertool, um die folgenden Schritte auszuführen:
  1. Öffnen Sie den Web-Service-Editor, klicken Sie auf das Register Erweiterungen und erweitern Sie den Eintrag Konfiguration des Server-Service.
  2. Geben Sie im Feld "Actor" den vollständigen absoluten URI ein.
  3. Klicken Sie auf Konfigurationsdetails zum Antwortgeneratorservice > Details.
  4. Geben Sie im Feld "Actor" den vollständigen absoluten URI ein.
Weitere Informationen finden Sie in der Dokumentation zu den Assembliertools.

Die Fehlernachricht "WSEC5502E: Unerwartetes Element als Zielelement" wird angezeigt

Ursache:

Wenn der folgende Fehler angezeigt wird, liegt das möglicherweise daran, dass ein X.509-Token in einer Nachricht enthalten ist, für das kein passender Tokenkonsument konfiguriert ist. Dieser Fehler kann in JAX-RPC-Anwendungen von Konsumenten oder Providern auftreten.
com.ibm.wsspi.wssecurity.SoapSecurityException: WSEC5502E: Unerwartetes Element als Zielelement:
wsse:BinarySecurityToken
Dieser Fehler tritt auf, weil entweder ein X.509-Token konfiguriert ist und ein X.509v3-Token empfangen wird oder aber weil ein X.509v3-Token konfiguriert ist und ein X.509-Token empfangen wird. Dieser Fall tritt häufig ein, wenn X.509v3-Token von Microsoft .NET empfangen werden. Wenn das die Ursache des Fehlers ist, führen Sie die folgenden Schritte durch:
  1. Rufen Sie einen WS-Security-Trace für den Prozess ab, der die Nachricht produziert. Weitere Informationen zur Implementierung des WS-Security-Trace finden Sie in der Dokumentation zur Erstellung von Web-Service-Traces.
  2. Prüfen Sie, ob der Trace Informationen zur eingehenden SOAP-Nachricht enthält:
    1. Suchen Sie ab dem Punkt, an dem die Ausnahme eingetreten ist, rückwärts gehend nach dem Begriff "soapenv:env".
    2. Suchen Sie ab diesem Punkt rückwärts gehend nach dem Begriff "X509".
    3. Notieren Sie den Typ des X.509-Sicherheitstokens, entweder "#X509" oder "#X509v3".
  3. Wenn der Trace keine Informationen zur eingehenden SOAP-Nachricht enthält, z. B., weil, der Trace unvollständig ist, suchen Sie ab dem Punkt, an dem die Ausnahme aufgetreten ist, rückwärts gehend nach dem Begriff "Target's value type is". Diese Suche lokalisiert den Abschnitt des Trace, der angibt, welches Sicherheitstoken zum Zeitpunkt des Fehlers verarbeitet wurde. Notieren Sie den Typ des X.509-Sicherheitstokens, entweder #X509 oder #X509v3.
  4. Prüfen Sie den Typ des X.509-Sicherheitstokens, der in der Konsumentenkonfiguration angegeben ist:
    1. Suchen Sie ab dem Punkt, an dem die Ausnahme eingetreten ist, rückwärts gehend nach dem Begriff "WSSConsumerConfig".
    2. Suchen Sie jetzt vorwärts gehend nach dem Begriff "#X509".
    3. Notieren Sie den Typ des konfigurierten X.509-Sicherheitstokenkonsumenten, entweder "#X509" oder "#X509v3".
  5. Wenn der konfigurierte Tokenkonsument nicht mit dem Typ des eingehenden Sicherheitstokens übereinstimmt, bestätigt das, dass ein nicht übereinstimmendes Sicherheitstoken die Ursache des Fehlers ist.

Lösung:

Der konfigurierte Tokenkonsument muss mit dem Typ laut Angabe für das eingehende Sicherheitstoken übereinstimmen. Wenn die Ursache des Fehlers, wie in den vorherigen Schritten beschrieben, ein nicht übereinstimmendes Token ist, müssen Sie entweder die Konsumenten- oder die Providerkonfiguration für WS-Security ändern, um sicherzustellen, dass die Tokentypen übereinstimmen.

Die Ausnahme "WSEC6664E: Ein Nullwert ist für PKIXBuilderParameter nicht zulässig. Die Konfiguration von TrustAnchor und CertStoreList ist nicht korrekt" wird angezeigt

Ursache:

Die Einstellung für den Zertifikatspfad ist nicht richtig konfiguriert.

Lösung:

Konfigurieren Sie die Einstellung für den Zertifikatspfad, indem Sie die folgenden Schritte ausführen:
  1. Klicken Sie in der Administrationskonsole auf Sicherheit > Web-Sicherheit.
  2. Klicken Sie unter der Überschrift "Standardkonsumentenbindung" auf Signaturdaten >Konfigurationsname.
  3. Wählen Sie die Option Jedem vertrauen oder Dedizierte Signaturdaten aus.

    Wenn Sie die Option Dedizierte Signaturdaten auswählen, wählen Sie sowohl einen Trust-Anchor als auch einen Zertifikatsspeicher aus den Listen mit den Konfigurationen aus.

  4. Klicken Sie auf OK und Speichern, um die Angaben in der Masterkonfiguration zu speichern.

Die Microsoft-.NET-Fehlernachricht "WSE567: The incoming Username token must contain both a nonce and a creation time for the replay detection feature" wird angezeigt

Ursache:

In diesem Szenario haben Sie einen Web-Service-Client für WebSphere Application Server und einen Microsoft .NET Web Service. Der Microsoft .NET Web Service hat bezüglich der WS-Security eine Einschränkung für ein konfiguriertes Benutzernamenstoken. Der Microsoft .NET Server löst die folgende Ausnahme aus:

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

Standardmäßig validiert der Microsoft .NET Web Service den Nonce und die Zeitmarke für das Benutzernamenstoken. Sie haben jedoch die Möglichkeit, die Eigenschaften des Nonce und der Zeitmarke für einen Web-Service-Client, der WebSphere Application Server verwendet, zu konfigurieren.

Lösung:

Führen Sie die folgenden Schritte aus, um die Eigenschaften des Nonce und der Zeitmarke für ein Benutzernamenstoken in einem Web-Service-Client für WebSphere Application Server hinzuzufügen. Verwenden Sie ein Assembliertool.
  1. Öffnen Sie den Implementierungsdeskriptor für den Web-Service-Client, und klicken Sie auf das Register WS-Bindung.
  2. Erweitern Sie die Abschnitte Sicherheitskonfiguration der Anforderungsgeneratorbindung > Tokengenerator.
  3. Klicken Sie auf den Namen des soeben erstellten Benutzernamenstoken und dann auf Bearbeiten.
  4. Klicken Sie im Abschnitt "Eigenschaften" des Fensters "Tokengenerator" auf Hinzufügen.
  5. Geben Sie com.ibm.wsspi.wssecurity.token.username.addNonce im Namensfeld der Nonce-Eigenschaft ein.
  6. Geben Sie true im Feld Wert ein.
  7. Klicken Sie auf Hinzufügen.
  8. Geben Sie com.ibm.wsspi.wssecurity.token.username.addTimestamp im Namensfeld der Zeitmarkeneigenschaft ein.
  9. Geben Sie true im Feld "Wert" ein.
  10. Klicken Sie auf OK, und speichern Sie den Clientimplementierungsdeskriptor.

Bei Verwendung des Pakets com.ibm.wsspi.wssecurity.auth.token mit aktivierter Java-2-Sicherheit treten Ausnahmen für die Java-2-Sicherheit ein

Ursache:

Eine Anwendung löst, während sie das Paket com.ibm.wsspi.wssecurity.auth.token.* bei aktivierter Java™-2-Sicherheit verwendet, Java-2-Sicherheitsausnamen aus.

Es wurden neue Java-2-Berechtigungen für verschiedene öffentliche Methoden des Pakets com.ibm.wsspi.wssecurity.auth.token.* unter WebSphere Application Server Version 6.1 konfiguriert. Wenn Ihre Anwendung eine der öffentlichen Methoden aus diesen Klassen verwendet, die von Java-2-Berechtigungen geschützt werden und nicht über die entsprechenden Berechtigungen verfügen, schlägt die Anwendung fehl. Die Ausnahmenachricht enthält Informationen zu den Klassen und öffentlichen Methoden, die von der entsprechenden neuen Java-2-Berechtigung betroffen sind.

Lösung:

Erteilen Sie der Anwendung die erforderliche Berechtigung in der Datei was.policy:
  1. Bearbeiten Sie die Richtliniendateien mit dem Richtlinientool. Führen Sie die entsprechenden Schritte für Ihr Betriebssystem aus.
  2. Fügen Sie alle Berechtigungen zur Datei was.policy, die in der EAR-Datei für Ihre Anwendung gepackt wird, hinzu. Wenn Sie für Ihre Anwendung eine feinere Unterteilung der Berechtigungen in der Datei was.policy wünschen, aktivieren Sie die erforderlichen Berechtigungen für die Anwendung basierend auf den benötigten Klassen.
    Wenn Sie z. B. nur auf die Methoden für das X509BSToken zugreifen müssen, fügen Sie die folgenden Berechtigungen zur Datei was.policy hinzu:
    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. Aktualisieren Sie die Datei was.policy in der EAR-Datei für Ihre Anwendung.
  4. Deinstallieren Sie die Anwendung in WebSphere Application Server, und installieren Sie sie mit der neuen EAR-Datei und der aktualisierten Datei was.policy erneut.

Bei der Zusicherung der Integrität und der Vertraulichkeit für ein SOAP-Element kann eine Ausnahme eintreten

Ursache:

Wenn ein Client die Integrität oder Vertraulichkeit für ein SOAP-Element zusichert, das Element in der Nachricht jedoch fehlt, wird eine Ausnahme abgesetzt.

Wenn der Client die Signatur oder Verschlüsselung für ein SOAP-Element erfordert, muss das SOAP-Element immer vorhanden sein. Das Vorhandensein dieses Elements ist nicht optional. Wenn die Konfiguration z. B. angibt, dass die Integrität oder Vertraulichkeit auf das Element wscontext angewendet werden soll und wscontext in der Nachricht fehlt, tritt folgende Ausnahme ein:

com.ibm.wsspi.wssecurity.SoapSecurityException: WSEC5636W: Die zu verarbeitenden Objekte wurden nicht mit dem Dialekt
[http://www.ibm.com/websphere/webservices/wssecurity/dialect-was]
und dem Schlüsselwort [wscontext] gefunden

Lösung:

Client-Entwickler müssen sicherstellen, dass die SOAP-Elemente, deren Integrität oder Vertraulichkeit sie überprüfen möchten, immer in der SOAP-Nachricht vorhanden sind. Wenn nicht gewährleistet ist, dass die SOAP-Elemente nicht immer vorhanden sind, darf nicht deren Integrität oder Vertraulichkeit überprüft werden.

Ausnahmen für die Clientausgabe, die aufgrund der Unterschiede in den Programmiermodellen JSR-101 und JSR-109 ausgelöst werden

Ursache:

Manchmal werden Ausnahmen für die Clientausgabe ausgelöst, wenn der Client ausgeführt wird. Diese Ausnahmen werden möglicherweise aufgrund der Unterschiede in den Programmiermodellen JSR-101 und JSR-109 ausgelöst.

Sie können alle Vorgaben für Web Services Security konfigurieren: Benutzernamenstoken, X509-Token, Signieren oder Verschlüsseln der SOAP-Elemente usw. Sie können beispielsweise das Benutzernamenstoken in einem WAS-Client und -Service konfigurieren. Der Client ist so konfiguriert, dass er ein Benutzernamenstoken in der Anforderung sendet, und der Server ist so konfiguriert, dass er ein Benutzernamenstoken erwartet. Sendet der Client jedoch kein Benutzernamenstoken, verweigert der Server die Anforderung. Wenn der Client kein JNDI-Lookup (Java Naming and Directory Interface) durchführt, handelt es sich möglicherweise nicht um einen JSR-109-Client. Wenn das tatsächlich der Fall ist, kann der Client nicht die Konfigurationsdaten für JSR-109 abrufen, einschließlich der Sicherheitskonfigurationen. Die Anforderung schlägt dann fehl.

Beim Programmiermodell JSR-109 beginnt der Aufruf mit dem JNDI-Lookup, und das ermöglicht die Zuordnung der Sicherheitskonfigurationsdaten. Beim Programmiermodell JSR-101 wird kein JNDI-Lookup durchgeführt, die Sicherheitskonfigurationsdaten können nicht zugeordnet werden.

Lösung:

Dieses Verhalten stellt für die Programmiermodelle JSR-101 und JSR-109 kein Problem dar. Web Services Security stellt keine Sicherheitskonfigurationsdaten von WebSphere Application Server für einen JSR-101-Client bereit.

Die Implementierung von Web Services Security funktioniert in Übereinstimmung mit den folgenden Richtlinien:
  • Web Services Security wird nicht für einen JSR-101-Client unterstützt.
  • Für die Verwendung von Web Services Security können Sie nur einen JSR-109-Client konfigurieren.

Wenn der Client Web Services Security erfordert, muss es ein JSR-109-Client sein.

Die Fehlernachricht "WSSecurityCon E WSEC5514E: Ausnahme bei der Verarbeitung der WS-Security-Nachricht" wird angezeigt

Ursache:

Der verwaltete Client hat keinen Zugriff auf den Web-Service-Implementierungsdeskriptor, da der Aufruf lookup() nicht das Java Naming and Directory Interface (JNDI) nutzt. Ohne den Aufruf lookup() kann der Client nicht auf den Implementierungsdeskriptor zugreifen. Die Konfiguration von Web Services Security befindet sich im Web-Service-Implementierungsdeskriptor. Dies ist eine detaillierte Ausnahmebedingung, die erstellt wird:
00000046 WebServicesFa 1 
com.ibm.ws.webservices.engine.WebServicesFault makeUserFault 
MakeUserFault:     com.ibm.wsspi.wssecurity.SoapSecurityException: 
WSEC5720E: Ein erforderlicher Nachrichtenteil [Hauptteil] ist nicht signiert.
		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)

Lösung:

Für die verwalteten Clients erfolgt der Service-Lookup über den JNDI-Lookup ( Java Naming and Directory Interface). Lesen Sie die Informationen zur Konfiguration von Web Services Security mit Benutzernamenstoken, Web Services Security mit digitaler Signatur und Web Services Security mit LTPA (Lightweight Third-Party Authentication). Es folgt ein Beispiel für einen Kontext-Lookup, der mit JSR 109 kompatibel ist:

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

Wenn Sie einen Kontext-Lookup für einen verwalteten Client instanziieren, verwenden Sie nicht new() für den Service Locator. Es folgt ein Beispiel, das nicht mit JSR 109 kompatibel ist (neuer Service Locator):

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

Die Fehlernachricht "WSEC6500E: Es wird kein Kandidat für die Anmeldung verwendet" wird angezeigt

Ursache:

Diese Situation kann unter einer der folgenden Bedingungen eintreten:
  • Die Anwendungssicherheit ist aktiviert, aber die eingehende SOAP-Nachricht enthält nicht das erforderliche Sicherheitstoken, das im Element des Aufrufenden des Konsumenten angegeben ist.
  • Dieser Fall tritt ein, wenn ein Web-Service-Client Web-Services unter Verwendung von Web Services Security aufruft und die Anwendungssicherheit in dem Anwendungsserver, der den Web-Service bereitstellt, inaktiviert ist.

Beispielsweise kann ein Web-Service für die Authentifizierung mit einem Benutzernamenstoken oder einem LTPA-Token konfiguriert werden. In jedem Fall wird der Web-Service auf einem Anwendungsserver implementiert, auf dem die globale Sicherheit inaktiviert ist. Wenn der Web-Service von einem Web-Service-Client aufgerufen wird, der das erforderliche Benutzernamenstoken oder LTPA-Token angibt, schlägt der Aufruf des Web-Service fehl. Möglicherweise wird der folgende Fault an den Web-Service-Client zurückgegeben:

<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: Es wird kein Kandidat für die Anmeldung verwendet.]]>
</faultstring>   
<detail encodingStyle=""/>   
</soapenv:Fault> 

Lösung:

Wenn die Anwendungssicherheit in dem Anwendungsserver, in dem der Web-Service installiert ist, aktiviert ist, müssen Sie sicherstellen, dass der Client so konfiguriert ist, dass er das Sicherheitstoken sendet, das für den Web-Service in der Konfiguration von Web Services Security (im Element des Aufrufenden des Konsumenten) erforderlich ist.

Wenn die Anwendungssicherheit nicht in dem Anwendungsserver aktiviert ist, der den Web-Service bereitstellt, gehen Sie wie folgt vor:
  • Aktivieren Sie die Anwendungssicherheit in dem Anwendungsserver, der den Web-Service bereitstellt.
  • Definieren Sie die angepasste Eigenschaft com.ibm.wsspi.wssecurity.config.disableWSSIfApplicationSecurityDisabled von Web Services Security im Web-Service.

Die Eigenschaft com.ibm.wsspi.wssecurity.config.disableWSSIfApplicationSecurityDisabled ermöglicht es Web Services Security, den WS-Security-Header nicht zu verarbeiten, wenn die Anwendungssicherheit inaktiviert ist. Die Eigenschaft bietet Systemadministratoren und Anwendungsprogrammierern die Möglichkeit, bestimmte Aspekte ihrer Services in einer nicht gesicherten Umgebung zu testen, ohne die WS-Security-Daten aus den Implementierungsdeskriptoren entfernen zu müssen. Diese Eigenschaft ist nur für Diagnosezwecke und nicht für eine Produktionsumgebung vorgesehen.

Die gültigen Werte für diese Eigenschaft sind true und false. Der Standardwert ist false.

WebSphere Application Server bietet Bindungen auf Anwendungs-, Zellen- und Serverebene.

Gehen Sie zum Konfigurieren der Bindungen auf Serverebene (Standardbindungen) wie folgt vor:
  1. Klicken Sie auf Server > Anwendungsserver > <Servername>.
  2. Klicken Sie unter "Sicherheit" auf Web-Services: Standardbindungen für Sicherheit von Web-Services.
  3. Führen Sie eine der folgenden Aktionen aus:
    • Klicken Sie auf Standardkonsumentenbindungen > Eigenschaften (gilt möglicherweise für alle Anwendungen in der Zelle).
    • Klicken Sie auf Weitere Eigenschaften > Eigenschaften (gilt möglicherweise für alle Anwendungen in der Zelle).
Gehen Sie wie folgt vor, um die Bindungen auf Zellenebene zu konfigurieren und auf die Standardbindungen auf Zellenebene zuzugreifen:
  1. Klicken Sie auf Sicherheit > Web-Services.
  2. Klicken Sie unter "Standardgeneratorbindungen" oder "Standardkonsumentenbindungen" auf Eigenschaften.
  3. Klicken Sie unter "Sicherheit" auf Web-Services: Standardbindungen für Sicherheit von Web-Services.
  4. Führen Sie eine der folgenden Aktionen aus, nach Priorität geordnet:
    • Klicken Sie auf Standardkonsumentenbindungen > Eigenschaften.
    • Klicken Sie auf Weitere Eigenschaften > Eigenschaften.
Gehen Sie zum Konfigurieren einer JVM-Systemeigenschaft wie folgt vor:
  1. Klicken Sie auf Server > Anwendungsserver > <Servername>.
  2. Klicken Sie unter "Serverinfrastruktur" auf Java- und Prozessverwaltung>Prozessdefinition.
  3. Klicken Sie unter "Weitere Eigenschaften" auf Java Virtual Machine.
  4. Klicken Sie unter "Weitere Eigenschaften" auf Angepasste Eigenschaften.

SHA-1-Schlüsselkennung für Kerberos-Token wird ohne eine angepasste Eigenschaft nicht ordnungsgemäß konsumiert oder generiert

Ursache:

Wie im OASIS-Standard "Web Services Security Kerberos Token Profile v1.1" festgelegt, kann eine base64-Codierung eines umgesetzten SHA-1-Schlüsselwerts verwendet werden, um eine Schlüsselkennung für ein Kerberos-AP-REQ-Token anzugeben. SHA-1 ist eine Hash-Funktion für Verschlüsselung, die eine Eingabe umsetzt und eine Zeichenfolge mit fester Größe zurückgibt. Nachdem der Client und der Service-Provider eine erste Web-Service-Nachricht ausgetauscht haben, wird die SHA-1-Schlüsselkennung verwendet, um extern auf das Kerberos-Authentifizierungstoken zu verweisen. Wenn Sie SHA-1 für diesen Zweck verwenden möchten, müssen Sie eine angepasste Eigenschaft in den Richtlinienbindungen konfigurieren, um die SHA-1-Schlüsselkennung zu generieren und zu konsumieren. Die angepasste Eigenschaft "com.ibm.wsspi.wssecurity.kerberos.attach.hashKeySupportToken" wird den Bindungen des Client-Token-Generators und des Service-Token-Konsumenten hinzugefügt. Diese Eigenschaft ermöglicht der Anwendung, die SHA-1-Schlüsselkennung bei einem weiteren Austausch von Web-Service-Nachrichten ordnungsgemäß zu generieren und zu konsumieren, wenn das Kerberos-Token als Authentifizierungstoken verwendet wird.

Lösung:

Wenn eine Anwendung eine SHA-1-Schlüsselkennung für jeden Web-Service-Nachrichtenaustausch generiert oder konsumiert, setzen Sie die angepasste Eigenschaft "com.ibm.wsspi.wssecurity.kerberos.attach.hashKeySupportToken" in den Tokengenerator- und Tokenkonsumentenbindungen für die Anwendung auf true.

Führen Sie die folgenden Schritte aus, um die angepasste Eigenschaft in der Administrationskonsole zu definieren:
  1. Klicken Sie auf Services > Richtliniensätze.
  2. Klicken Sie auf Allgemeine Providerrichtliniensatzbindungen > Bindungsname.
  3. Klicken Sie in der Tabelle "Richtlinien" auf die Richtlinie WS-Security.
  4. Klicken Sie im Abschnitt mit den Sicherheitsrichtlinienbindungen auf Authentifizierung und Zugriffsschutz.
  5. Klicken Sie unter Authentifizierungstoken auf den Namen des Tokenkonsumenten oder Tokengenerators.
  6. Geben Sie im Abschnitt Angepasste Eigenschaften die angepasste Eigenschaft com.ibm.wsspi.wssecurity.kerberos.attach.hashKeySupportToken mit dem Eigenschaftswert true ein.
  7. Klicken Sie auf OK und anschließend auf Speichern.
Anmerkung: Sie sollten die Möglichkeit einer Man-in-the-Middle-Attacke in Betracht ziehen, bei der der SHA-1-Schlüssel während des Nachrichtenaustauschs abgefangen werden könnte. Zum Schutz des SHA-1-Schlüssels verwenden Sie die Sicherheit auf Transportebene, wie z. B. SSL, oder die Sicherheit auf Nachrichtenebene mit Signatur und Verschlüsselung.

Das binäre AP_REQ-Token der Kerberos Version 5 wird ohne eine angepasste Eigenschaft nicht ordnungsgemäß generiert oder konsumiert

Ursache:

Wenn Microsoft®-Web-Service-Anwendungen Nachrichten über ein Kerberos-Token anfordern, müssen Sie eine angepasste Eigenschaft in den Richtlinienbindungen konfigurieren, damit das AP_REQ-Token der Kerberos Version 5 generiert und konsumiert wird. Fügen Sie den Bindungen des Client-Token-Generators und Service-Token-Konsumenten die angepasste Eigenschaft "com.ibm.wsspi.wssecurity.kerberos.attach.apreq" hinzu. Wenn Sie diese Eigenschaft aktivieren, kann die Anwendung das Kerberos-AP_REQ-Token für jede Web-Service-Anforderungsnachricht generieren und konsumieren.

Lösung:

Wenn eine Anwendung ein AP_REQ-Token der Kerberos Version 5 für jede Web-Service-Anforderungsnachricht generiert oder konsumiert, setzen Sie die angepasste Eigenschaft com.ibm.wsspi.wssecurity.kerberos.attach.apreq in den Tokengenerator- und Tokenkonsumentenbindungen für die Anwendung wie folgt auf true:
  • Für die Interoperation mit Microsoft-.NET-Clientanwendungen setzen Sie die angepasste Eigenschaft in den Tokenkonsumentenbindungen für den Zielservice auf true.
  • Für die Interoperation mit Microsoft-.NET-Services setzen Sie die angepasste Eigenschaft in den Bindungen des Clienttokengenerators auf true.
  • Wenn eine Anwendung das Kerberos-AP_REQ-Token für jede Web-Service-Nachricht generiert, setzen Sie die angepasste Eigenschaft in den Bindungen des Client-Token-Generators und in den Bindungen des Service-Token-Konsumenten auf true.
Anmerkung: Das Generieren und Konsumieren eines AP_REQ-Tokens für jede Web-Service-Anforderungsnachricht hat Auswirkungen auf die Produktleistung, wie z. B. auf die Effizienz der Nachrichtenverarbeitung und die Speicherbelegung.
Führen Sie die folgenden Schritte aus, um diese angepasste Eigenschaft in der Administrationskonsole zu definieren:
  1. Klicken Sie in der Administrationskonsole auf Services > Richtliniensätze.
  2. Klicken Sie auf Allgemeine Providerrichtliniensatzbindungen > Bindungsname.
  3. Klicken Sie in der Tabelle "Richtlinien" auf die Richtlinie WS-Security.
  4. Klicken Sie im Abschnitt mit den Sicherheitsrichtlinienbindungen auf Authentifizierung und Zugriffsschutz.
  5. Klicken Sie unter "Token für Zugriffsschutz" auf den Namen des Tokenkonsumenten oder Tokengenerators.
  6. Geben Sie im Abschnitt "Angepasste Eigenschaften" die angepasste Eigenschaft com.ibm.wsspi.wssecurity.kerberos.attach.apreq und den entsprechenden Wert (true) ein.

Bei Verwendung eines ungültigen Zertifikats wird unter Sun Solaris keine CertPath-Ausnahme abgesetzt, sondern ein gültiger Zertifizierungspfad erstellt

Ursache:

Web-Service-Anwendungen mit aktivierter WS-Security auf einem Sun-Solaris-System erstellen möglicherweise einen gültigen Pfad, obwohl ein ungültiges Zertifikat verwendet wurde. Wenn der Schlüssel im Zertifikat in einer Anforderung und der Schlüssel in dem auf dem Server abgerufenen Zertifikat nicht übereinstimmen, wird eine Fehlernachricht ausgegeben. Wenn die Zertifikate mit Ausnahme des definierten Namens (DN) in jeder Hinsicht voneinander abweichen und der Sicherheitsprovider von Sun verwendet wird, wird der Zertifizierungspfad als ungültig zurückgegeben. Dieses Problem tritt nicht auf, wenn der Sicherheitsprovider IBMCertPath verwendet wird. IBMCertPath ist der Standardsicherheitsprovider auf allen Systemen mit Ausnahme von Sun Solaris, daher ist Sun Solaris das einzige System, auf dem dieses Problem auftritt.

  • Wird der Web-Service auf Systemen ohne Sun Solaris implementiert, wird der IBM Standard-CertPath-Provider zurückgegeben. Wenn der Code richtig funktioniert, wird bei Nichtübereinstimmung der Schlüssel die folgende Ausnahmebedingung angezeigt:
    WSEC5085E: Es kann kein gültiger CertPath erstellt werden:  java.security.cert.CertPathBuilderException:
    unable to find valid certification path to requested target
  • Wird der Web-Service in Sun Solaris implementiert, gibt die Methode java.security.cert.CertPathBuilder.build anstelle des IBM CertPath den Standard-CertPath-Provider von Sun zurück. Die Sicherheitsprovider von Sun überprüft nur den DN und nicht die Signaturdaten.

    Die Anforderung müsste aufgrund des falschen Schlüssels fehlschlagen. Der ungültige CertPath wird jedoch als gültig zurückgegeben, da nur der DN geprüft wurde. Web-Service-Anwendungen könnten also unter Sun Solaris nicht ordnungsgemäß einen gültigen CertPath erstellen, wenn sie eine ungültige Eingabe bekommen, die sich mit Ausnahme des DN in jeder Hinsicht von einem serverseitigen Zertifikat unterscheidet.

Lösung:

Es wurde eine neue Eigenschaft hinzugefügt für WebSphere Application Server Version 6.0.2 und höher: com.ibm.wsspi.wssecurity.config.CertStore.Provider.

Diese Eigenschaft ermöglicht es Web Services Security, bei Ausführung in WebSphere Application Server unter Solaris, den IBMCertPath-Provider anstelle des CertPath-Providers von Sun zu verwenden. Die Eigenschaft ist der Sicherheitsprovider, den Web Services Security verwenden sollte, wenn der Trust-Anchor genutzt wird und wenn der Sicherheitsprovider des Zertifikatsspeichers zusammen mit dem Zertifikatsspeicher angegeben wurde.

Wenn sowohl der com.ibm.wsspi.wssecurity.config.CertStore.Provider als auch ein Sicherheitsprovider für den Zertifikatsspeicher Store angegeben sind, überschreibt der Sicherheitsprovider des Zertifikatsspeichers die Einstellung für com.ibm.wsspi.wssecurity.config.CertStore.Provider.

Verschlüsselungsanforderungen für Hardware mit kartenbedingten Ausnahmen müssen zur Ausführung der Anforderungen Verschlüsselungssoftware verwenden

Ursache:

Treten auf der Maschine Lastspitzen auf, werden möglicherweise Ausnahmen für Hardwareverschlüsselungseinheiten angezeigt. Die Anforderungen können erfolgreich ausgeführt werden, weil für die Sonderoperation, die die Ausnahmebedingung empfangen hat, Verschlüsselungssoftware eingesetzt wird. Die Hardwareverschlüsselungseinheit wird jedoch nicht verwendet.

Während der Belastungstests sind die folgenden Ausnahmen eingetreten:
CWWSS5601E: Beim Entschlüsseln der Nachricht ist die folgende Ausnahme eingetreten:
com.ibm.pkcs11.PKCS11Exception: Another operation is already active
und
CWWSS5601E: Beim Entschlüsseln der Nachricht ist die folgende Ausnahme eingetreten: Key handle is invalid:
com.ibm.pkcs11.PKCS11Exception: Key handle is invalid

Dieses Problem tritt nur auf, wenn die Hardwareverschlüsselungskarte viele Operationen verarbeitet.

Lösung:

Es gibt keine bekannten Fehlerumgehungen. Die Anforderungen werden jedoch erfolgreich abgeschlossen, da die Softwareverschlüsselung verwendet wird, wenn die Hardwareverschlüsselung für eine Operation fehlschlägt.


Symbol, das den Typ des Artikels anzeigt. Referenzartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rwbs_troubleshoot
Dateiname:rwbs_troubleshoot.html