Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) Web 認証を WebSphere® Application
Server Liberty プロファイルに使用することによって、HTTP 要求にシングル・サインオンを使用できます。SPNEGO シングル・サインオンは、
HTTP ユーザーがデスクトップで Microsoft® ドメイン・コントローラーに一度だけログインして、
Liberty プロファイル・サーバーでのシングル・サインオン (SSO) を実現できるようにします。
始める前に
以下のソフトウェアを構成し、使用可能であることを確認してください。
- Active Directory ドメイン・コントローラーが稼働する Microsoft Windows®
Server および関連付けられた Kerberos 鍵配布センター (KDC)。このトピックでは、そのようなドメイン・コントローラーのホストの例は、myAdMachine.example.com です。
ドメイン・コントローラー名は mydomain.example.com であり、
Kerberos レルム名は、ドメイン・コントローラー名をすべて大文字にした MYDOMAIN.EXAMPLE.COM です。
- IETF RFC 2478 に定義された SPNEGO 認証メカニズムをサポートする Microsoft Windows® ドメイン・メンバー (クライアント)。適切なクライアントの例は、
最新のブラウザーまたは Microsoft .NET クライアントです。ほとんどの最新のブラウザーは SPNEGO 認証をサポートしています。このトピックでは、
クライアントのホストの例は、myClientMachine.example.com です。
- アプリケーション内に保護リソースを持つ Liberty プロファイル・サーバーがあるサーバー・プラットフォーム。Active Directory 内のユーザーは、
ネイティブ Liberty プロファイル・サーバー認証メカニズムを使用して Liberty プロファイル・サーバー保護リソースにアクセスできなければなりません。このトピックでは、
Liberty プロファイル・サーバー・ホストの例は myLibertyMachine.example.com です。
注: ソフトウェア構成には、
稼働しているドメイン・コントローラー、そのドメイン内の少なくとも 1 つのクライアント・マシン、および、
アプリケーション内に保護リソースを持つ Liberty プロファイル・サーバーがあるサーバー・プラットフォームがなければなりません。
つまり、合計 3 つのマシンが必要です。ドメイン・コントローラーから直接 SPNEGO を使用することはサポートされていません。
注: クライアント、Microsoft Active Directory サーバー、および Liberty プロファイル・サーバーで、
それぞれのクロックが互いに 5 分以内 (デフォルト) で同期していることを確認してください。同期に許容できる差異は構成可能です。
注: 現在は、
IBM® JDK のみがサポートされています。IBM 以外の JDK はサポートされていません。
このタスクについて
このタスクの目的は、ユーザーが再び認証を受けなくても Liberty プロファイル・サーバー・リソースに正常にアクセスできるようにすること、
すなわち、Microsoft Windows® デスクトップのシングル・サインオン機能を実現することです。
このタスクでは、
SPNEGO Web 認証の使用によって HTTP 要求のシングル・サインオンをサポートするよう Liberty プロファイル・サーバーを構成する方法を示します。
手順
- Microsoft ドメイン・コントローラー (myAdMachine.example.com) で、
Liberty プロファイル・サーバー用の Kerberos サービス・プリンシパル名 (SPN) およびキータブ・ファイルを作成します。:
- Liberty プロファイル・サーバー用のユーザー・アカウントを作成します。
これは、Kerberos サービス・プリンシパル名 (SPN) にマップするために使用されるアカウントです。Active Directory マシンでは、
これを行うには、通常、と進み、パネルで「ユーザー」を右クリックし、
を選択します。このトピックでは、
ユーザー myLibertyMachine_http がパスワード security で作成済みであると想定しています。
- Microsoft setspn コマンドを実行して、
ユーザー・アカウントを Kerberos SPN にマップします。このユーザー・アカウントは、
Liberty プロファイル・サーバーを、KDC のある Kerberos サービスとして表します。 以下に setspn コマンドの例を示します。
C:¥> setspn -a HTTP/myLibertyMachine.example.com myLibertyMachine_http
Registering ServicePrincipalNames for CN=myLibertyMachine_http,CN=Users,DC=MYDOMAIN,DC=EXAMPLE,DC=COM
HTTP/myLibertyMachine.example.com
Updated object
注: 使用する Microsoft setspn コマンドのバージョンで -S オプションがサポートされている場合は、
-A オプションの代わりに -S オプションを使用する必要があります。
- Microsoft ktpass ツールを使用して、Kerberos キータブ・ファイルを作成します。
このファイルのデフォルトの名前は krb5.keytab です。
以下に 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 がないことを確認してください。
- 使用する Microsoft setspn コマンドのバージョンで、
重複する SPN を検索するための -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
各種の KDC システム上での SPN およびキータブ・ファイルの作成について詳しくは、
Kerberos サービス・プリンシパル名およびキータブ・ファイルの作成を参照してください。
- Liberty プロファイル・サーバー・マシン (myLibertyMachine.example.com) で、
Kerberos キータブ・ファイル、構成ファイル、および SPNEGO Web 認証を使用可能にします。
- Kerberos キータブ・ファイルをドメイン・コントローラーから Liberty プロファイル・サーバー・マシンにコピーします。このファイルのデフォルトの名前は krb5.keytab であり、
デフォルトのロケーションは、プラットフォームによって異なりますが、Kerberos 構成ファイルと同じディレクトリーです。各種プラットフォームでのデフォルトのロケーションについては、
次のステップを参照してください。
- 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
注: 通常、レルム名は大文字で指定されます。Microsoft Active Directory を使用している場合、レルム名は大文字である必要があります。
注: 使用可能なすべての KDC ソリューションですべての暗号化タイプがサポートされるわけではありません。暗号化タイプを選択する前に、
Kerberos の管理者ガイドおよびユーザーズ・ガイドを参照して、使用したい暗号化タイプが KDC でサポートされていることを確認してください。
Kerberos 構成ファイル、Kerberos キータブ・ファイル、Kerberos SPN、および Kerberos クライアントで、暗号化タイプが共通していることを確認してください。例えば、
Kerberos クライアントが RC4-HMAC 暗号化タイプを使用する場合、
ターゲット・サーバーも RC4-HMAC 暗号化タイプをサポートしていなければならず、
Kerberos 構成ファイルでは default_tgt_enctypes パラメーターと default_tkt_enctypes パラメーターで先頭に RC4-HMAC がリストされている必要があります。
このファイルについての追加情報およびファイル内容の要件については、
Kerberos 構成ファイルの作成を参照してください。
- Kerberos 構成ファイルおよびキータブ・ファイルを検証します。
kinit コマンドの後、klist コマンドを使用して Kerberos チケットをリストできます。Kerberos チケットを取得できれば、Kerberos キータブおよび構成は有効です。
- Liberty プロファイル・サーバーで SPNEGO Web 認証を構成し、使用可能にします。
Liberty プロファイルの spnego-1.0 フィーチャーを使用可能にすることによって、SPNEGO Web 認証を使用可能にすることができます。
- 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 構成ファイルおよびキータブ・ファイルのデフォルトのロケーションは、このトピックの前半に記述されています。
- オプション: 必要に応じて、追加の構成オプションを指定します。
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" />
...
</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 カスタム・ログイン・モジュール・マッピングを使用しないことを明確に選択したユーザーのみが、どうしても必要な場合のみにしてください。
- クライアント・アプリケーション・マシン (myClientMachine.example.com) 上にクライアント・アプリケーションを構成します。
以下のステップは、クライアント・マシン上でのみ実行する必要があります。Active Directory マシンまたは Liberty プロファイル・サーバー・マシンでブラウザーを開始し、以下のステップを実行しても効果はありません。
以下のステップは、SPNEGO で保護されたリソースにブラウザーからアクセスするユーザー向けのものです。SPNEGO 認証をサポートしているブラウザーがインストールされている必要があります。
Microsoft Internet Explorer:
- デスクトップで、Windows Active Directory ドメインにログインします。
- Internet Explorer ウィンドウで、をクリックします。表示されるウィンドウで「セキュリティ」タブをクリックします。
- 「ローカル イントラネット」アイコンを選択し、「サイト」をクリックします。
- Internet Explorer バージョン 9 以前を使用している場合、次のステップに進みます。Internet Explorer 10 以降を使用している場合、「ローカル イントラネット」ウィンドウで「詳細設定」をクリックします。
- 「ローカル イントラネット」ウィンドウで、「この Web サイトをゾーンに追加する」フィールドに、ホスト名の Web アドレスを入力します。
これによって、「Web サイト」フィールドにリストされる Web サイトに対してシングル・サインオン (SSO) を使用可能にできるようになります。この情報を提供するのは、
サイトの情報技術スタッフです。2 番目の「ローカル イントラネット」ウィンドウを閉じ、
「OK」をクリックしてこのステップを完了し、「ローカル イントラネット」ウィンドウを閉じます。
- 「インターネット オプション」ウィンドウで、「詳細設定」タブをクリックし、
「セキュリティ」設定までスクロールします。「統合 Windows® 認証を使用する」ボックスが選択されていることを確認します。
- 「OK」をクリックします。この構成をアクティブにするため、Microsoft Internet Explorer を再始動します。
Mozilla Firefox:
- デスクトップで、Windows Active Directory ドメインにログインします。
- Firefox のアドレス・フィールドに about:config と入力します。
- 「フィルター/検索」ボックスに network.n と入力します。
- network.negotiate-auth.trusted-uris をダブルクリックします。
この設定は、ブラウザーで SPNEGO 認証を使用することを許可されたサイトをリストします。トラステッド・ドメインまたは URL をコンマ区切りリストの形式で入力してください。
注: network.negotiate-auth.trusted-uris の値は必ず設定する必要があります。
- デプロイされた SPNEGO ソリューションが Kerberos 拡張機能 Credential Delegation を使用している場合、network.negotiate-auth.delegation-uris をダブルクリックします。
この設定は、ブラウザーがサーバーにユーザー許可を委任できるサイトをリストします。トラステッド・ドメインまたは URL をコンマ区切りリストの形式で入力してください。
- 「OK」をクリックします。更新内容が構成に反映されます。
- この構成をアクティブにするため、Firefox ブラウザーを再始動します。
注: SPNEGO が機能するためには、ユーザーがドメイン・コントローラーにログインしている必要があります。前のマシン例を使用すると、
SPNEGO 認証がブラウザーを介して機能するためには、ユーザーは MYDOMAIN.EXAMPLE.COM¥username でドメイン・コントローラーにログインする必要があります。
注: ユーザー ID およびパスワードを求めるプロンプトが複数回表示される場合は、
前述の説明に従って、クライアント・ブラウザーで SPNEGO サポートを有効にしたことを確認してください。また、
<spnego> 構成で disableFailOverToAppAuthType 属性が false に設定されていることも確認する必要があります。
タスクの結果
これで、ご使用のインターネット・ブラウザーは SPNEGO 認証用に正しく構成されました。ユーザー ID およびパスワードを求めるプロンプトが出されることなく、
Liberty プロファイル・サーバーにデプロイされた、保護リソースが含まれるアプリケーションを使用することができます。
SPNEGO が機能していることを検証するには、
ドメイン・コントローラーにログインした後に、Liberty プロファイル・サーバー上の保護リソースにアクセスします。
そうすると、ドメイン・コントローラーにログインしているため、資格情報を求めるプロンプトは出されません。しかし、
ドメイン・コントローラーにログインしていないときに保護リソースにアクセスしようとすると、資格情報を求めるプロンプトが出されます。