アウトバウンド JAX-WS 要求用の SPNEGO トークンの生成
com.ibm.wsspi.security.auth.krb5. SpnegoTokenHelper クラスを使用して、SPNEGO トークンをプログラマチックに作成することができます。
- Windows ネイティブ資格情報を使用して要求されるトークン。WebSphere® Java™ プロセスが、Kerberos 資格情報を持つユーザー ID を使用して Windows システムで実行されている場合、Windows OS がそのユーザー用の Kerberos Ticket Granting Ticket (TGT) を保守します。SpnegoTokenHelper クラスはその TGT を使用して SPNEGO トークンを要求し、そのトークンはターゲット・サービス・システムの ServicePrincipalName (SPN) のために要求できます。
- キャッシュに入れられた Kerberos 資格情報を使用して要求されるトークン。通常は Java kinit ツールなどのツールを使用して、ユーザーがログインしたシステムでは、そのユーザーの Kerberos 資格情報が krb5cc_<userid> という名前のキャッシュ・ファイルに保管されます。あるいは、Microsoft の ktpass ツールまたは Java ktab ツールなど、多くのツールを使用することによって、ユーザーの鍵を含むキータブ・ファイルを作成できます。 これらのファイルにはユーザーの Kerberos 鍵のコピーが含まれ、それを使用してそのユーザー ID 用の Ticket Granting Ticket (TGT) を取得できます。SpnegoTokenHelper クラスはその TGT を使用して SPNEGO トークンを要求し、そのトークンはターゲット・サービス・システムの ServicePrincipalName (SPN) のために要求できます。WebSphere プロセスは、krb5cc_<userid> またはキータブ・ファイルのいずれかを使用するように構成される必要があります。ファイル内にあるキャッシュされた資格情報の UserPrincipalName (UPN) も提供される必要があります。
- ユーザー ID とパスワードを使用する Kerberos 資格情報を使用して要求されるトークン。このシナリオでは、WebSphere プロセスは SpnegoTokenHelper クラスを使用して、提供されたユーザー ID とパスワードを使用して Kerberos 鍵配布サーバーに接続して Ticket Granting Ticket (TGT) を取得します。次に、 このクラスは、その TGT を使用して SPNEGO トークンを要求します。SpnegoTokenHelper クラスは、ターゲット・サービス・システムの ServicePrincipalName (SPN) と、ユーザー ID およびパスワードを必要とします。
- Java Subject 内に存在する Kerberos 資格情報を使用して要求されるトークン。Subject は以下のいずれかの方法で Kerberos 資格情報を取得できます。
- ユーザーはインバウンド SPNEGO Web 認証を使用して Web アプリケーションにログインしました。WebSphere Application Server において、このオプション用に SPNEGO Web 認証が構成および使用可能化されることのみが必要です。インバウンド SPNEGO サービスと関連付けられた Kerberos ユーザー ID がフル Kerberos 委任に使用可能にされる必要があります。
- WS-Security Kerberos トークンを含んでいる JAX-WS Web サービス要求が受信されました。インバウンド Web サービス要求と関連付けられた Kerberos ユーザー ID がフル Kerberos 委任に使用可能にされる必要があります。
- ユーザーがユーザー ID とパスワードでログインしました。WebSphere Application Server は LTPA および Kerberos 認証用に構成されました。
- パスワードと共にユーザー名トークンを含んでいる JAX-WS Web サービス要求が受信されました。 WebSphere Application Server は LTPA および Kerberos 認証用に構成されました。SpnegoTokenHelper クラスは、Subject 内の資格情報を使用して、ターゲット・サービス・システムの ServicePrincipalName (SPN) のためのサービス・チケットを要求します。この手法と関連付けられたメソッドは、SPN 値に加えて、Java Subject パラメーターを必要とします。
- 現行呼び出し元 ID の Java Subject 内の Kerberos 資格情報を使用して要求されるトークン。この手法は前の手法と似ていて、 現行呼び出し元 ID を取得するために SpnegoTokenHelper クラス内で便利メソッドを使用します。ここでも前述の Subject に関する制約は適用されます。この手法と関連付けられたメソッドでは、ServicePrincipalName (SPN) のみが必要です。
これら 5 つの手法すべてに、2 つのバリエーションがあります。 1 つ目のバリエーションでは、トークンの存続期間を指定でき、委任可能なトークンが要求される必要があることを示すブール値フラグがあります。2 つ目のバリエーションでは、 トークンの存続期間は無限であり、トークンは委任可能として要求されません。
5 つの手法すべてが、ストリングを 1 つ戻します (例えば、“Negotiate YIIFKwYG….”)。このストリングを使用してアウトバウンド Authorization ヘッダーを注入するのはプログラマーの責任です。
- ネイティブ資格情報に関する注意事項
- Microsoft Kerberos Logon Session 資格情報キャッシュ (MSLSA) は、
Kerberos Logon Session 資格情報キャッシュ (LSA) からのセッション鍵を含めて、Kerberos チケット全体を抽出する機能に依存します。セキュリティーを向上させるため、Microsoft は、Ticket Getting Tickets のためのセッション鍵をもうエクスポートしないフィーチャーを実装しました。
これにより、追加のサービス・チケットを要求する試みが行われるときに IBM® JGSS ではそれらが役に立たない可能性があります。この新フィーチャーは、
Windows 2003 Server 以降のシステムにあります。Microsoft は、この新フィーチャーを使用不可にするために以下のレジストリー・キーを提供しています。
HKEY_LOCAL_MACHINE¥SYSTEM¥CurrentControlSet¥Control¥Lsa¥Kerberos¥Parameters AllowTGTSessionKey = 0x01 (DWORD)
- Kerberos 構成ファイルにおける条件
- どの手法を使用するのかに関わらず、Kerberos 構成ファイルを正しく構成する必要があります。
- WebSphere プロセスが鍵配布センター (KDC) に到達する方法を、[realms] スタンザおよび [domain_realm] スタンザを介して正しく構成する必要があります。
- [libdefaults] スタンザで使用される暗号化タイプは、default_tkt_enctypes 値および default_tgs_enctypes 値を指定する必要があります。
- [libdefaults] スタンザは以下を含んでいる必要があります。
- forwardable = true
- renewable = true
- noaddresses = true
- [libdefaults] スタンザは、妥当な clockskew 値を定義する必要があります。
キータブの参照
JAASClientUsingKeytab {
com.ibm.security.auth.module.Krb5LoginModule required useKeytab="file:///C:¥¥WAS¥¥ND855¥¥profiles¥¥AppSrv01¥¥config¥¥cells¥¥testserver-vmCell01-855¥¥cachKerbUser.keytab" credsType=both
tryFirstPass=true forwardable=true noAddress=true;
};
SPNEGOTokenHelper クラスの使用例
最初の例では、 WebSphere プロセスを実行している Windows ネイティブ資格情報に基づくユーザー用に SPNEGO トークンが取得されます。
String nativeToken = SpnegoTokenHelper.buildSpnegoAuthorizationStringFromNativeCreds(spn, GSSCredential.INDEFINITE_LIFETIME, false);
- spn - この SPNEGO トークンがターゲットにされるシステムの ServicePrincipalName。例えば “HTTP/service.host.ibm.com@IBM.COM” といったストリングです。
- コンテキストの存続時間。この例では GSSCredential.INDEFINITE_LIFETIME です。
- 委任 - このトークンが委任可能な資格情報を含むかどうか。 この例では、このトークンは委任可能な資格情報を含みません。
2 つ目の例は、キータブ・ファイルまたはキャッシュ資格情報ファイルの使用法を示します。この例では、簡単なメソッドが使用されています (存続期間は指定されず、トークンは委任可能ではありません)
String token = SpnegoTokenHelper.buildSpnegoAuthorizationFromUpn(spn,upn, jaas);
- upn - ファイルからの ID の UserPrincipalName。例えば、alice@IBM.COM です。
- Jaas - 使用する JAAS 構成の名前 (キャッシュ資格情報ファイルのキータブを参照します (例えば “JAASClientUsingKeytab”))。
3 つ目の例は、ユーザー ID とパスワードを使用した Kerberos トークンの生成を示します。
String token = SpnegoTokenHelper.buildSpnegoAuthorizationFromUseridPassword(spn,userid,pwd,1000,true);
新しく導入されたパラメーターは、ユーザー ID とパスワードです。この例は、無限ではないトークンの要求も示しています。 このトークンは 1000 秒間存続するよう生成され、委任可能です (この spn と関連付けられたサービスで委任が使用可能にされている必要があります)。
4 つ目の例は、 Kerberos 資格情報を含む Subject から始めるという、あまり使用されることのないメカニズムを示しています。完全を期するためにこの例が示されていますが、 Subject の作成をプログラマチックに制御する場合を除いて、このメソッドを使用することはありません。
String token = buildSpnegoAuthorizationFromSubject(spn, subject);
String token = SpnegoTokenHelper.buildSpnegoAuthorizationFromCallerSubject(spn);
詳しくは、クライアント・ポリシー・セット・バインディングを使用したアウトバウンド JAX-WS 要求用 SPNEGO トークンの生成を参照してください。