SPNEGO TAI : Windows から WebSphere Application Server へのシングル・サインオンの使用

サービス・プリンシパル名の使用に関するヒント

WebSphere Application Server の Simple and Protected GSS-API Negotiation (SPNEGO) Trust Association Interceptor (TAI) は、Microsoft Windows デスクトップと WebSphere ベース・サーバーとの間にシームレスなシングル・サインオン環境を実現するための強力なツールとなります。しかし一部のユーザーの環境では、SPNEGO TAI を使用する際にサービス・プリンシパル名の構成がうまくいかない場合があります。この記事では、Microsoft Active Directory と SPNEGO TAI を構成する場合のベスト・プラクティスをいくつか取り上げて説明します。

Martin Lansche, Consulting IT Specialist , IBM

Martin Lansche は、IBM Software Services for WebSphere に 所属する Consulting IT Specialist です。 彼は過去 14 年間にわたって、VM システムのプログラミングや C/C++ コンパイラー・ツールなど、 さまざまな分野の開発作業に携わってきました。ここ 8 年間は ISSW に勤務しており、 その初期には C++ サービスの実行を手がけ、最近ではKerberos と SPNEGO の使用による Active Directory 環境内での統合など、 カスタムの WebSphere セキュリティー・ソリューションに集中して取り組んでいます。 他の専門分野としては、WebSphere のパフォーマンスチューニングとトラブルシューティング、および WebSphere システム管理全般が挙げられます。 また、ヨーク大学にて数学とコンピューター・サイエンスの理学士号を取得しています。



2008年 9月 17日

はじめに

IBM WebSphere Application Server の Simple and Protected GSS-API Negotiation (SPNEGO) Trust Association Interceptor (TAI) は、Microsoft Windows デスクトップと WebSphere ベース・サーバーとの間にシームレスなシングル・サインオン環境を実現するための強力なツールとなります。WebSphere Application Server V6.1 インフォメーション・センターでは、WebSphere Application Server V6.1 における SPNEGO TAI の構成方法が説明されていますが、SPNEGO 機能については、ユーザーの混乱を招きうるポイントがいくつか存在します。

この記事では、よくある質問に回答していきます。構成の全体像については WebSphere Application Server インフォメーション・センターを参照してください。この記事では、一部の細かい事項について説明します。


SPNEGO とは

Active Directory (AD) ドメインを使用するよう構成された Windows デスクトップでは、コアとなる Kerberos に配置されたセキュリティー・インフラストラクチャーが使用されます。Kerberos には長年にわたって分散認証をサポートしてきた実績があり、TAI はその機能を活用しています。Microsoft では、Windows のクレデンシャルを Web サーバーと共有できるように、Protected GSS-API Negotiation Mechanism (SPNEGO) と呼ばれるプロトコルを使用して Kerberos を拡張しました。このプロトコルを使用すると、クライアント・マシンと Web サーバーが互いの通信に使用するプロトコルの種類についてネゴシエーションすることが可能となります。また、検証可能な認証データをクライアント・マシンから Web サーバーに送信する方法についても、このプロトコルによって定義されます。Web サーバーが SPNEGO トークンを理解すれば、そのトークンを使用してセキュアな SSO が実装されます。こうして、ユーザーの ID に関する Web サーバーとのネゴシエーションが、セキュアな方法で行われます。今日、ユーザーが Microsoft の Internet Information Server (IIS) にアクセスする際には、通常この方法が取られます。ここで注意が必要なのは、SPNEGO では、Kerberos をベースとする Active Directory クレデンシャル以外に、より旧式の (したがって安全性で劣る) NTLM クレデンシャルもサポートされるということです。これに対して IBM の TAI ソリューションでは、Kerberos ベースのクレデンシャルのみがサポートされます。また Tivoli Access Manager では、NTLM と Kerberos の両方のクレデンシャルがサポートされます。

SPNEGO は国際標準として認知されています。


WebSphere に SPNEGO を組み込む方法

SPNEGO を使用する SSO の実装方法は、WebSphere Application Server (以降、「Application Server」) のバージョンに応じて異なります。そうした各種アプローチについて言及する前に、まず WebSphere におけるセキュリティー概念についてご紹介しましょう。

WebSphere における Web 認証

最も基本的な例では、WebSphere Application Server の HTTP クライアント (Web ブラウザーなど) は、証明書に基づく単純な認証メカニズムか、あるいはユーザーID/パスワードによるチャレンジのみを受け付けます。いずれの場合も、フォームによるログインまたは BasicAuth チャレンジが使用されます。Trust Association Interceptors (TAI) と呼ばれる WebSphere Application Server の高度な認証機能を使用すると、第三者が WebSphere への要求送信に先立って認証を済ませていた場合に WebSphere がその認証結果を信頼して使用することが可能となります。

基本的には、アプリケーション・サーバーが要求を受信したときに適切な TAI が利用可能な状態であれば、Application Server セキュリティー・ランタイムから TAI に対して、ユーザーを識別するよう指示が送られます。TAI は一般に、Tivoli Access Manager WebSEAL などの認証プロキシーとの統合に使用されます。この種の認証プロキシー・サーバーは通常、認証を実行した後、独自のメカニズムと該当する TAI を使用して、WebSphere に対してユーザーのID 情報を反映させます。

WebSphere Application Server V6.1 の新機能に装備されている認証モデルは、Kerberos と SPNEGO プロトコルを使用する Windows デスクトップ認証をベースとしています。他の認証プロキシーでは通常、ユーザーにプロキシーへのログインを 1 回要求してから下流の全 WebSphere インスタンスにその ID 情報を反映させるという方法でシングル・サインオン (SSO) を実現しています。一方 SPNEGO TAI では、WebSphere Application Server がユーザーの Windows ドメイン・ログインを取り込み、表面上は見えない形でそのユーザーの Windows クレデンシャルを使用して、WebSphere に対するユーザー認証を行うことが可能です。言い換えれば、ユーザーは Windows ドメインのアカウントとパスワードを使用して Windows デスクトップに 1 回ログオンするだけで済むのです。ユーザーが WebSphere にアクセスすると、そのユーザーの Windows クレデンシャルがブラウザーに密かに要求され、自動的に WebSphere に対するユーザー認証が行われます。

WebSphere における Windows シングル・サインオンをサポートしているその他の製品

こうした Windows/WebSphere 統合を行いたいお客様にご利用いただける IBM ソリューションは、以下に示すように数々存在します。

  1. IBM がお届けする Tivoli Access Manager (TAM) V5.1 (およびそれ以降) と呼ばれる製品ソリューションには、SPNEGO を使用した Windows SSO の明示的サポートが組み込まれています。この TAM は、WebSphere のバージョン 5.x および 6.x で動作します。
  2. WebSphere Application Server バージョン 5.1.1.x および 6.0.x をお使いのお客様なら、IBM Software Services for WebSphere (ISSW) からカスタムのサービス・オファリング・ソリューションをご利用いただけます。このソリューションはソース・コード付きで提供されます。カスタム・コードの保守はお客様側で行っていただくことになります。WebSphere Application Server V5.1.1 および V6.0 に対応するこの ISSW の SPNEGO TAI サービス・オファリングについて、詳細情報が必要な場合は、IBM Software Services for WebSphere までお問い合わせください。
  3. WebSphere Application Server バージョン 6.1 には、完全サポートの製品コードとして、上記の ISSW バージョンをベースとする TAI が搭載されています。ただしこのバージョンについては、お客様にソース・コードは提供されません。

上記の 2 番目と 3 番目のオプションの問題点は互いに似通っているため、この記事では特にこの両オプションについて重点的に取り上げます。

WebSphere における SPNEGO の動作

このセクションでは、SPNEGO TAI 認証プロセスの主要な部分に注目します。

このシナリオでは、Windows 認証済み (つまり Active Directory クレデンシャル取得済み) のユーザーが、Web ブラウザー・クライアント (以降、「クライアント」) を使用して、SPNEGO をサポートする WebSphere サーバー上にデプロイされた Web アプリケーションを呼び出します。プロトコルの手順は以下のとおりです。

  1. ユーザーが、セキュアなWebリソースへリクエストを送信します。
  2. サーバーが、「Authenticate: Negotiate」ヘッダーを含む HTTP チャレンジ応答 (HTTP 401) を返します。
    1. クライアントは事前に「統合 Windows 認証」をサポートするよう構成されているため、この Negotiate ヘッダーを認識します。
    2. クライアントが、要求された URL を解析してホスト名を割り出します。
  3. クライアントが、Kerberos Authentication Service (AS) に Ticket Granting Ticket (TGT) を要求します。
  4. クライアントが、TGT を受け取ります。
  5. クライアントが、Kerberos Ticket Granting Service (TGS) に対して、SPN (例: HTTP/serverrc4.ibm.net@ IBM.NET) に対応するサービス・チケットを要求します。クライアントは、要求された URL を解析してプロトコルとホスト名を割り出すことによって SPN を構築し、クライアント自身のドメイン名を Kerberos セキュリティー・レルムとして使用します。つまり、<protocol>/<host's FQDN>@<Client's Kerberos Security Realm> という書式になります。ただし、環境を構成する際に SPN を Kerberos Key Distribution Center (KDC) に登録しなければなりません。
  6. クライアントが、サービス・チケットを受け取ります。
  7. クライアントが、最初にリクエストしたセキュアなリソースに再度リクエストを送信します。今回のリクエストには、暗号化された Kerberos サービス・チケット内にユーザー名 (SPNEGO トークンにカプセル化された形式) が組み込まれており、それが HTTP Authorization ヘッダーを使用して渡されます。
  8. アプリケーション・サーバーは、SPNEGO トークンとともに HTTP Authorization ヘッダーを確認します。SPNEGO トークンの抽出/復号 (この処理により、TGS から取得されたものであることが検証される) によってユーザー名が取得され、このユーザー名がサーバーに対してアサートされます。このユーザー名をプリンシパル (サーバーのレジストリー内で有効なもの) にマップすることが必要となる場合もあります。
  9. サーバーのセキュリティー・システムが、セキュリティー・レジストリーとの照合を行ってユーザーの妥当性を検証し、そのユーザーに関するその他のセキュリティー情報を取得します。これで、ユーザーがサーバーにログインされます。
  10. サーバーは、このユーザーのセキュリティー情報を Java™ Subject と呼ばれるメモリー内オブジェクトにキャッシュすることによって、以後の認証チャレンジを回避します。
  11. サーバーが、コンテンツに LTPA トークンを組み入れ、それをクッキーとしてユーザーに返送します。このクッキーは、同じ WebSphere SSO ドメインに対するそれ以降の要求を再認証なしに送信可能にするものです。
    1. ユーザーに目的のリソースに対するアクセス権限がある場合は、HTTP 200 の応答が返され、要求されたリソースが提供されます。
    2. アクセス権限がない場合は、クライアントに対して「HTTP 403 Not Authorized」応答が送信されます。

図 1 は、上記のシナリオ中に実行される手順を図示したものです。

図 1. SPNEGO の概要
SPNEGO の概要

このシナリオでは、ユーザーに対して認証の画面は出されていません。ここでは、クライアントがサーバーに向けて、ユーザーの既存の AD クレデンシャルを単純に「流して」いるだけです。ユーザーがサーバーにアクセスする際には、Windows のクレデンシャルが使用されます。ターゲットの WebSphere サーバーにログインするよう画面上でユーザーに表示されることは、一切ありません。

SPNEGO での Windows 使用の必要性

この記事では、このセクション以外の記述に、意図的にぼかした表現を使用しています。厳密に言えば、必ずしも Windows を使用する必要はないからです。正確な事情を以下に示しましょう。

  • WebSphere Application Server が Windows サーバーである必要はまったくありません。実際、Windows 上で Application Server を実行する際には回避すべき地雷原が存在するということは、既に判明しています (これについては、後掲のセクションで説明します)。IBM には、実際のお客様環境において、WebSphereがサポートする大半のプラットフォーム上で、SPNEGO TAI ソリューションをデプロイしてきた実績があります。
  • デスクトップは、Windows デスクトップでなくてもかまいません。Kerberos ログインをサポートし、Web クライアントに SPNEGO プロトコルのサポートが組み込まれていれば、どのようなデスクトップでも動作します。具体的には、Linux や Apple のデスクトップが使用可能です。IBM は、そのような環境向けの SPNEGO TAI ソリューションの構成作業を経験しています。
  • Information Center では、「Kerberos Key Distribution Center (KDC) および Ticket Granting Server (TGS) は Windows 2000 サーバーまたは Windows 2003 サーバーでなければならない」と規定されています。
  • WebSphere レジストリーは、Microsoft Active Directory(Lightweight Directory Access Protocol (LDAP) サーバーとして構成)で構成する必要はありません。一般に、サービス・チケットから取得されるユーザー ID は Kerberos UserPrincipalName と呼ばれます。Microsoft では、これを特に ClientPrincipalName と称しています。このユーザー ID を、WebSphere セキュリティー・レジストリー内で有効な名前にマップする必要があります。最も単純なマッピング方法は、WebSphere レジストリーが、Active Directory によって提供される LDAPサーバーになっているというものです。IBM には、以下のような WebSphere レジストリーでさまざまなマッピング (些細なものから主要なものまで) を使用して SPNEGO TAI をデプロイしてきた豊富な経験があります。
    • 1 つ以上の LDAP レジストリーで構成される、WebSphere のフェデレーテッド・ポジトリー
    • 単一 Active Directory ドメインの LDAP
    • 1 つの Active Directory フォレストとして構成された、Active Directory LDAP サーバーのセット
    • IBM Tivoli Directory Server LDAP
    • Domino LDAP
    • z/OS RACF レジストリー
    • カスタム・ユーザー・レジストリー (各種)

これらのマッピング・ソリューションでは、お客様固有のカスタム・コードの作成が必要となります。このコードは通常、「TAI によって構築された、Windows の ID 情報を含む Java Subject」を「WebSphere レジストリー内で有効となるマップ先ユーザー ID を含む、新しい Java Subject」に変える、LoginModule の形で作成されます。この種の LoginModule を作成するには専門技術者による支援が必要で、その仕組みについてはこの記事では取り上げません。

この記事内のほかのセクションに「Windows」という語句が含まれていたとしても、それは典型例を示すものであって、必ずしも必要なものではありません。


Kerberos プリンシパル名の実体、および WebSphere との関係

ここまでは、SPNEGO プロトコルの内容と SPNEGO TAI の動作の仕組みについて概説してきました。ここからは、Kerberos ベース・セキュリティー・システムに詳しくない読者向けに、混乱を招きがちないくつかの問題点について解説していきたいと思います。それらの問題点の多くは、Kerberos プリンシパル名のトピックに関連するものです。では、プリンシパル名とは何でしょうか。

Kerberos でプリンシパル名を使用する目的は、Kerberos 内の「プリンシパル」を識別することにあります。プリンシパルは、エンド・ユーザーやシステムを表現するほか、一時的な ID 情報を表現する場合もあります。

ユーザー・プリンシパル名

従来の Kerberos システムにログインする場合、その処理は通常 UserPrincipalName を使用して行われます。ユーザーの UserPrincipalName は通常「userid@REALM」という形式であり、例えば「lansche@IBM.NET」のようになります。Windows ドメインにログインする場合には、sAMAccountName とも呼ばれる Windowsのユーザー・ログオン名 (Windows 2000 以前のもの) を使用します。

このことについて、図 2 に示した Windows のアカウントの例で考えてみましょう。赤線で囲まれたフィールドが sAMAccountName です。

図 2. 典型的 Windows Active Directory ユーザーのプロパティー・シート
典型的 Windows Active Directory ユーザーのプロパティー・シート

Microsoft のシステムでは、Active Directory 内のユーザーに対応した UserPrincipalName も格納されます。これは「ユーザー・ログオン名 (User logon name)」とレルム名 (上図の例では「@ibm.net」) で構成されたものです。一方、SPNEGO ネゴシエーションからは、Microsoft が ClientPrincipalName と称する名前が返されます。この名前は、sAMAccountName と Kerberos レルムを組み合わせたものです。デフォルトでは、Active Directory 内のユーザーの ClientPrincipalName と UserPrincipalName は同一となりますが、常にそうであるとは限りません。図 3 に示した第 2 のアカウントについて考えてみましょう。

図 3. 一般的ではないが有効なユーザー ID の、プロパティー・シート
一般的ではないが有効なユーザー ID の、プロパティー・シート

図 4 は、「botzum@ibm.net」という UserPrincipalName (検索可能な LDAP 属性) を有するアカウントを示しています。

図 4. 一般的ではないユーザーの UserPrincipalName を示す LDAP ブラウザーのビュー
一般的ではないユーザーの UserPrincipalName を示す LDAP ブラウザーのビュー

ところが図 5 が示すように、sAMAccountName は「keys」となっています。

図 5. 一般的ではないユーザーの sAMAccountName を示す LDAP ブラウザーのビュー
一般的ではないユーザーの sAMAccountName を示す LDAP ブラウザーのビュー

したがって、このユーザーの ClientPrincipalName (検索可能な LDAP 属性ではない) は「keys@IBM.NET」となります。

デフォルトでは、「ユーザー・ログオン名 (User logon name)」と「sAMAccountName」には同一の値が初期設定されますが、それらの値を変更できない理由はありません。企業によっては、sAMAccountName を変更するポリシーを施行している例もあります。しかし、このことが SPNEGO TAI に破壊的な問題を引き起こす場合もあります。というのも、SPNEGO TAI が確認するのは sAMAccountName だけであり、そこから引き出した情報をレジストリー内の検索可能な名前にマップするという作業が必要だからです。sAMAccountName が一意であれば、その検索は可能です。ところが残念ながら、sAMAccountNames の一意性が保証されているのは単一ドメイン内だけです。Active Directory フォレストを運用している場合は、同一フォレスト内の複数のドメイン間で sAMAccountNames が重複する可能もあります。

要するに、SPNEGO TAI のデプロイメントを計画する際には、ユーザーのプリンシパル名を WebSphere レジストリーにとって有効な名前にマッピングすることが必須です。すべてのユーザーが単一の Active Directory ドメインに属し、WebSphere レジストリーがその単一 Active Directory の LDAP に対応するよう構成されているならば、マッピングは必要ありません。しかしユーザーがフォレスト内の複数の Active Directory ドメインに分散し、WebSphere レジストリーが LDAP 経由でそのフォレストに対して構成されているならば、「ユーザー・ログオン名」と「sAMAccountName」との食い違いがマッピングの問題を引き起こす可能性があります。また、別レジストリーに対するマッピングの場合は、カスタムの JAAS ログイン・モジュール内での処理内容に依存している必要があります。その種のマッピングについては、この記事では取り上げません。

サービス・プリンシパル名

Kerberos のプリンシパルは、システムやサービスを表現する場合もあります。サービスのプリンシパル名 (SPN: ServicePrincipalName) の形式は、「SERVICE/name@REALM」となります。文字列「SERVICE」の部分に実際に入る値は、規約で定められています。説明の都合上、ここでは Active Directory と SPNEGO で使用される以下の 2つの重要規約に注目します。

  • Web サーバーの SPN には、先頭に文字列「HTTP/」が付きます。この接頭部は、使用されるプロトコルが HTTP と HTTPS のどちらであるかには関係ありません。例えば、「http://someserver.ibm.net」に置かれた Web サーバーの SPN であれば、「HTTP/someserver.ibm.net@IBM.NET」となります。Active Directory では、「HTTP/」の付いたすべての SPN が、Windows サービス・アカウントに追加されます。Active Directory におけるサービス・アカウントとは、「何らかのアプリケーションまたはサービスをサポートするために存在すること」が存続期間全体にわたる唯一の役割であるアカウントのことです。SPNEGO TAI の場合は、SPN を「所有すること」を唯一の目的としてサービス・アカウントが作成されます。1 つのサービス・アカウントに対して複数の SPN の定義が可能であるという点に注意してください。すなわち、1 つのサービス・アカウントが「HTTP/」付きの SPN を複数「所有」する場合があるということです。
  • 「コンピューター」タイプの Active Directory オブジェクトも Kerberos サービスであり、SPN を有します。その SPN の先頭には「HOST/」が付きます。例えば、IBM のテスト用 AD レルム「IBM.NET」内に配置された「wasserv01」という名前の「コンピューター」オブジェクトには、次の 2 つの SPN が定義されることになります。
    • HOST/wasserv01@IBM.NET
    • HOST/wasserv01.ibm.net@IBM.NET

SPNEGO TAI をデプロイする際によく発生する問題は、Active Directory 内で SPN の名前が衝突するというものです。

推奨事項: SPNEGO へのアクセスは常に仮想ホスト名を介して行ってください。

質問: ブラウザーからアプリケーションへのアクセスに、http://someserver.ibm.net の代わりに http://wasserv01.ibm.net を使用するよう変更した場合、この要求に対応するサービス・チケットを求められた AD が使用するのはどちらの SPN ですか。

回答: HOST/wasserv01.ibm.net@IBM.NET です。SPNEGO TAI 使用時には、このことが問題の原因となります。

純粋な Kerberos システム内では、鍵の検証は以下の 2種類の方法のいずれかで行われます。

  • TGS/KDC にコンタクトする
  • 秘密鍵 (TGS/KDC と共有されるもの) を内包した keytab ファイルを使用する

SPNEGO TAI では、この検証を実行する際、共有秘密鍵を内包した keytab ファイルによる方法のみが使用されます。KDC におけるユーザー・アカウント用のパスワードが、この共有秘密鍵となります。Active Directory 内の「コンピューター」オブジェクトに対してパスワードを定義する手段は存在しないため、カスタムのサービス・アカウントに対するパスワードを設定したうえで、そのアカウントに対して SPN を定義しなければなりません。ある SPN と一致する可能性のあるオブジェクトが Active Directory 内に複数存在する場合、AD はサービス・チケット構築時に「HTTP/」の SPN ではなく「HOST/」の SPN のほうを選択します。このことは、SPNEGO TAI にとっては明らかに問題発生の原因となります。というのも、SPNEGO TAI は、(keytab ファイルに組み込まれている) サービス・アカウント対応パスワードに基づく共有秘密鍵を使用してサービス・チケットの復号を試みることになるからです。

Windows コンピューター・オブジェクト上で WebSphere Application Server が稼働している場合、サービス・チケットは「HTTP/」ではなく「HOST/」の SPN に対して発行されます。したがって、HTTP 要求内でそのコンピューターのホスト名を使用することはできません。つまり、使用したいサーバーの SPN に対応する第 2 のホスト名が必要になるのです。興味深いことに、これが問題となるのは小規模なサンドボックス・システムや PcC (Proof of Concept, 概念検証) システム、または開発者用環境の場合だけです。

ほとんどの典型的な「実世界」の WebSphere環境においては、ソリューション内に特別なネットワーク・コンポーネントをデプロイすることによってこの問題を解決しています。通常は、少なくとも 2 台のマシン上でアプリケーション・サーバーのクラスターを稼働させています。ユーザーの側からは、例えば「someserver.ibm.net」という名前の、いつでも利用・拡張が可能な単一の大規模サーバーが存在するように見えます。実際には、ユーザーの要求は多数のマシンを経由してからアプリケーション・サーバー上で処理されます。この仕組みの実現に使用されているのが、仮想ホスト名という魔法です。図 6 は、「実世界」の最小構成の WebSphere 環境を示したものです。

図 6. 「実世界」における最小構成の WebSphere 環境
「実世界」における最小構成の WebSphere 環境

この環境では、ユーザーが「http://wasserv01.ibm.net」を使用してアプリケーションにアクセスすることはありません。そのホスト名は、この実世界の事例では無用の存在です。実際は、上図で示したファイアウォールによって、そうしたアクセスは阻止されてしまいます。同様に、個々の Web サーバーの名前がユーザーに知られたり、アクセスされたりすることもありません。

実際のマシン名がユーザーに知られることが多く、名前衝突の問題が発生しやすいのは、単一マシンの単純な Windows 環境の場合です。この名前衝突の問題を回避するには、そうした単純な環境を、上図で示した複雑な環境を簡略化した構成として扱えるようにします。上図の構成からファイアウォール、スプレイヤー、冗長サーバーを取り除き、さらに Web サーバーと Application Server の階層もまとめてしまえば、図 7 に示したシナリオに行き着きます。

図 7. シンプルなサンドボックス/開発者用環境
シンプルなサンドボックス/開発者用環境

名前衝突の問題を回避するには、ユーザーがサーバーにアクセスする際に、そのマシンの実際のWindows ホスト名ではなく仮想ホスト名を使用する必要があります。PoC 用または開発用のサーバーである場合は、etc/hosts ファイルを手作業でコーディングし、DNS によるホスト名解決をバイパスするという方法が、簡単な回避策でしょう。実動サーバーの場合は、そのサーバーの IP アドレスに対応する第 2 の DNS ホスト・レコードを追加しなければなりません。この問題の解決に DNS エイリアスを使用しない理由については、後掲セクションの説明を参照してください。

このトピックを終える前に、Application Server の手前に Windows ベースの Web サーバーが配置された、やや大規模な環境について考えてみましょう。このケースでは、ユーザーは Web サーバーの真のホスト名を使用することはできません。その代わりに仮想ホスト名を使用し、その Web サーバー・コンピューターに対応する Active Directory 内の「コンピューター」オブジェクトとの名前衝突を回避します。図 8 は、典型的な 2 マシン構成を示したものです。

図 8. 典型的な 2 マシン構成の WebSphere 環境
典型的な 2 マシン構成の WebSphere 環境

使用する SPN の個数

前セクションでは、AD 内コンピューター・オブジェクトのホスト名を使用することに起因する SPN 名前衝突の問題について説明しました。一般的に言えば、「サービスごとに SPN を 1 つずつ使用する」というのがここでのベスト・プラクティスです。そしてこの方法の基盤となるのが、ユーザーのブラウザーのアドレス・フィールドで認識される Web アプリケーションの仮想ホスト名です。環境の複雑さや単純さに関係なく、これが実際の方法です。


複数の SPN の使用が推奨されるケース

構成内に複数の SPN を使用することが推奨されるのは 1 つのケースに限られます。すなわち、WebSphere セル全体が複数のアプリケーションをサポートしていて、それらのアプリケーションが別々の仮想ホスト名でホストされているという場合です。これは、一般的なデプロイメントの範囲を超え、複雑な議論の領域となります。

このケース以外の場合、アクセス・パスに関係なくアプリケーションに対する SSO アクセスが機能するように複数の SPN を構成することは、お勧めしませんので、その点にご注目ください。図 9 に示したこの種の悪い例について、考えてみましょう。

図 9. WebSphere 用の SPN セットアップの悪い例
WebSphere 用の SPN セットアップの悪い例

ここで示されているのは、可能なあらゆるホスト名 (下記) を使用した SPNEGO の SSO アクセスをすべて許可するという考え方です。

  • http://someserver.ibm.net
  • http://webserv01.ibm.net
  • http://webserv02ibm.net
  • http://wasserv01.ibm.net
  • http://wasserv02.ibm.net

このようなデプロイメントは、どのような状況から生まれるのでしょうか。よく見られるのは、1 台のサーバー (例えば wasserv1.ibm.net) からシステムが構築され、そのサーバーに対して SPNEGO が構成されるというケースです。開発者はそのホスト名を使いますが、その後のシステム展開に応じて、サーバーはクラスター化されていきます。その結果、第 2 のサーバー (wasserv2.ibm.net) が構成に追加されます。そして SPNEGO の機能が損われていないように、keytab ファイルに第 2 の SPN が追加されます。ユーザーは、2 つの WebSphere インスタンスのどちらを使用してもアプリケーションにアクセスできます。

ここで、Web コンテナーの WebSphere インスタンス上でアプリケーションに直接アクセスするという方法は実動システム上での処理を忠実にモデル化したものではないということに開発者が気付き、新たな Web サーバーを 1 台導入します。続いて、SPNEGOが動作するように、webserv1.ibm.net に対応する第 3 の SPN が追加されます。そして最後に、本番稼働環境に移行する前に第 2 の Web サーバーが追加されて、そのサービスに対応する第 4 の SPN が追加されます。さらに、本番稼働環境への移行直前になって、IP スプレイヤーへのアクセスが取得されます。IP スプレイヤーにも独自のホスト名があるため、開発者は第 5 の SPN (someserver.ibm.net) を追加します。

SPNEGO TAI をこのような方法で構成することは可能ですが、このような構成を通常行うべきではありません。これらのサーバーが AD フォレスト内の Windows サーバーである場合、前述した名前衝突の問題がすべて降りかかることになります。さらに言えば、ユーザーによる内部サーバーへの直接アクセスは避ける必要があるという観点から見て、このようなアクセス方法は実動システムに対する通常のあらゆるセキュリティー強化策に反しています。

この種のテスト用アクセスが必要な場合には、テスターのデスクトップ上で etc/hosts ファイルを編集してください。ターゲットとするアクセス・ポイント用に someserver.ibm.net と同等の IP アドレスを入力し、SPNEGO の SSO をテストしてください。コード例を以下に示します。

127.0.0.1       localhost 
# SPNEGO TAI Lab - uncomment the access point you want
9.26.20.145	someserver.ibm.net #Really wasserv01.ibm.net
#9.26.20.146	someserver.ibm.net #Really wasserv02.ibm.net
#9.26.20.147	someserver.ibm.net #Really webserv01.ibm.net
#9.26.20.148	someserver.ibm.net #Really webserv02.ibm.net

Active Directory における SPN の設定対象

SPN のトピックを終える前に、「Active Directory の世界では SPN をどこに設定することになっているのか」という疑問にお答えします。前掲のセクションでは、AD Key Distribution Center (KDC) と共用される秘密鍵を内包した keytab ファイルについて紹介し、その共有秘密鍵が AD 内の「ユーザー ID」パスワードであることを説明しました。AD ドメイン管理者は、ktpass ツールを使用して以下の作業を行います。

  • アカウントに対して SPN を設定する
  • 他の Kerberos システムで使用するための鍵を keytab ファイル内に作成する

では、どのユーザー ID を使用すればよいのでしょうか。

今までのお客様事例では、WebSphere 用 AD で使用するユーザー ID 数を可能な限り少なくするという、誤った方法を取ろうとしていたケースがありました。WebSphere 6.1 では、スタンドアロン LDAP レジストリーを経由する方法か、あるいはフェデレーテッド・レジストリーの一部として組み入れる方法によって、AD を LDAP として使用しているため、以下の各アカウントを定義する必要があります。

  • LDAP バインドのアカウントとパスワード: これは、WebSphere ランタイムが LDAP の検索とクエリーを行う際に使用するアカウントです。例えば、多くの場合は「wasbind」アカウントが使用されます。
  • サーバーのユーザー ID: V6.1 の場合、この ID 情報の使用はオプションです。V6.0 以前のバージョンの場合は、オプションではありません。WebSphere のさまざまなプロセスで、互いの認証を目的としてこの情報が使用されます。具体的には、ユーザー ID とパスワードが必要です。このアカウントは、通常は「wasserver」となります。
  • プライマリー管理ユーザー ID: これは、レジストリー内の「実際のユーザー」に対して必要な管理権限を付与することを唯一の目的とする、上級管理者用のアカウントです。多くの場合は、「wasadmin」アカウントが使用されます。

最初の 2 つのアカウントは、レジストリー内では「サービス・アカウント」と見なされます。これらのアカウントでは、何らかのオペレーティング・システム (OS) 権限を特別に必要とすることはありません。これらのアカウント用のパスワードは変更が制御されているため、変更が自動的に許可されることはありません。レジストリー内で変更されたパスワードが WebSphere 構成内では変更されていない場合、WebSphere は正常に機能しなくなります。一方、プライマリー管理アカウント用のパスワードについては、WebSphere 内の構成を変更することなく、変更することが可能です。

質問: SPN は、上記のどのアカウントに対して設定すべきでしょうか。

回答: どれに対しても設定すべきではありません。ベスト・プラクティスとして推奨されるのは、「wasspnegospn」などの名前で第 3 のサービス・アカウントを作成し、そのアカウントに対して ServicePrincipalName を定義するという方法です。

注: 上記の 3 種類のアカウントは、どれも使用しないでください。使用すると、運用上の問題点が発生します。特に、このサービス・アカウント用のパスワードを変更した場合には、keytab ファイルを再作成して WebSphere セル全体に再配布しなければなりません。そのためには、WebSphere の停止が必要です。

どうしても SPNEGO 構成内で複数の SPN を使用なければならない場合には (そのような措置が唯一推奨される状況については、前セクションの「複数の SPN の使用が推奨されるケース」を参照してください)、複数の SPN を単一アカウント上の 1 つのグループとして統合し、WebSphere 構成内の共通アプリケーション・クラスターで使用される可能性があるすべての SPN をそのアカウントに対応付けるという方法が推奨されます。表 1 に示したセル・コンテンツの例について考えてみましょう。このセルでは、3 つの業務部門が所有する 4 種類のアプリケーションがホストされています。

表 1. 複数のアプリケーション、仮想ホスト、SPN を有する、実世界のセル
クラスターアプリケーション仮想ホストSPN
アプリケーション・クラスター App1 および App2 app1.ibm.net および app2.ibm.net HTTP/app1.ibm.net@IBM.NET および
HTTP/app2.ibm.net@IBM.NET
Portal Portal portal.ibm.net HTTP/portal.ibm.net@IBM.NET
HR HR hr-sys.ibm.net HTTP/hr-sys.ibm.net@IBM.NET

ユーザー側から見れば 4 種類の異なった仮想ホストが存在することになるため、4 つの SPN が必要であることは明らかです。Portal と HR の両アプリケーションは、それぞれの WebSphere クラスター上で稼働しています。この両者については、表 2 に示すように、単一の SPN を有するサービス・アカウントを個別に設定するというサービス方法が最も適しています。

表 2. サービス・アカウントに対する SPN のマッピング
アプリケーションSPNサービス・アカウント
Portal HTTP/portal.ibm.net@IBM.NET Svc_PortalSPN
HR HTTP/hr-sys.ibm.net@IBM.NET Svc_HRSPN

「アプリケーション・クラスター」については、慎重な分析が必要となります。この 2 つのアプリケーションが密結合の関係にある (すなわち、ともにデプロイされ、同時に実行する必要があり、ライフ・サイクルが互いにリンクしており、共通の業務部門によって所有されている) 場合は、単一のサービス・アカウントで複数の SPN を「所有」することが可能です。このサービス・アカウントに対するパスワード変更や、このサービス・アカウントのリタイヤメントは、両方のアプリケーションに影響を及ぼします。

一方、App1 と App2 が疎結合の関係にある (すなわち、サービス品質やライフ・サイクルが互いに異なっていたり、所有する業務部門が別だったりする) 場合は、それぞれ固有の SPN を有する独自のサービス・アカウントをアプリケーション別に設定する必要があります。サービス・アカウントに対するパスワード変更や、一方のアプリケーションのリタイヤメント (当然、そのサービス・アカウントのリタイヤメントを伴います) が、もう一方のアプリケーションに影響を及ぼすことはありません (表 3 を参照してください)。

表 3. アプリケーションの結合関係による、SPN とサービス・アカウントのマッピング例
SPNサービス・アカウント
App1 と App2 が密結合の場合:
HTTP/app1.ibm.net@IBM.NET
HTTP/app2.ibm.net@IBM.NET
Svc_AppsSPN
App1 と App2 が疎結合の場合:
HTTP/app1.ibm.net@IBM.NET Svc_App1SPN
HTTP/app2.ibm.net@IBM.NET Svc_App2SPN

AD フォレスト内で SPN の定義対象となる場所

では、複雑なドメイン階層構造を持った実世界の Active Directory フォレストを有している場合はどうでしょうか。そのフォレスト内のどこに対して SPN サービス・アカウントを定義すればよいのでしょうか。

Active Directory フォレストでは、AD ドメインの階層構造が定義されます。それら複数のドメイン間には、信頼関係が存在します。AD フォレスト内の特定の場所に SPN を定義することに関して、特に要件は存在しません。SPN の定義場所を決定する基準は、技術面よりは管理面に置かれていると言えるでしょう。同じ内容の変更ならば、上位の AD ドメインや AD フォレストのルートに対して行うよりは、より下位のドメインに対して行う方が簡単かもしれません。この問題については、フォレスト全体にわたるサービス・チケット要求時のネットワーク・コストとのバランスを考慮する必要があります。以下の図 10 に示した例について考えてみましょう。

図 10. 企業の AD フォレストの例
企業の AD フォレストの例

ルートを ibm.net (Kerberos レルムは IBMNET) とする AD フォレストに、na.ibm.net および eu.ibm.net というサブドメインがあります。そのサブドメインの Kerberos レルムは、それぞれ NA と EU です。そしてこの 2 つのサブドメインが、さらに以下の国別ドメインに分割されています。

  • us.na.ibm.net (US)
  • ca.na.ibm.net (CA)
  • uk.eu.ibm.net (UK)
  • fr.eu.ibm.net (FR)
  • de.eu.ibm.net (DE)

ここで、http://someserver.ibm.net は na.ibm.net domain で稼働しているコンピューター上でホストされていると仮定してみましょう。さらに、全ユーザーのうち 75% が us.na.ibm.net domain に属していると仮定します。

サイトの DNS 名が全社レベル (すなわちフォレスト・レベル) で保持されていることを理由に、SPN を「HTTP/someserver.ibm.net@IBMNET」として定義するよう主張することは可能です。しかし、フォレストのトップ・レベルでユーザー ID を作成しようとすると、企業全体にわたる複数の承認が必要となる可能性があります (管理上の問題)。ここで理解する必要があるのは、サービス・チケットの検索経路はフォレストの階層構造に従うということです。例えば SPN がフォレストのトップ (すなわち IBMNET) で定義されている場合、米国のドメイン内のユーザーはまず最初にサービス用チケットを TGS に要求することになります。その結果、usdc.us.na.ibm.net がそのユーザー用の TGT を nadc.na.ibm.net に要求し、そこからさらに、そのユーザー用の TGT の要求が rootdc.ibm.net に対して送られます。IBMNET でホストされているサービスに対する、このクライアントによるサービス・チケット要求では、処理を完了するまでにフォレストの 2 つのレベルを横断しなければなりません。ここに示した例では、大部分のサービス・チケット要求において、このような 2 回の転送が必要となります。この例では、ルートおよび第 2 レベルのドメインに属しているクライアントはごく少数にすぎません。大部分のクライアントは、第 3 レベルのドメインに属しています。したがってこの定義方法では、WAN 上に過剰な AD トラフィックが生じる可能性があります (運用上の問題)。

管理面を考慮すれば、na.ibm.net ドメイン内に「HTTP/someserver.ibm.net@NA」として SPN を配置するほうが簡単でしょう。EU と NA の間に明示的なドメイン間信頼関係を追加すれば、ヨーロッパからのサービス・チケット要求の場合でもわずか 2 ホップで済むようになります。さらに、Active Directory 管理者が国別ドメインと NA ドメインの間にドメイン間信頼関係を個別に定義することも可能です。この方法なら、「外国」のドメインによるすべての要求がわずか1 ホップで済みます。

また、サービス・チケット要求の大部分が米国のレルムから発せられることを考えれば、米国のレルム内に「HTTP/someserver.ibm.net@US」として SPN を配置する方法を検討することも有意義かもしれません。


Web サーバーでのURLのセキュリティ設定を避ける

WebSphere Application Server の手前に Web サーバーを配置して運用する場合は、「統合 Windows 認証」が透過的に行われるように設定する必要があります。Web サーバーは、SSL ターミネーターとして機能する場合もあれば、Web ワークロード管理を行うための WebSphere プラグインの実行場所として機能する場合もあります。ただし、Web サーバーでユーザーの要求を認証することは避けるべきでしょう。SSL クライアント認証が有効であるならば、認証メカニズムとして SPNEGO の使用を検討する理由はないはずです。

IBM HTTP Server の場合、および vanilla Apache の Web サーバーの場合は、通常この件は問題になりません。これらの Web サーバーは一般に、デフォルト構成で要求の認証を実行できるようにはなっていないからです。

ただし Microsoft の IIS サーバーの場合は、デフォルト Web サイト内のフォルダーに対してデフォルトでセキュリティーが有効化されています。IIS 内では、デフォルトで統合 Windows 認証 (IWA) が有効化されます。

このシナリオでは、まず元の要求が WebSphere の SPNEGO TAI へ流れます。そして「HTTP 401 Authenticate/Negotiate」の応答がクライアントに返されます。クライアントは、SPNEGO ヘッダーを内包する Authorization ヘッダーを使用して要求を再送信します。IIS サーバーは、その Authorization ヘッダーを確認し、処理を試みます。ところがこのヘッダーは IIS サーバー名ではなく仮想ホスト名に対応するものなので、IIS サーバーは要求を拒否し、クライアントに「401」を返送します。その結果、BasicAuth ヘッダーが提示されます。こうした状況は、ここで望まれているシングル・サインオンの結果ではありません。

Web サーバーが IWA を処理するということは、Web サーバーが既に SPNEGO トークンの処理を試みて失敗し、BasicAuth チャレンジを返しているということなので、SPNEGO TAI が機能する余地は残されていません。この BasicAuth ヘッダーは、TAI から見て受け付けられるものではありません。


DNS エイリアスの使用を回避

前掲の「Active Directory における SPN の設定対象」セクションで述べたとおり、WebSphere サーバーが Active Directory 内の Windows「コンピューター」オブジェクトである場合は特に、WebSphere サーバーに対して仮想ホスト名を定義する必要があります。この仮想ホスト名をセットアップするには、以下の2 種類の方法があります。

  1. 図 11 に示すように、DNSで、第 2 のホスト名を提供するエイリアスすなわち (CNAME) レコードを追加する
    図 11. DNS エイリアスとして someserver DNS レコードを設定する方法 (誤った方法)
    DNS エイリアスとして someserver DNS レコードを設定する方法 (誤った方法)
  2. 図 12 に示すように、DNSで、元のホスト名と同一の IP アドレスにマップされる第 2 のホスト・レコードを追加する
    図 12. 第 2 の DNS ホスト・レコードとして someserver DNS レコードを設定する方法 (正しい方法)
    第 2 の DNS ホスト・レコードとして someserver DNS レコードを設定する方法 (正しい方法)

SPNEGO TAI で使用されているホスト名に対して DNS エイリアスを使用することは避けるようお勧めします。SPNEGO TAI から「401 Authenticate/Negotiate」の応答を受け取ったブラウザーは、サービス・チケットを要求します。このとき要求されるホスト名は、エイリアスの元となっているホスト名です。「someserver.ibm.net」がエイリアスである場合、上の例で生成されるサービス・チケットは「HTTP/wasserv01.ibm.net@IBM.NET」に対応するものとなります。ただし前掲の説明のように、wasserv01 が Active Directory 内の Windows コンピューター・オブジェクトである場合、エイリアスを使用すると「HOST/wasserv01.ibm.net@IBM.NET」用のサービス・チケットが生成される可能性があります。

WebSphere V6.1 の SPNEGO TAI でエイリアスを動作させることのできるケースが 1 つ存在します。しかし ISSW の SPNEGO TAI はこの機能をサポートしていません。このケースには、複雑な Kerberos/SPNEGO 構成の定義が必要となります。この構成は推奨していません。この非推奨構成を機能させるには、以下の措置が必要です。

  1. ISSW の SPNEGO TAI ではなく、WebSphere 6.1 の SPNEGO TAI を使用しなければなりません。
  2. APAR PK50383 (WebSphere Application Server V6.1 Fix Pack 15 内) を適用しなければなりません。
  3. Application Server の JVM のカスタム・プロパティーで、プロパティー「com.ibm.websphere.security.krb.canonical_host=true」を定義します。
  4. Active Directory 内で、SPN アカウントに対して、以下の 2 つの SPN を定義しなければなりません。
    1. HTTP/someserver.ibm.net@IBM.NET
    2. HTTP/wasserv01.ibm.net@IBM.NET
  5. 上記 2 つの SPN に対する鍵を組み込んだ、単一の keytab を作成します。
  6. SPNEGO TAI の構成において、次のようにホスト名のプロパティーが異なる以外はまったく同一である、2 つのプロパティー・セットを作成します。
    1. com.ibm.ws.security.spnego.SPN1.hostName=someserver.ibm.net
    2. com.ibm.ws.security.spnego.SPN2 hostName=wasserv01.ibm.net

SPN2 に関連付けられたその他のプロパティーは、SPN1 に対して定義されたプロパティーと一致していなければなりません。

実行時には、HTTP リクエスト内の「hostname」が第 1 の SPN 構成 (hostName=someserver.ibm.net に対応する構成) と照合され、リクエストをインターセプトするかどうかが決定されます。サービス・チケット到着時には、このインターセプトの決定が HTTP/wasserv01.ibm.net SPN に基づくものとなります。次に、リクエストの処理時には、受け取られたサービス・チケットが第 2 の構成プロパティー・セットと照合され、SPNEGO の SSO が実行されます。

このアプローチは推奨していません。以下に示すような稀な条件に該当する場合のみ、このアプローチを使用してください。

  • DNS エイリアスとの共存が不可欠な場合
  • エイリアスのマップ先であるホスト名が、Active Directory 内の Windows コンピューター・オブジェクトではない場合 (ただし、第 2 の DNS ホスト・レコードを追加する方法を強く推奨しています)

まとめ

この記事では、WebSphere Application ServerでSPNEGO TAIを利用する場合に、サービス・プリンシパル名を定義するうえでの数多くのベストプラクティスやヒントを説明しました。これらのベストプラクティスは、ISSW SPNEGO TAIやWebSphere Application Server v6.1 SPNEGO TAIを使用した数多くのお客様環境での経験から得られたものです。

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=WebSphere
ArticleID=360039
ArticleTitle=SPNEGO TAI : Windows から WebSphere Application Server へのシングル・サインオンの使用
publish-date=09172008