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
- 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
- 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.
- 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.
- Ü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.
- 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
- 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"
- Die Fehlernachricht "CWWSI5061E: Der SOAP-Body ist nicht signiert" wird angezeigt
- Die Fehlernachricht "CWWSI5075E: Es wurde kein Sicherheitstoken gefunden, das für eines der Authentifizierungsverfahren geeignet ist" wird angezeigt
- 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
- Die Fehlernachricht "CWSCJ0053E: Authentifizierung für /UNAUTHENTICATED... fehlgeschlagen" wird angezeigt
- 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
- 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".
- Die Fehlernachricht "WSEC5502E: Unerwartetes Element als Zielelement" wird angezeigt
- Die Ausnahme "WSEC6664E: Ein Nullwert ist für PKIXBuilderParameter nicht zulässig. Die Konfiguration von TrustAnchor und CertStoreList ist nicht korrekt" wird angezeigt
- 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
- Die Fehlernachricht "WSEC6500E: Es wird kein Kandidat für die Anmeldung verwendet" wird angezeigt
- SHA-1-Schlüsselkennung für Kerberos-Token wird ohne eine angepasste Eigenschaft nicht ordnungsgemäß konsumiert oder generiert
- Das binäre AP_REQ-Token der Kerberos Version 5 wird ohne eine angepasste Eigenschaft nicht ordnungsgemäß generiert oder konsumiert
- Bei Verwendung eines ungültigen Zertifikats wird unter Sun Solaris keine CertPath-Ausnahme abgesetzt, sondern ein gültiger Zertifizierungspfad erstellt
- Verschlüsselungsanforderungen für Hardware mit kartenbedingten Ausnahmen müssen zur Ausführung der Anforderungen Verschlüsselungssoftware verwenden
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:
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."
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
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
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 Actor-URI die Actor-Informationen an. , und geben Sie im Feld
- Klicken Sie auf Actor die Actor-Informationen an. , und geben Sie im Feld
- Für Serverkonfigurationen im Web-Services-Editor des Assembliertools:
- Klicken Sie auf . Vergewissern Sie sich, dass für die Actor-URI dieselbe Actor-Zeichenfolge angegeben ist wie auf der Clientseite.
- Klicken Sie auf Actor die Actor-Informationen an. , und geben Sie im Feld
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
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 , und überprüfen Sie die Authentifizierungsmethode.
- Klicken Sie auf , um die Authentifizierungsmethode und andere Parameter zu überprüfen.
- Für Serverkonfigurationen im Web-Services-Editor des Assembliertools:
- Klicken Sie auf , und überprüfen Sie die Authentifizierungsmethode.
- Klicken Sie auf , 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 Actor-URI die Actor-Informationen an. , und geben Sie im Feld
- Klicken Sie auf Actor die Actor-Informationen an. , und geben Sie im Feld
- Für Clientkonfigurationen im Editor für Web-Services des Assembliertools:
- Klicken Sie auf Actor-URI dieselbe Actor-Zeichenfolge angegeben ist wie auf der Clientseite. . Vergewissern Sie sich, dass im Feld
- Klicken Sie auf Actor die Actor-Informationen an. , und geben Sie im Feld
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:
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:
- 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:
- 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:
Ungültige URI: URI-Format konnte nicht bestimmt werden.
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.
- Öffnen Sie den Web-Service-Editor, klicken Sie auf das Register Erweiterungen und erweitern Sie den Eintrag Konfiguration des Server-Service.
- Geben Sie im Feld "Actor" den vollständigen absoluten URI ein.
- Klicken Sie auf .
- Geben Sie im Feld "Actor" den vollständigen absoluten URI ein.
Die Fehlernachricht "WSEC5502E: Unerwartetes Element als Zielelement" wird angezeigt
Ursache:
com.ibm.wsspi.wssecurity.SoapSecurityException: WSEC5502E: Unerwartetes Element als Zielelement:
wsse:BinarySecurityToken
- 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.
- Prüfen Sie, ob der Trace Informationen zur eingehenden SOAP-Nachricht enthält:
- Suchen Sie ab dem Punkt, an dem die Ausnahme eingetreten ist, rückwärts gehend nach dem Begriff "soapenv:env".
- Suchen Sie ab diesem Punkt rückwärts gehend nach dem Begriff "X509".
- Notieren Sie den Typ des X.509-Sicherheitstokens, entweder "#X509" oder "#X509v3".
- 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.
- Prüfen Sie den Typ des X.509-Sicherheitstokens, der in der Konsumentenkonfiguration angegeben ist:
- Suchen Sie ab dem Punkt, an dem die Ausnahme eingetreten ist, rückwärts gehend nach dem Begriff "WSSConsumerConfig".
- Suchen Sie jetzt vorwärts gehend nach dem Begriff "#X509".
- Notieren Sie den Typ des konfigurierten X.509-Sicherheitstokenkonsumenten, entweder "#X509" oder "#X509v3".
- 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:
- Klicken Sie in der Administrationskonsole auf .
- Klicken Sie unter der Überschrift "Standardkonsumentenbindung" auf .
- 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.
- 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:
- Öffnen Sie den Implementierungsdeskriptor für den Web-Service-Client, und klicken Sie auf das Register WS-Bindung.
- Erweitern Sie die Abschnitte .
- Klicken Sie auf den Namen des soeben erstellten Benutzernamenstoken und dann auf Bearbeiten.
- Klicken Sie im Abschnitt "Eigenschaften" des Fensters "Tokengenerator" auf Hinzufügen.
- Geben Sie com.ibm.wsspi.wssecurity.token.username.addNonce im Namensfeld der Nonce-Eigenschaft ein.
- Geben Sie true im Feld Wert ein.
- Klicken Sie auf Hinzufügen.
- Geben Sie com.ibm.wsspi.wssecurity.token.username.addTimestamp im Namensfeld der Zeitmarkeneigenschaft ein.
- Geben Sie true im Feld "Wert" ein.
- 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:
- Bearbeiten Sie die Richtliniendateien mit dem Richtlinientool. Führen Sie die entsprechenden Schritte für Ihr Betriebssystem aus.
- 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"; };
- Aktualisieren Sie die Datei was.policy in der EAR-Datei für Ihre Anwendung.
- 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.
- 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:
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:
- 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.
- 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.
- Klicken Sie auf .
- Klicken Sie unter "Sicherheit" auf Web-Services: Standardbindungen für Sicherheit von Web-Services.
- Führen Sie eine der folgenden Aktionen aus:
- Klicken Sie auf (gilt möglicherweise für alle Anwendungen in der Zelle).
- Klicken Sie auf (gilt möglicherweise für alle Anwendungen in der Zelle).
- Klicken Sie auf .
- Klicken Sie unter "Standardgeneratorbindungen" oder "Standardkonsumentenbindungen" auf Eigenschaften.
- Klicken Sie unter "Sicherheit" auf Web-Services: Standardbindungen für Sicherheit von Web-Services.
- Führen Sie eine der folgenden Aktionen aus, nach Priorität geordnet:
- Klicken Sie auf .
- Klicken Sie auf .
- Klicken Sie auf .
- Klicken Sie unter "Serverinfrastruktur" auf .
- Klicken Sie unter "Weitere Eigenschaften" auf Java Virtual Machine.
- 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.
- Klicken Sie auf .
- Klicken Sie auf .
- Klicken Sie in der Tabelle "Richtlinien" auf die Richtlinie WS-Security.
- Klicken Sie im Abschnitt mit den Sicherheitsrichtlinienbindungen auf Authentifizierung und Zugriffsschutz.
- Klicken Sie unter Authentifizierungstoken auf den Namen des Tokenkonsumenten oder Tokengenerators.
- Geben Sie im Abschnitt Angepasste Eigenschaften die angepasste Eigenschaft com.ibm.wsspi.wssecurity.kerberos.attach.hashKeySupportToken mit dem Eigenschaftswert true ein.
- Klicken Sie auf OK und anschließend auf Speichern.
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:
- 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.
- Klicken Sie in der Administrationskonsole auf .
- Klicken Sie auf .
- Klicken Sie in der Tabelle "Richtlinien" auf die Richtlinie WS-Security.
- Klicken Sie im Abschnitt mit den Sicherheitsrichtlinienbindungen auf Authentifizierung und Zugriffsschutz.
- Klicken Sie unter "Token für Zugriffsschutz" auf den Namen des Tokenkonsumenten oder Tokengenerators.
- 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.
CWWSS5601E: Beim Entschlüsseln der Nachricht ist die folgende Ausnahme eingetreten:
com.ibm.pkcs11.PKCS11Exception: Another operation is already active
undCWWSS5601E: 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.