Übersicht über die Verwendung von Kerberos für Web-Services
Sie können ein Kerberos-Token verwenden, das ähnliche Funktionen ausführt wie die, die Sie derzeit vielleicht mit LTPA- (Lightweight Third Party Authentication) oder Secure-Conversation-Token ausführen.
Tokengenerator
Nachdem das Kerberos-Token aus dem Key Distribution Center (KDC) erstellt wurde, verschlüsselt der WS-Security-Generator das Token, fügt es in die SOAP-Nachricht ein und gibt das Token weiter, damit es konsumiert bzw. akzeptiert wird. Wenn ein Schlüssel für Nachrichtenintegrität oder ein Nachrichtenvertraulichkeit erforderlich ist, wird ein Kerberos-Unterschlüssel oder ein Kerberos-Sitzungsschlüssel aus dem Kerberos-Ticket verwendet. Ein Schlüssel kann entweder aus dem Kerberos-Unterschlüssel oder aus dem Kerberos-Sitzungsschlüssel abgeleitet werden. Web Services Security verwendet den Schlüssel aus dem Kerberos-Token, um die Nachrichtenteile gemäß der Spezifikation "OASIS Web Services Security Kerberos Token Profile Version 1.1" zu signieren und zu verschlüsseln. Der Typ des zu verwendenden Schlüssels ist abhängig von der Konfiguration von Web Services Security oder der Sicherheitsrichtlinie. Die Größe des abgeleiteten Schlüssels ist ebenfalls konfigurierbar.
- Kerberos-Unterschlüssel, falls im Authentifikator vorhanden
- Sitzungsschlüssel direkt aus dem Ticket, wenn der Unterschlüssel fehlt
- Schlüssel, der aus einem der vorherigen Schlüssel abgeleitet wurde
- http://www.w3.org/2001/04/xmlenc#aes128-cbc
- http://www.w3.org/2001/04/xmlenc#aes256-cbc
- http://www.w3.org/2001/04/xmlenc#tripledes-cbc
- WebSphere Application Server unterstützt nur Kerberos Version 5.
- Sie können in Web Services Security nur dann eine symmetrische Algorithmus-Suite des Typs AES verwenden, wenn das Kerberos-Ticket mit RFC-4120 übereinstimmt.
- Ein Kerberos-Schlüssel mit dem Schlüsseltyp RC4-HMAC 128-Bit wird nur dann verwendet, wenn sich das KDC auf einem Server mit Microsoft Windows 2003 befindet.
- Ein Kerberos-Schlüssel mit dem Schlüsseltyp AES 128–Bit oder 256–Bit wird verwendet, wenn sich das KDC auf einem Server mit Microsoft Windows 2008 befindet.
- Ein Kerberos-Ticket muss weiterleitbar sein und darf keine Adresse enthalten, wenn der Service-Provider in einem Cluster ausgeführt wird.
- Wenn ein AES-256-Bit-Verschlüsselungsalgorithmus verwendet wird, müssen Sie eine uneingeschränkte Java™-Sicherheitsrichtlinie importieren.
Informationen zur Verwendung eines Kerberos-Tokens in einer realmübergreifenden oder vertrauenswürdigen Realmumgebung finden Sie im Artikel "Sicherheit von Kerberos-Token in einer Einzelrealm-, realmübergreifenden oder vertrauenswürdigen Realmumgebung".
Tokenkonsument
Der WS-Security-Konsument empfängt und extrahiert das Kerberos-Token aus der SOAP-Nachricht. Anschließend akzeptiert der Konsument das Kerberos-Token, indem er es mit seinem eigenen geheimen Schlüssel validiert. Der geheime Schlüssel des Service ist in einer exportierten Chiffrierschlüsseldatei gespeichert. Nachdem der WS-Security-Konsument das AP_REQ akzeptiert hat, speichert er die zugehörigen Anforderungstokeninformationen im Kontext-"Subject". Der zugehörige Schlüssel kann auch aus dem Anforderungstoken abgeleitet werden. Mit dem Schlüssel wird die Nachricht verifiziert und entschlüsselt. Wenn das Anforderungstoken weitergeleitet werden kann und keine Adresse enthält, kann der Anwendungsserver das gespeicherte Token auch für nachgeordnete Aufrufe verwenden.
Tokenformat und Tokenreferenz
Verwenden Sie für JAX-WS-Anwendungen den vorhandenen angepassten Richtliniensatz oder verwenden Sie die Scripts des Verwaltungsbefehls für die angepasste Richtlinie, um den Kerberos-Tokentyp, die Nachrichtensignatur und die Nachrichtenverschlüsselung festzulegen. Das JAX-WS-Programmiermodell für WebSphere Application Server stellt eine Minimalkonfiguration zur Aktivierung des Kerberos-Tokenprofils mit dem Kerberos-Token bereit.
Für JAX-RPC-Anwendungen müssen Sie den Implementierungsdeskriptor verwenden, um das angepasste Token anzugeben, das für das Kerberos-Token verwendet werden soll. Sie können das Kerberos-Token für die Authentifizierung verwenden, aber nicht für die Nachrichtensignatur oder -verschlüsselung.
- com.ibm.websphere.wssecurity.callbackhandler.KRBTokenConsumeCallbackHandler
Diese Klasse ist ein Callback-Handler für das Kerberos-Token der Version 5 auf der Konsumentenseite. Diese Instanz wird verwendet, um die Objekte "WSSVerification" und "WSSDecryption" zur Validierung eines binären Kerberos-Sicherheitstokens zu generieren.
- com.ibm.websphere.wssecurity.callbackhandler.KRBTokenGenerateCallbackHandler
Diese Klasse ist ein Callback-Handler für das Kerberos-Token der Version 5 auf der Generatorseite. Diese Instanz wird verwendet, um die Objekte "WSSSignature" und "WSSEncryption" zum Generieren eines binären Kerberos-Sicherheitstokens zu generieren.
Die Spezifikation "OASIS Web Services Security Kerberos Token Profile Version 1.1" legt fest, dass das Kerberos-Token mit dem Element <wsse:BinarySecurityToken> an die SOAP-Nachricht angehängt wird. Das folgende Beispiel zeigt das Nachrichtenformat. Die Informationen zum binären Sicherheitstoken sind von den anderen Teilen der Nachricht durch Fettdruck hervorgehoben.
<S11:Envelope xmlns:S11="…" xmlns:wsu="…">
<S11:Header>
<wsse:Security xmlns:wsse="…">
<wsse:BinarySecurityToken
EncodingType="http://docs.oasis-open.org/wss/2004/01/
oasis-200401-wss-soap-message-security-1.0#Base64Binary"
ValueType="http://docs.oasis-open.org/wss/
oasis-wss-kerberos-token-profile-1.1#Kerberosv5_AP_REQ"
wsu:Id="MyToken">boIBxDCCAcCgAwIBBaEDAgEOogcD…
</wsse:BinarySecurityToken>
…
</wsse:Security>
</S11:Header>
<S11:Body>
…
</S11:Body>
</S11:Envelope>
Das Kerberos-Token wird über das Element <wsse:SecurityTokenReference> referenziert. Das Element <wsu:Id>, das im Element <wsse:BinarySecurityToken> angegeben und im folgenden Beispiel in Fettdruck hervorgehoben ist, ermöglicht eine direkte Referenzierung des Tokens im Element <wsse:SecurityTokenReference>.
Der Attributwert @wsse:TokenType im Element <wsse:SecurityTokenReference> stimmt mit dem Attributwert ValueType im Element <wsse:BinarySecurityToken> überein. Das Attribut Reference/@ValueType ist nicht erforderlich. Wenn es jedoch angegeben wird, muss sein Wert mit dem Wert des Attributs @wsse11:TokenType übereinstimmen.
<S11:Envelope xmlns:S11="…" xmlns:wsu="…">
<S11:Header>
<wsse:Security xmlns:wsse="…">
<wsse:BinarySecurityToken
EncodingType="http://docs.oasis-open.org/wss/2004/01/
oasis-200401-wss-soap-message-security-1.0#Base64Binary"
ValueType="http://docs.oasis-open.org/wss/
oasis-wss-kerberos-token-profile-1.1#Kerberosv5_AP_REQ"
wsu:Id="MyToken">boIBxDCCAcCgAwIBBaEDAgEOogcD…
</wsse:BinarySecurityToken>
</wsse:Security>
</S11:Header>
</S11:Envelope>
<wsse:Security>
</wsse:Security>
<wsse:SecurityTokenReference
TokenType="http://docs.oasis-open.org/wss/
oasis-wss-kerberos-token-profile-1.1#Kerberosv5_AP_REQ">
<wsse:Reference URI="#MyToken"
ValueType="http://docs.oasis-open.org/wss/
oasis-wss-kerberos-token-profile-1.1#Kerberosv5_AP_REQ">
</wsse:Reference>
</wsse:SecurityTokenReference>
…
<wsse:Security>
</wsse:Security>
<S11:Header>
</S11:Header>
<S11:Body>
…
</S11:Body>
<S11:Envelope>
</S11:Envelope>
Mit dem Element <wsse:KeyIdentifier> wird eine Kennung für das Kerberos-Token angegeben. Der Wert der Kennung ist ein SHA1-Hash-Wert des verschlüsselten Kerberos-Tokens in der vorherigen Nachricht. Das Element muss über ein "ValueType"-Attribut mit dem Wert #Kerberosv5APREQSHA1 verfügen. Nachdem das ursprüngliche Kerberos-Token akzeptiert wurde, wird für den weiteren Nachrichtenaustausch die Referenzmethode "KeyIdentifier" verwendet. Im folgenden Beispiel werden die Informationen zur Schlüsselkennung in Fettdruck angezeigt:
<S11:Envelope xmlns:S11="…" xmlns:wsse="…" xmlns:wsu="…">
<S11:Header>
<wsse:Security>
…
<wsse:SecurityTokenReference
wsse11:TokenType=http://docs.oasis-open.org/wss/
oasis-wss-kerberos-token-profile-1.1#Kerberosv5_AP_REQ>
<wsse:KeyIdentifier
ValueType="http://docs.oasis-open.org/wss/
oasis-wss-kerberos-token-profile-1.1#Kerberosv5APREQSHA1">
GbsDt+WmD9XlnUUWbY/nhBveW8I=
</wsse:KeyIdentifier>
</wsse:SecurityTokenReference>
…
</wsse:Security>
</S11:Header>
<S11:Body>
…
</S11:Body>
</S11:Envelope>
Mehrere Referenzen auf das Kerberos-Token
Nachdem die Kerberos-Identität geprüft und vom Service validiert und akzeptiert wurde, ist es nicht erforderlich, dass der Client das Kerberos-Token nicht in jeder Anforderung sendet. Die Spezifikation "OASIS Web Services Security Kerberos Token Profile Version 1.1" empfiehlt die Verwendung eines mit SHA1 codierten Schlüssels mit dem Element <wsse:KeyIdentifier> im Element <wsse:SecurityTokenReference> für alle nachfolgenden Nachrichten, nachdem das ursprüngliche AP_REQ-Paket akzeptiert wurde. Allerdings ist es die Aufgabe der Laufzeitumgebung von Web Services Security, die Schlüsselkennung zur weiteren Verarbeitung einem zwischengespeicherten Kerberos-Token zuzuordnen. IBM® WebSphere Application Server 7.0 und höher bietet standardmäßig eine Unterstützung für dieses SHA1-Caching wie im Profil beschrieben. Allerdings stellt der Anwendungsserver auch die Funktionalität zum Generieren neuer AP_REQ-Token für jede Anforderung im vorhandenen Service-Kerberos-Ticket bereit. Wenn Sie mit Microsoft .NET arbeiten, sollte das pSHA1-Caching nicht verwendet werden. Generieren Sie ein AP_REQ-Paket für jede Anforderung.