 |
|
|||||||||||||||||||||||||||||||||||||||||||
複数ディレクトリー環境でのシングル・サインオン:「Never say login again」パート 1複数ディレクトリー、複数 ID 環境での SSO を理解する |
||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||
Amy Smith, Principal Information Developer, IBM Terri Warren, Advisory Software Engineer, IBM Jane Marcus, Senior Software Engineer, IBM レベル：中級 原文の掲載：2005年9月7日 更 新 日：2006年1月20日更新  原文はこちら
自社の作業環境が扱いにくいと思った場合は、政府最高機密機関 (TSGA と表記) の諜報員である Jim Bland のことを考えてみましょう。他の国際スパイと同様、Jim は情報こそが最高の価値を持つ、スリリングで要求が厳しい世界で働いています。しかし、よく知られた彼の同僚とは異なり、Jim (バッジナンバー 013) は、過酷で予算不足の IT 部署がある古い環境で働いています。そして、私たちと同様に、Bland は厳しい環境で多くの仕事をしなければなりません。 Jim Bland はスパイ活動をしますが、その範囲は国内のみです。現在、Bland は、未払いの駐車違反料金を抹消する謎の事件で利益を上げている業界の大物への調査に取り組んでいます。Bland の最新の任務を示す最高機密ファイルは、保護された保管領域 (今回は、ショッピングモールの公衆トイレ) に隠されていて、Bland はこのファイルにアクセスするために、彼自身の身分を証明しなければなりません。Bland は後ろの壁に歩み寄り、最も新しくて輝いている壁のタイルに手をかざします。これは、指紋を読み取るスキャナーです。もちろん Bland は認識され、「識別完了」を告げる音声が聞こえます。壁の中に秘密のドアが現れます。このドアは、機密ファイルがある場所へ通じているエレベータのドアです。Bland はエレベータの中に入ります。しかし、Bland は、2 番目の関門である網膜スキャンを通過するまではエレベータのボタンを押せません。ここで、「識別完了」という声が再び聞こえます。少し移動した後、エレベータのドアが開きます。しかし、またもや問題が待ちかまえています。足を踏み出すフロアがないのです。フロアの代わりに、何も見えない空間が広がっています。Bland はどうすればよいのでしょうか。ジャンプするか、隣の水道管にしがみついて降りていくのでしょうか。しかし、機知に富んだ Bland は何をすべきかを知っていました。彼は再び自分自身を証明するために、「Bland、Jim Bland です」と合言葉を言いました。突然、安全な通路が現れます。Bland の識別を確認する「エージェント 013 へのアクセスが許可されました」という音声にともない、Bland はエレベータから出ます。これで、Bland は任務を遂行できます。悪魔から地球を救うというものではなく、駐車料金詐欺グループとの対決です。しかし、この認証手順はあまりにも面倒です。Bland は「なぜ、シングル・サインオンがまた壊れたのだろう」と思ったに違いありません。 シングル・サインオン (SSO ともいいます) は、管理は複雑ですが、ユーザーにとってはたいへん便利です。SSO がない環境では、ユーザーはログイン情報を繰り返し要求されて面倒です (この例では、公衆トイレから出ようとした場合などです)。この記事では、SSO 環境のデプロイまたはメンテナンスに関わる人々に対し、ユーザーが安心して使用できるようにするために、複雑な環境を設定する際のヒントとテクニックを説明します。音声認識によって現れる隠し通路を環境に組み込むことも不可能ではありません。しかし、ほとんどの企業では標準的な Web SSO 環境を構築します。最も一般的なシナリオでは、WebSphere Portal や Domino などの IBM コンポーネントが含まれる環境にアクセスする際に、ユーザーはユーザー名とパスワードの入力を求められます。この環境には、Sametime、QuickPlace、Domino Web Access (DWA) 経由での Domino メールへの接続を提供する Lotus ポートレットが含まれることがあります。 この連続記事では、主に Portal 環境を取り上げます。Portal 環境では複数のディレクトリーが配置されるため、より複雑さが増加します。DWA などのコンポーネントには Domino ディレクトリが必要です。一方、Portal などの他のコンポーネントには、IBM Directory Server、Active Directory、または他のサポートされている LDAP ディレクトリーが必要です。この記事では、複数のディレクトリーが導入されている環境で SSO がどのように機能するのかを説明し、ユーザーが複数の名前で識別されるときの対策を示します。 諜報員がしばしば複数の名前を持つスパイの世界と同様に、SSO ではユーザーが複数の名前で識別されることが一般的です。SSO 環境ではユーザー名がたいへん重要です。ユーザー名が、なぜ、どのように重要なのかを理解するために、第 1 部の記事では SSO の基礎を再確認することから始め、SSO 環境でのユーザーの識別方法を明らかにします。次に、複数ディレクトリー、複数 ID 環境を運用する際の課題について考慮します。
SSO の基礎通常、SSO といえば、Web ユーザーのエクスペリエンスのことを示します (使用されているオペレーティング・システムのデスクトップ・ログインについて興味がある場合は、この資料を参照してください)。ユーザーは Web ブラウザーを使用して URL にアクセスします。たとえば、Jim Bland はお気に入りの spycentral (http://spycentral.spies.com/fun) にアクセスします。適切に設定された SSO デプロイメントでは、Bland は各セッションごとに一度だけログインを求められます。Bland は、最初に spycentral でこの URL にアクセスしたときに、ユーザー名「jb013」とパスワード「LazyEye」を入力する必要があります。spycentral の Web アプリケーション・サーバーは Bland が入力したパスワードの検証に成功し、この URL へのアクセスを許可します。Bland は一度だけログインすればよいのです。彼は SSO 環境へのアクセスが認められているので、再びログインすることなく、この環境内の他の URL をブラウズできます (図 1 参照)。 図 1. SSO ログイン 図 1 について説明します。 A. Bland はお気に入りの URL をブラウズしようとして、ログインを求められます。Web アプリケーション・サーバーは Bland のパスワードを検証し、URL へのアクセスを許可します。Bland は SSO 環境で認識されました。 B. Bland は SSO 環境内の他の URL をブラウズしますが、ログイン手順を繰り返す必要はありません。 SSO を実現するには、ユーザーのログイン後、SSO サーバーとアプリケーションがユーザーを認識することが非常に重要です。IBM 製品がデプロイされている Web 環境では、SSO を実現するために、Lightweight Third Party Authentication (LTPA) と呼ばれる手法が使用されています。この LTPA テクノロジーにより、SSO サーバーはログイン後のユーザーを識別できます。IBM はオープン・スタンダードを支持していますが、SSO として幅広く導入されたデファクト・スタンダードが存在しないため、IBM は独自の SSO テクノロジーを開発しました。LTPA はさまざまな IBM 製品で使用できます。また、IBM はオープン・アーキテクチャーを表明しているため、WebSphere と Domino のどちらにもプラグイン・ポイントが装備されています。これを利用してサードパーティ製の SSO アプリケーションを組み込み、LTPA ソリューションを得ることができます。LTPA テクノロジーを理解し、最初に述べた「SSO 環境ではユーザー名が重要」という意味を明らかにするには、ブラウザーとブラウザー Cookie について考える必要があります。 SSO セキュリティーでブラウザーがサポートする役割 Jim Bland がブラウザーを使用して WebSphere URL を入力するケースを考えます。Bland はユーザー名とパスワードによるログインを求められます。WebSphere アプリケーション・サーバーは、入力されたパスワードをチェックすることによって、Bland の ID を検証します。次に、Web サーバーは、Bland の Web ブラウザーに表示すべき Web サイトのコンテンツを送り返します。Web ユーザー・エクスペリエンスは通常と変わりありません。正しいパスワードを入力すると、Web サイトの表示が開始されます。この場合、WebSphere は Bland のブラウザーによって保存される Cookie をバックグラウンドで送信しています (図 2 参照)。Cookie がブラウザーによって保存されるには、ブラウザーで Cookie を受け入れるよう設定されている必要があります。一般的なブラウザーでは、デフォルトでこのように設定されています。LTPA Cookie は一時的な Cookie で、ブラウザーのメモリー内だけで有効です。つまり、ユーザーがブラウザーを終了すると、この Cookie は永久に失われます。 図 2. ログインによって LTPA ブラウザー Cookie が返される  LTPA ブラウザー Cookie は一般的なブラウザー Cookie です。ブラウザー Cookie に慣れていない読者は、Cookie とは後で利用するためにユーザーのコンピューターに情報を保存する標準的な方法と理解すればよいでしょう。LTPA ブラウザー Cookie に保存された情報は、Bland が既にログインしていることを示します。すべてのブラウザー Cookie は、いくつかの標準属性 (たとえば、名前など) を持ちます。LTPA Cookie の名前は LtpaToken です (SSO を設定するとき、設定ユーティリティーでは LTPA Cookie を SSO LTPA「トークン」と呼びます。この記事では、SSO Cookie という表記は、SSO トークンと同じものを表します)。すべてのブラウザー Cookie と同様に、Cookie 名に加え、LTPA Cookie は値を持っています。LTPA Cookie の場合、一見しただけでは Cookie の値はよくわかりません。この値はエンコードされているからです。LTPA Cookie の値をエンコードすることにより、機密を保持したまま Cookie に含まれる重要な情報をインターネット上で送信できます。 一般的なブラウザー Cookie と同様に、LTPA ブラウザー Cookie は関連するドメイン情報を持っています。Bland が spycentral にログインすると、spycentral のサーバーは LTPA Cookie を作成します。spycentral のサーバーは spies.com DNS ドメインに置かれているので、Cookie のドメイン情報は spies.com に設定されます。ドメイン情報は、この Cookie が spies.com の DNS ドメイン内だけで有効であることを示します。LTPA 実装はこのドメイン情報を持っているブラウザー Cookie を信頼するので、一般的に、SSO 環境は 1 つの DNS ドメイン内だけにデプロイすることが必要です。このサンプルのデプロイメントでは、サーバー・マシンは spycentral.spies.com、spymeetings.spies.com、spyVsSpy.spies.com です。どのマシンも spies.com DNS ドメイン内にあります。SSO を 1 つの DNS ドメイン内に実装しなければならないという制限は、ドメイン情報を持つブラウザー Cookie が LTPA 実装の中心である事情に直接関係しています (しかし、この DNS の問題には対策があります。この資料を参照してください)。 LTPA ブラウザー Cookie のさまざまな側面について簡単に説明してきました。ここで、この Cookie が SSO ソリューションで果たす主な役割の基本に戻ることにしましょう。Bland がログインし、Bland のブラウザーによって LTPA Cookie が受け取られると、ブラウザーは自動的にこの Cookie を HTTP トラフィックに含めて送信するようになります。特殊な設定は必要ありません。これは、ブラウザーの標準的な動作だからです。ブラウザーは、正しい DNS ドメイン内の任意の URL 転送先に HTTP 要求を送信するたびに、常にこの Cookie を含めて送出します。たとえば、Bland が spycentral.spies.com の URL を入力すると、ブラウザーは spies.com ドメインに適用する Cookie を持っていることを認識し、自動的にこの LTPA Cookie をともなって送信します。Bland が spymeetings.spies.com の URL にアクセスするときも同様です。ブラウザーは、該当する HTTP 要求ごとに Cookie を送信します。SSO サーバーが HTTP 要求を受け取り、LTPA Cookie が含まれていることを確認すると、何が起こるのでしょうか。サーバーは Cookie を検証し、この Cookie がログイン済みユーザーの Bland に属することを認識します。サーバーは、このサーバーでの適切なアクセス権を Jim Bland に許可します。 まとめると、HTTP トラフィックで LTPA Cookie を送出するかどうかを判断するのは、ブラウザー側の作業となります (図 3 参照)。 Jim Bland が DNS ドメイン外の URL をブラウズすることを考えます。たとえば、cia.gov 内の URL をブラウズします (もっと魅力的な仕事を探すためかもしれません)。この場合、ブラウザーは LTPA Cookie を送信しません。この Cookie は spies.com にのみ適用され、cia.gov には適用されないからです。ブラウザーが cia.gov 内のサーバーに Cookie を送信しないので、受信したサーバーはユーザーが誰であるかがわかりません。サーバーはアクセスを許可する前に、Bland に対してユーザー名とパスワードの入力を求めるでしょう。 図 3. ブラウザーは spies.com 内のサーバーにのみ LTPA Cookie を送信する  図 3 について説明します。 A. Bland はすでにログインしています。ブラウザーは、spycentral.spies.com 内の URL へのアクセスを許可する LTPA Cookie を自動的に送信します。 B. Bland は spies.com DNS ドメイン内の他のサーバー上の URL をブラウズします。ブラウザーが LTPA Cookie を送信しているので、アクセスを認められます。 C. www.cia.gov は一致する DNS ドメインでないため、ブラウザーは www.cia.gov へは LTPA Cookie を送信しません。このため、cia.gov のサーバーは、アクセスを許可する前に、ユーザー名とパスワードを入力してログインするよう Bland に要求します。 犯罪者の手から鍵を守る ユーザーにとって SSO はたいへん便利ですが、もしこれがセキュアでないと、何の価値もありません。セキュリティーは最優先事項です。特に、TGSA の宿敵 BEDLAM (Bureau of Egregiously Dangerous Lawless Assassins and Murderers) のメンバーが逃亡中の場合はなおさらです。LTPA Cookie は信頼のおける暗号技術を使用して作成されているので、セキュアです。LTPA Cookie を作成するサーバーは、暗号鍵のセットを使用します。暗号鍵は Cookie のエンコードに使用されます。エンコードされた Cookie がユーザーのブラウザーに送信されるまでに、この暗号鍵を持たないユーザーによって Cookie がデコードされることはありません。暗号鍵は Cookie の検証にも使用されるので、Cookie の完全性を検証し、改ざんを容易に検出できます。SSO 環境のすべてのサーバーは、同じ暗号鍵を共有する必要があります。SSO サーバーが HTTP 要求を受け取り、LTPA Cookie が含まれていることを確認すると、共有している暗号鍵のコピーを使用してこの Cookie を検証します。そして、有効な Cookie に含まれる情報によって、サーバーがログイン・ユーザー (たとえば、Jim Bland) を認識します。 SSO サーバーで使用されているセキュアな暗号技術によって、Cookie が偽造される可能性はありません。仮に、Bland の敵である Dr. Notnow (BEDLAM のリーダー) が、SSO サーバーへのハッキングを狙って SSO Cookie の作成を試みるケースを考えます。Dr. Notnow の目的は、オンライン・データベースにある駐車違反の記録を抹消することです。しかし、Dr. Notnow は暗号鍵を持たないので、SSO サーバーへのハッキングは失敗します。Dr. Notnow から送信された偽の Cookie は検証できないため、無視されます。 WebSphere Portal 環境では、通常、LTPA 暗号鍵は SSO の設定中に WebSphere によって作成されます。システム管理者はこの鍵をファイルにエクスポートし、他の SSO サーバー (たとえば、Domino) に配布します。この方法で、これらのサーバーに鍵をインポートできます。明らかに、この鍵ファイルは特別に注意して扱う必要があります。ファイルのコピーは安全な場所に厳重に保管してください (網膜スキャンがあれば完璧です!)。 自分自身を証明する これで、SSO のセキュリティーが組み込まれていることがわかりました (セキュアな SSO 環境を正しくデプロイする方法の詳細については、この資料を参照してください)。エンコードされたこの Cookie に何が含まれるのかを見ていきましょう。Jim Bland がログインするときのことを、より詳しく説明します。まず、彼はユーザー名「jb013」とパスワードを入力します。すると、ログイン・サーバーはディレクトリーでユーザー jb013 を検索します。ディレクトリーでは、ユーザーのエントリーは「uid=jb013,ou=secret,dc=spies,dc=com」という識別名で検出されるものとします。ユーザーのパスワード情報が検証されると、サーバーはこの識別名を使用してユーザーを認識します。この識別名は生成された LTPA Cookie に書き込まれ、ブラウザーに送信されます。ブラウザーは HTTP トラフィックで Cookie を送信します。次に何が起こるのでしょうか。Bland が SSO 環境内の URL をブラウズすると、SSO サーバーは Cookie を受け取り、暗号鍵を使用してこれをデコードし、検証します。SSO サーバーは、ユーザー名「uid=jb013,ou=secret,dc=spies,dc=com」が Cookie 内にあることを確認します。SSO サーバーは、LTPA Cookie 内に存在するこのユーザー名に基づいてユーザーを識別します。 図 4. エンコードされた Cookie の内部  図 4 について説明します。 A. Bland はログインを求められるので、ユーザー名「jb013」とパスワードを入力します。 B. サーバーはディレクトリーでユーザー「jb013」を検索し、一致するユーザー・レコードを見つけます。このレコードに対して、Bland のパスワードを検証します。 C. Bland がログインしました。サーバーは、Bland の識別名を含む LTPA Cookie をブラウザーに送り返します。 環境内にディレクトリーが 1 つだけあり、すべての SSO コンポーネントがこのディレクトリーを使用している場合は、LTPA Cookie 内の名前によってユーザーを明確に識別できます。しかし、一人のユーザー (たとえば、Bland) に対し、複数のディレクトリーで複数の名前形式が使用されている複雑な環境では、問題が発生する可能性があります。たとえば、Microsoft の Active Directory と IBM Lotus Domino ディレクトリという 2 つのディレクトリーが使用されているものとします。この場合、Active Directory での Bland の識別名が Domino で定義された識別名と異なると問題が生じます。LTPA Cookie には、ログイン・ユーザーを識別するユーザー名が 1 つしか含まれないので、ユーザーが複数の名前を持つこと自体が問題になります。LTPA Cookie に含まれるユーザー名だけが、受信したサーバーがユーザーに関する情報として入手できる唯一の情報である可能性もあります。受信したサーバーが LTPA Cookie 内の名前を認識できないことは、SSO の機能が停止することを意味します。
複数ディレクトリー、複数 ID の問題を理解するTGSA の IT 管理者たちは、世の中の駐車違反者に取り組む Jim Bland の任務をうらやましく思っています。もし、IT ジョブが同じように「ミッションポッシブル」であればなぁ、というように。IT 管理者にとって、解決しなければならないことは山のようにあります。企業の IT インフラストラクチャーが総合的な計画に沿って構築されることはほとんどなく、まったく無秩序な状態になっていることもよくあります。多くの企業では、すべての企業ユーザーを 1 つのディレクトリーにまとめるという最終的な目標を持っていますが、実状では、少なくとも 2 つの (時には、それ以上の) ディレクトリーが企業内に存在していることが一般的です。システム管理者は、複雑なパスワード検証の課題、複数の ID、実行可能なソリューションの要望といった難題を抱えています。しかし、なぜ複数のディレクトリーが使用されているのでしょうか。お気づきのように、分散アプリケーションが分散ディレクトリーの必要性を高めています。組織全体にわたる複数のアプリケーション環境によって、さまざまなユーザー・リポジトリーの生成が脈絡なく何度も繰り返されてきました。たとえば、ある企業では、LDAP ディレクトリーにユーザーとグループを持つ既存の WebSphere Portal Application 環境がある上に、Domino ディレクトリを使用する IBM Sametime 環境も存在します。Domino アプリケーションのアクセス制御リスト (ACL) と実行制御リスト (ECL) は、複雑で変更が困難な場合もあります。その時点で使用されている特定のディレクトリーに基づいてアクセス制御リストを再編成または複製することは、困難で時間がかかり、コストに合わないソリューションでしょう。また、常に変化する社会では、企業の合併や買収 (あるいは政変) が発生することもあります。このような場合、システム管理者は、新しいディレクトリーを既存のインフラストラクチャーに組み込むことを何度も繰り返すことになります。 Jim Bland のような優秀な諜報員は、常に脱出の計画を持っています。これは、TSGA の IT 部門も同様です。これから取り上げる例では、Bland の上司の VM と IT 管理者が IBM 製品を利用して複数ディレクトリー、複数 ID 環境をどのように統合したのかを説明します。TSGA のインフラストラクチャーには 2 つのディレクトリーが必要です。TSGA での WebSphere Portal Server (WPS) と WebSphere Application Server (WAS) の実装は、LDAP IBM Directory Server (ITDS) を使用するよう設定されています。一方、Domino Web Access ポートレット、Sametime、QuickPlace などのアプリケーションによってもたらされる多機能のコラボレーティブ環境には、Domino ディレクトリを使用する必要があります。TSGA の諜報員は、両方のディレクトリーに存在します。 VM の計画は、Domino、Portal アプリケーション、および IBM Workplace Collaboration Services を含むすべての IBM コラボレーティブ製品群を大きな変更なしに活用することなので、複数 ID、複数ディレクトリーのシナリオを理解することが TSGA にとっての課題となります。VM は、IBM 製品群、ソリューション、テクノロジーをデプロイしたときに、SSO が機能することを要求しています。これにより、Agent 013 とその同僚たちにとって、スパイと駐車料金詐欺師の危険な世界での働き方がシームレスに変更されます。 ユーザー名には何が含まれるか 前述のように、SSO 環境ではユーザー名が非常に重要です。Jim Bland は実際には 1 つの名前しか持ちませんが、スパイの世界や TSGA の IT インフラストラクチャーでは、多くの ID が使用されています。TSGA 本部には、それぞれ異なるディレクトリー・インフラストラクチャーを持つ複数のアプリケーションがデプロイされています。このため、Bland は複数の ID を持っています。各 ID は、それを発行したディレクトリーのスキーマに基づいてフォーマットされています。たとえば、Bland の IBM Tivoli Directory Server (ITDS) での識別名 (DN) と Domino での識別名は、階層および構文の両面で次のように異なります。
Portal ログイン ID と Portal アプリケーション ID SSO サーバーとアプリケーションは一度ログインしたユーザーを認識することがポイントであることを思い出してください。Bland がブラウザーを使用し、WebSphere URL を入力すると、ユーザー名とパスワードによるログインを求められます。常に時間のない Bland は、自分自身の固有の識別子「jb013」を入力します。WebSphere アプリケーション・サーバーは、ITDS サーバーで Bland の名前を検索し、入力されたパスワードを検証することによって Bland の ID を検証します。名前が検証されると、Bland はブラウザーを使用して WebSphere Portal Server のコンテンツにアクセスできるようになります。 図 5. Portal ログイン ID  現在、LTPA Cookie には、Bland の LDAP ID「uid=jb013,ou=secret,dc=spies,dc=com」が含まれます。これが、Bland の Portal ログイン ID です。 Jim はメールをチェックすることにして (彼は CIA の人材募集部門からの回答を待っています)、Domino Web Access ポートレットに切り替えます (図 5 参照)。LTPA トークンは HTTP を介して Domino Web Access サーバーに送信されます。このサーバーは、Jim の ID を検証 (認証) するために Domino ディレクトリを検索します。そして、この ID に基づいて、Domino Web Access リソースへのアクセスを許可するかどうかを判断します (認可)。しかし、LTPA トークンには Portal アプリケーション ID が含まれています。Bland はアクセスを許可されるのでしょうか。 Bland は実際にアクセスが認められます。Bland のポータル ID「jb013」は、Domino Web Acces ポートレット内で彼の Domino ID「Jim Bland」にマッピングされます。しかし、TSGA の統合アプリケーション環境は、どのような方法で名前のマッピングを処理したのでしょうか。
第 1 部終了...これで、SSO の基礎と、複数ディレクトリー、複数 ID 環境を運営する際に遭遇する可能性のある課題についての説明を終わります。連続記事の第 2 部では、私たちのヒーロー Jim Bland とその同僚を引き続き例にとり、いくつかの SSO シナリオと、Notes/Domino 7 の SSO の新機能について解説します。
リソース
|
||||||||||||||||||||||||||||||||||||||||||||
