Sicherheitsüberlegungen für Sicherheitssitzungen
Berücksichtigen Sie die folgenden Punkte, die sich bei der Implementierung von Sicherheitssitzungen auf die Sicherheit auswirken. Weitere Informationen zu Sicherheitsüberlegungen finden Sie unter Sicherheitsüberlegungen und bewährte Methoden für die Sicherheit.
Sicherheitssitzungen und Metadaten
Wenn eine sichere Sitzung aufgebaut wird und die RequireCancellation-Eigenschaft auf false gesetzt ist, sendet Windows Communication Foundation (WCF) eine mssp:MustNotSendCancel-Assertion als Teil der Metadaten im WSDL-Dokument (Web Services Description Language) für den Dienstendpunkt. Die mssp:MustNotSendCancel-Assertion informiert Clients, dass der Dienst nicht auf Anforderungen zum Abbrechen der sicheren Sitzung reagiert. Wenn die RequireCancellation-Eigenschaft auf true gesetzt ist, gibt WCF keine mssp:MustNotSendCancel-Assertion im WSDL-Dokument aus. Clients sollen eine Abbruchanforderung an den Dienst senden, wenn sie die sichere Sitzung nicht mehr benötigen. Wenn ein Client mit dem ServiceModel Metadata Utility Tool (Svcutil.exe) erstellt wird, reagiert der Client-Code entsprechend auf das Vorhandensein oder Fehlen der mssp:MustNotSendCancel-Assertion.
Sichere Unterhaltungen und benutzerdefinierte Token
Beim Mischen benutzerdefinierter Token und abgeleiteter Schlüssel ergeben sich aufgrund der Art der Definition in der WS-SecureConversation-Spezifikation einige Probleme. In der Spezifikation wird angegeben, dass es sich bei wsse:SecurityTokenReference um ein optionales Element handelt, das auf das abgeleitete Token verweist: "/wsc:DerivedKeyToken/wsse:SecurityTokenReference Dieses optionale Element dient zum Angeben des Sicherheitskontexttokens, Sicherheitstokens oder des freigegebenen Schlüssels für die Ableitung. Wird das Element nicht angegeben, wird davon ausgegangen, dass der Empfänger den freigegebenen Schlüssel dem Nachrichtenkontext entnehmen kann. Wenn der Kontext nicht bestimmt werden kann, sollte ein Fehler (beispielsweise wsc:UnknownDerivationSource) ausgelöst werden."
Das bedeutet, dass zum Ableiten eines benutzerdefinierten Tokens dessen Klauseltyp in ein SecurityTokenReference-Element eingeschlossen werden muss. Zwar steht eine Option zum Deaktivieren der Ableitung zur Verfügung, standardmäßig werden Schlüssel jedoch abgeleitet. Wird der Schlüssel nicht eingeschlossen, ist zwar die Serialisierung des abgeleiteten Schlüsseltokens erfolgreich, bei der Deserialisierung wird jedoch eine Ausnahme ausgelöst.