Web サービスのための Kerberos の使用法の概要
現在 Lightweight Third Party Authentication (LTPA) トークンや Secure Conversation トークンなどの他のバイナリー・セキュリティー・トークンで完成されている関数と類似した関数を、Kerberos トークンを使用して完成させることができます。
トークン生成プログラム
Key Distribution Center (KDC) から Kerberos トークンが作成された後で、Web Services Security 生成プログラムは、そのトークンをエンコードして SOAP メッセージに挿入し、使用または受け入れが行われるようにそのトークンを伝搬します。メッセージ保全性鍵またはメッセージ機密性鍵が必要な場合には、Kerberos サブキー、または Kerberos チケットからの Kerberos セッション鍵が使用されます。 Kerberos サブキーからも Kerberos セッション鍵からも鍵を派生させることができます。 Web Services Security は、OASIS Web Services Security Kerberos Token Profile バージョン 1.1 仕様で説明されているように、Kerberos トークンから得られた鍵を使用してメッセージ・パーツに署名し、メッセージ・パーツを暗号化します。使用される鍵のタイプは、Web Services Security の構成またはポリシーによって事前に決定されます。また、派生鍵のサイズは構成可能です。
- Kerberos サブキーがオーセンティケーターに存在する場合には、その Kerberos サブキー
- そのサブキーが存在しない場合は、チケットから直接得られるセッション鍵
- 上記のいずれかの鍵から派生した鍵
- 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
- Application Server は Kerberos バージョン 5 のみをサポートします。
- Kerberos チケットが RFC-4120 に準拠している場合にのみ、Web Services Security で AES タイプの対称アルゴリズム・スイートを使用することができます。
- KDC が Microsoft Windows 2003 サーバー上にある場合、RC4-HMAC 128 ビット鍵タイプの Kerberos 鍵のみが使用されます。
- KDC が Microsoft Windows 2008 サーバー上にある場合、AES 128 ビットまたは 256 ビット鍵タイプの Kerberos 鍵が使用されます。
- サービス・プロバイダーがクラスター内で稼働している場合、Kerberos チケットは転送可能でなければならす、また、アドレスを含んでいてはなりません。
- AES 256 ビット暗号化アルゴリズムを使用する場合には、非制限 Java™ セキュリティー・ポリシーをインポートする必要があります。
相互レルム環境またはトラステッド・レルム環境における Kerberos トークンの使用については、トピック『単一、相互、またはトラステッド・レルム環境における Kerberos トークンのセキュリティー』を参照してください。
トークン・コンシューマー
Web Services Security コンシューマーは、SOAP メッセージから Kerberos トークンを受け取り、抽出します。そして、固有の秘密鍵を使用して Kerberos トークンを検証し、そのトークンを受け入れます。 サービスの秘密鍵は、エクスポートされたキー・タブ・ファイルに保管されます。トークンを受け入れた後で、Web Services Security コンシューマーは、関連した要求トークン情報をコンテキスト・サブジェクトに保管します。対応する鍵を派生させて要求トークンに含めることもできます。 この鍵は、メッセージの検証と暗号化解除に使用されます。 要求トークンが転送可能であり、アドレスを含んでいない場合、アプリケーション・サーバーは保管されたトークンをダウンストリーム呼び出しに使用することができます。
トークンのフォーマットおよび参照
JAX-WS アプリケーションの場合、既存のカスタム・ポリシー・セット、またはカスタム・ポリシー用の管理コマンド・スクリプトを使用して、Kerberos トークン・タイプ、メッセージ署名、およびメッセージ暗号化を指定できます。 WebSphere® Application Server 用の JAX-WS プログラミング・モデルは、Kerberos トークンで Kerberos トークン・プロファイルを使用できるようにするための最小限の構成を備えています。
JAX-RPC アプリケーションの場合、デプロイメント記述子を使用して、カスタム・トークンが Kerberos トークンを使用することを指定する必要があります。 Kerberos トークンを認証に使用することができますが、メッセージの署名または暗号化に使用することはできません。
- com.ibm.websphere.wssecurity.callbackhandler.KRBTokenConsumeCallbackHandler
このクラスは、コンシューマー側の Kerberos バージョン 5 トークン用のコールバック・ハンドラーです。このインスタンスは、WSSVerification オブジェクトおよび WSSDecryption オブジェクトを生成して Kerberos バイナリー・セキュリティー・トークンを検証するために使用されます。
- com.ibm.websphere.wssecurity.callbackhandler.KRBTokenGenerateCallbackHandler
このクラスは、生成プログラム側の Kerberos バージョン 5 トークン用のコールバック・ハンドラーです。このインスタンスは、Kerberos バイナリー・セキュリティー・トークンを生成するための WSSSignature オブジェクトと WSSEncryption オブジェクトを生成するために使用されます。
OASIS Web Services Security Kerberos Token Profile バージョン 1.1 仕様では、Kerberos トークンが <wsse:BinarySecurityToken> エレメントとともに SOAP メッセージに添付されるものと規定されています。 以下の例は、メッセージ・フォーマットを示しています。 太字体は、例の他の部分から得られるバイナリー・セキュリティー・トークン情報を表しています。
<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>
Kerberos トークンは、<wsse:SecurityTokenReference> エレメントによって参照されます。 <wsu:Id> エレメント (以下の例では太字体で示されています) は、<wsse:BinarySecurityToken> エレメント内で指定され、<wsse:SecurityTokenReference> エレメント内のトークンを直接参照します。
<wsse:SecurityTokenReference> エレメント内の @wsse:TokenType 属性値は、<wsse:BinarySecurityToken> エレメントの ValueType 属性値と一致します。 Reference/@ValueType 属性は必須ではありません。ただし、この属性を指定する場合、その値は @wsse11:TokenType 属性と等価でなければなりません。
<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>
<wsse:KeyIdentifier> エレメントは、Kerberos トークン用の ID を指定するために使用されます。ID の値は、上のメッセージで示したエンコード済み Kerberos トークンの SHA1 ハッシュ値です。 このエレメントの ValueType 属性の値は #Kerberosv5APREQSHA1 でなければなりません。 KeyIdentifier 参照メカニズムは、初期 Kerberos トークンが受け入れられた後のメッセージ交換で使用されます。 以下の例では、鍵 ID 情報が太字体で示されています。
<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>
Kerberos トークンへの複数の参照
Kerberos ID がサービスによって検証されて受け入れられると、クライアントは要求ごとに Kerberos トークンを送信する必要がなくなります。OASIS Web Services Security Kerberos Token Profile バージョン 1.1 仕様は、最初の AP_REQ パケットが受け入れられた後の後続の各メッセージに対し、<wsse:SecurityTokenReference> エレメント内の <wsse:KeyIdentifier> エレメントで SHA1 エンコード鍵を使用することを推奨しています。ただし Web Services Security のランタイム環境は、鍵 ID をさらに処理するために、キャッシュ Kerberos トークンにマップする必要があります。IBM® WebSphere Application Server 7.0 以降は、プロファイルで記載されたように、デフォルトでこの SHA1 キャッシングをサポートします。ただし、アプリケーション・サーバーは、既存のサービス Kerberos チケットを使用して要求ごとに新規 AP_REQ トークンを生成する機能も備えています。 Microsoft .NET と相互操作する場合には、pSHA1 キャッシングを使用せず、要求ごとに AP_REQ パケットを生成してください。