Liberty での SPNEGO 認証の構成

以下に ktpass コマンドの例を示します。

C:\> ktpass -out krb5.keytab -princ HTTP/myLibertyMachine.example.com@MYDOMAIN.EXAMPLE.COM -mapUser myLibertyMachine_http -mapOp set -pass security -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL

				Targeting domain controller: myAdMachine.MYDOMAIN.EXAMPLE.COM
				Using legacy password setting method
				Successfully mapped HTTP/myLibertyMachine.example.com to myLibertyMachine_http.
				Key created.
				Output keytab to krb5.keytab:
				Keytab version: 0x502
				keysize 93 HTTP/myLibertyMachine.example.com@MYDOMAIN.EXAMPLE.COM ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0x17 (RC4-HMAC) keylength 16 (0x148d643db283327d3f3d44547da8cade)

以下のいずれかのコマンドを使用して、Microsoft フォレスト内に重複する SPN がないことを確認します。

• 重複する SPN を検索するために Microsoft setspn コマンド・バージョンが -X オプションをサポートしている場合は、 setspn -Xを使用します。

  C:\>setspn -X HTTP/myLibertyMachine.example.com 
  
  Processing entry 0 
  found 0 group of duplicate SPNs. 

• Microsoft ldif コマンドを使用することもできます。 以下の例は、1 つの項目が返されたことを示しています。これは、重複する SPN がないことを意味します。

  C:\>ldifde -f check_SPN.txt -t 3268 -d "" -l servicePrincipalName -r " 
  (servicePrincipalName=HTTP/myLibertyMachine.example.com)" -p subtree 
  
  Connecting to "myAdMachine.MYDOMAIN.EXAMPLE.COM" 
  Logging in as current user using SSPI 
  Exporting directory to file check_SPN.txt 
  Searching for entries... 
  Writing out entries. 
  1 entries exported 

ktpass -in myOtherKrb5.keytab -out krb5.keytab -princ HTTP/myLibertyMachine.example.com@MYDOMAIN.EXAMPLE.COM -mapUser myLibertyMachine_http -mapOp set -pass security -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL

Targeting domain controller: myAdMachine.MYDOMAIN.EXAMPLE.COM
Using legacy password setting method
Successfully mapped HTTP/myLibertyMachine.example.com to myLibertyMachine_http.
Key created.
Output keytab to krb5.keytab:
Keytab version: 0x502
keysize 93 HTTP/myLibertyMachine.example.com@MYDOMAIN.EXAMPLE.COM ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0x17 (RC4-HMAC) keylength 16 (0x148d643db283327d3f3d44547da8cade)

異なる KDC システムでの SPN およびキータブ・ファイルの作成については、 Kerberos サービス・プリンシパル名およびキータブ・ファイルの作成を参照してください。

Kerberos 構成ファイルには、クライアント構成情報が含まれます。 この情報には、関心のあるレルム用の KDC のロケーション、現行の Kerberos レルムに対するデフォルト、ホスト名から Kerberos レルムへのマッピングが含まれます。 Liberty サーバーの場合は、このファイルを手動で作成する必要があります。

AIX、 z/OS、 HP-UX、または Solaris プラットフォーム (デフォルトのキータブ・ロケーションに基づく) 用の Kerberos 構成ファイルの例を以下に示します。

[libdefaults]
          default_realm = MYDOMAIN.EXAMPLE.COM
          default_keytab_name = FILE:/etc/krb5/krb5.keytab
          default_tkt_enctypes = rc4-hmac 
          default_tgs_enctypes = rc4-hmac 
          forwardable  = true
          renewable  = true
          noaddresses = true
          clockskew  = 300
          udp_preference_limit = 1
[realms]
          MYDOMAIN.EXAMPLE.COM = {
                kdc = myAdMachine.example.com:88
                default_domain = example.com
			}
[domain_realm]
        .example.com = MYDOMAIN.EXAMPLE.COM

Kerberos 構成ファイル、Kerberos キータブ・ファイル、Kerberos SPN、および Kerberos クライアントで、暗号化タイプが共通していることを確認してください。 例えば、 Kerberos クライアントが RC4-HMAC 暗号化タイプを使用する場合、ターゲット・サーバーも RC4-HMAC 暗号化タイプをサポートする必要があり、 Kerberos 構成ファイルの default_tgt_enctypes パラメーターと default_tkt_enctypes パラメーターに RC4-HMAC を最初にリストする必要があります。

このファイルの内容に関する追加情報および要件については、 Kerberos 構成ファイルの作成を参照してください。

Kerberos 構成ファイルおよびキータブ・ファイルを検証するには、klist コマンドと kinit コマンドを使用します。

• JDK コマンド klist を使用して、キータブ・ファイル内の SPN をリストできます。

  klist -k -t /etc/krb5.keytab

• JDK コマンド kinit を使用して、キータブ・ファイル内の SPN および Kerberos 構成ファイルを検証できます。

  kinit -k -t /etc/krb5.keytab HTTP/myLibertyMachine.example.com

kinit コマンドの後、klist コマンドを使用して Kerberos チケットをリストできます。 Kerberos チケットを取得できれば、Kerberos キータブおよび構成は有効です。

Libertyの spnego-1.0 フィーチャーを使用可能にすることにより、SPNEGO Web 認証を使用可能にすることができます。

1. spnego-1.0 フィーチャーを server.xml ファイルに追加します。

   <featureManager>
           <feature>spnego-1.0</feature>
           <feature>appSecurity-2.0</feature>
           ...
   </featuremanager>
   

   spnego-1.0 フィーチャーを追加すると、 自動的に一定の最小構成が行われます。 server.xml ファイルに <spnego> エレメントを指定する必要はありません。 <spnego> エレメントを指定しなくても、以下の構成が暗黙指定されます。

   <spnego
          canonicalHostName="true"
          disableFailOverToAppAuthType="true"
          trimKerberosRealmNameFromPrincipal="true"
          includeClientGSSCredentialInSubject="true" />
   

   注: ランタイムは、以下の形式でデフォルトの SPN を形成します。

   "HTTP/" + java.net.InetAddress.getLocalHost().getCanonicalHostName();

   このデフォルト SPN が krb5.keytab ファイル内にあるものと一致しない場合は、 次の例のように servicePrincipalNames を指定する必要があります。

   <spnego id="mySpnego" servicePrincipalNames="HTTP/myLibertyMachine.example.com"/>

   注: spnego-1.0 フィーチャーが有効になっていて、 <spnego> エレメントが省略されているか、 authFilterRef 属性を使用して構成されていない場合、保護リソースにアクセスするすべての要求で SPNEGO 認証が使用されます。

   認証フィルターの構成について詳しくは、 認証フィルターを参照してください。

   注: krb5Config 属性または krb5Keytab 属性の値が指定されていない場合は、それぞれのファイルがデフォルトの場所に存在することが予期されます。 各種プラットフォームでの Kerberos 構成ファイルおよびキータブ・ファイルのデフォルトのロケーションは、この例の前半に記述されています。
2. オプション: 必要に応じて、追加の構成オプションを指定します。 Liberty は、多くの一般的な SPNEGO シナリオおよび構成をサポートします。 例えば、特定の要求、Web アプリケーション、ホスト、またはユーザー・エージェントのみに SPNEGO 認証を必要とするように、HTTP 要求をフィルター操作できます。 また、Kerberos 構成ファイルおよびキータブ・ファイルをそれぞれのデフォルトのロケーションから移動することもできます。 以下に、 デフォルトの <spnego> 設定を変更する構成のサンプルを示します。

   <server>
           <featureManager>
                   <feature>spnego-1.0</feature>
                   <feature>appSecurity-2.0</feature>
                   ...
           </featureManager>
           ...
           <authFilter id="myAuthFilter">
                    <host id="myHost" name="example.com" matchType="contains" />
                    <webApp id="myWebApp" name="protectedApp" matchType="equals" />
           </authFilter>
   
           <spnego id="mySpnego"
                   includeClientGSSCredentialInSubject="false"
                   krb5Config="${server.config.dir}/resources/security/kerberos/krb5.conf"
                   krb5Keytab="${server.config.dir}/resources/security/kerberos/krb5.keytab"
                   servicePrincipalNames="HTTP/myLibertyMachine.example.com"
                   authFilterRef="myAuthFilter" />
           </spnego>        
           ...
   </server>

   この構成が使用される場合、受信した要求に SPNEGO 認証が使用されるのは、 Web アプリケーション protectedApp 内のリソースに対する要求で、ホスト名 example.com が含まれている要求に限られます。 また、クライアントの GSS 資格情報は、認証が成功したときにユーザー・サブジェクトに追加されません。 最後に、 サーバーによって使用される Kerberos 構成ファイルおよびキータブ・ファイルには、それぞれのデフォルトのロケーションの代わりに、 サーバー構成ディレクトリー内の特定のロケーションが指定されています。

   その他の構成オプションについては、 Simple and Protected GSS-API Negotiation Mechanism (SPNEGO)を参照してください。

   Kerberos プリンシパル名から WebSphere ユーザー・レジストリー ID へのマッピングについては、 クライアント Kerberos プリンシパル名から WebSphere ユーザー・レジストリー ID へのマッピングを参照してください。

   許可のために Kerberos プリンシパル名を使用する必要があるまれなケースでは、 SPNEGO 認証による許可のための Kerberos プリンシパル名の使用を参照してください。 これらのステップは、必要な場合にのみ、およびデフォルト・マッピングまたは JAAS カスタム・ログイン・モジュール・マッピングを使用しないことを明確に選択したユーザーのみが実行してください。

-Djava.security.krb5.kdc=myKdcMachine.example.com
-Djava.security.krb5.realm=EXAMPLE.COM