Insider's Eye Windows Server 2003 R2で強化する最新ID管理（1） Peter Pawlak 2005/11/03 Copyright (C) 2005, Redmond Communications Inc. and Mediaselect Inc.

本記事は、（株）メディアセレクトが発行する月刊誌『Directions on Microsoft日本語版』2005年11月号 p.14の「Windows Server 2003 R2で強化する最新ID管理」を、許可を得て転載したものです。同誌に関する詳しい情報は、本記事の最後に掲載しています。

　次期Windows Serverの暫定版としてリリースが予定されているWindows Server 2003 R2には、アクセス権を有する外部の顧客やパートナーとの間で、企業がWebアプリケーションやサービスを安全に共有できるよう支援する、フェデレーテッド・アイデンティティと呼ばれる新技術が含まれる。さらにR2には、Active Directory Application Mode（ADAM）とUNIX Identity Managementを使ってユーザーIDを管理するための改善も含まれる。これらの改善点は、総合的にどのユーザーがどのリソースにアクセスするかを企業が確実に管理するうえで役立つことになるだろう。ただし、Active Directory Federation Services（ADFS）と呼ばれるMicrosoftのフェデレーテッド・アイデンティティ技術の初版（当初はコード名でTrustBridgeと呼ばれていた）でのサポートは、Webベースのアプリケーションのみになり、一部のアプリケーションについては変更が必要となる場合もありそうだ。

フェデレーテッド・アイデンティティとは？

　フェデレーテッド・アイデンティティは、顧客やパートナーなど、外部組織のアクセス権を持つユーザーとの間で、企業の社内リソースを共有しやすいようにするための技術だ。例えばソフトウェア会社であれば、自社のセキュアなWebサーバでホストしている、新製品に関する技術仕様とマーケティング計画を、広報担当のPR会社がアクセスできるようにもしたいだろう。ただし、ソフトウェア会社は何らかの方法で、PR会社のユーザーを認証（IDを確認）し、信頼できるユーザーであることを確認する必要がある。理想的なのは、PR会社のユーザーがシングル・サインオン（SSO）でソフトウェア会社の情報にアクセスできるというシナリオだろう。そうすれば、まずPR会社のシステムにログオンしてから、再度、ソフトウェア会社でログオンするという手間を省ける。

マルチプル・アカウントの課題

　こうした場合に一般的なソリューションの1つが、マルチプル（複数の）ユーザー・アカウントだ。つまり、ソフトウェア会社は自社のディレクトリにPR会社の各従業員用のユーザー・アカウントを作成し、そのアカウントに文書への適切なアクセスを許可する。だが、マルチプル・アカウントの保守にはコストがかかり、セキュリティ上の新たなリスクを生むことにもなる。例えば、PR会社を解雇された従業員がその後もソフトウェア会社のアカウントを使い続け、ソフトウェア会社のファイルにアクセスすることもあるかもしれない。また、マルチプル・アカウントのソリューションでは通常、SSOは提供しない。ユーザーは一般に、アカウントごとにログオンする必要がある。こうした問題は、企業が数十あるいは数百社に及ぶパートナーを抱え、それぞれに異なるレベルのアクセス権を与えたい場合にはさらに複雑となる。

　MSNやMicrosoftのそのほかのWebサイト向けにSSOサービスを提供するMicrosoft Passportのように、中央集中型のIDブローカーは、マルチプル・アカウントの代替選択肢となり得る。企業はすべてのユーザー・アカウントを単一の信頼できる組織に保管し、その組織に社内と社外、すべてのユーザーの認証を委ねられる。ここで問題となるのは、信頼された単一の組織がハッカーの集中的なターゲットとなり、Single Point of Failure（システム全体の障害を引き起こす、単一の障害ポイント）となってしまう点だ。また、個人や企業の中には、単一のブローカーに自分のID情報を預けることに対して、プライバシーに関する懸念を示す向きもある。

アカウント保守の一元管理

　これに対してフェデレーテッド・アイデンティティ・システムでは、各組織がそれぞれのユーザーを認証し、そのユーザー・アカウントを保守する。ユーザーがパートナー組織のリソースにアクセスしたいときには、そのユーザーの所属組織がユーザーのアイデンティティの証明書を含むセキュリティ・トークンをパートナーに転送し、パートナーはユーザーの所属組織の信頼度に応じて、アクセスを許可する。従って、前述の例でいえば、PR会社の従業員がソフトウェア会社のファイルにアクセスしようとするときには、PR会社がその従業員を認証し、その従業員の認証データをセキュリティ・トークンとしてソフトウェア会社に転送することになる。

　フェデレーテッド・アイデンティティ・システムは、アカウントを複製したり、中央で一元管理したりするシステムよりも安全で保守がしやすい。なぜなら、ユーザーのアカウント情報と関連する機密情報（パスワードなど）は、ユーザーの雇用主かISP、あるいはユーザーが信頼するそのほかの組織のいずれか1カ所でのみ保守されることになるからだ。また、フェデレーテッド・アイデンティティはSSOをサポートできるため、ユーザーはいったん自分の所属組織で認証を行えば、その組織がパートナーに対してユーザーを認証してくれるため、ユーザー側ではそれ以上何もする必要がない。

Active Directory Federation Servicesの仕組み

　Active Directory Federation Services（ADFS）はWindows Server 2003 R2の新しいコンポーネントで、これにより、企業は当初、顧客とパートナーにWebアプリケーション用のフェデレーテッド・アイデンティティを提供できることになる。ADFSはActive Directory（以下ADと略記）のほか、認証と権限授与に必要となるIDデータ用のWindows Serverストア、ユーザーを認証するためのKerberos標準など、Windows Serverの既存のID管理／権限付与サービスをベースとしている。

■ADFSの運用シナリオ
　ADFSの鍵となるのは、「リソース・パートナー」と「アカウント・パートナー」、およびそれらの間を結び付けるフェデレートによる信頼関係だ。

　リソース・パートナーとは、リソースをホストする組織のことで、Windows Server 2003 R2の場合、そうしたリソースはInternet Information Services（IIS）Webアプリケーションとなる。アカウント・パートナーとは、リソース・パートナーのWebサイトにアクセスする必要のあるユーザーのID情報（ユーザー・アカウント）を保守、管理する組織のことだ。

　前述の例では、ソフトウェア会社はPR会社に対し、セキュアな自社のWebサーバ上でホストしている技術仕様やマーケティング計画をアクセスできるような環境を構築したかった。この場合、ソフトウェア会社がリソース・パートナーであり、文書がリソースであり、PR会社がアカウント・パートナーだ。リソース・パートナー（ソフトウェア会社）は、ユーザーの認証をアカウント・パートナー（PR会社）に委ねている。つまり、ソフトウェア会社はPR会社が発行したセキュリティ・トークンを受け入れることに合意している。その結果、アカウント・パートナーのユーザーはリソース・パートナーが所有するリソースにアクセスできるが、リソース・パートナーの側ではそうしたユーザー向けに自社のディレクトリでユーザー・アカウントを管理したり、複製したりする必要はない。

　ADFSサーバは、リソース・パートナーとアカウント・パートナーの間にフェデレートによる信頼関係を構築し、双方間でセキュリティ・トークンを転送する。ADFSでは、セキュリティ・トークンにはユーザーに関する1つまたは複数の申告（claim）が含まれ、そうした申告には、そのユーザーのアカウントを所有するアカウント・パートナーにより、デジタル署名が施されている。申告には通常、ユーザー名、電子メール・アドレス、グループ所属のほか、ユーザーにどの程度のアクセス権を認めるかをリソース・パートナーが判断する際に役立つデータが含まれる（コラム「ADFSのフェデレーテッド・アイデンティティのシナリオ」を参照）。

　アカウント・パートナーのADFSは、ユーザーのADアカウントを使ってセキュリティ・トークンを構築する。リソース・パートナーのADFSは、アカウント・パートナーから送られてきたセキュリティ・トークンが有効かどうか（アカウント・パートナーによるデジタル署名が施され、その後、変更が加えられていないかどうか）を検証する。リソース・パートナーのADFSはさらに、セキュリティ・トークンから申告を取り出し、そのユーザーの認証の判断を下す必要があるアプリケーションに転送する。

ADFSのフェデレーテッド・アイデンティティのシナリオ ADFSのフェデレーテッド・アイデンティティのシナリオ 　Windows Server 2003 R2では、ユーザーはActive Directory Federation Services（ADFS）を、パートナーのWebアプリケーションへのシングル・サインオン（SSO）に使えるようになる。以下に、典型的なシナリオを示す。 アカウント・パートナーのユーザーは自分のブラウザを使って、リソース・パートナーがホストするWebアプリケーションまでナビゲートする。 リソース・パートナーのWebサーバにはInternet Information Services（IIS）6.0が必要で、その上に置かれたADFS Webサービス・エージェントがアクセス権を認めるためにセキュリティ・トークンを探す。ユーザーがセキュリティ・トークンを持っていない場合には、リソース・パートナーのADFSサーバにリクエストを送信する。 リソース・パートナーのADFSサーバはフェデレートによるアカウント・パートナーのリストを調べ、セキュリティ・トークンを入手するためにはユーザーをどこへ送信すべきかを判断する。リソース・パートナーのWebアプリケーションにアクセスするための最初の試みは、ホーム領域の発見と呼ばれる。ここで、リソース・パートナーのADFSサーバはユーザーに対し、自分のメール・アドレスなど、何か身元を証明するデータの提供を求める。その後のアクセスでは、リソース・パートナーのADFSサーバは、Cookieにより、そのユーザーがどのアカウント・パートナーに所属しているかを把握する。 リソース・パートナーのADFSサーバは、アカウント・パートナー（ユーザーの所属会社の認証システム）にリクエストを送信する。 アカウント・パートナーのADFSサーバは、Active Directory（AD）またはActive Directory Application Mode（ADAM）ディレクトリ・サービスでそのユーザーの情報を調べ、リソース・パートナーのWebアプリケーションで必要となるセキュリティ・トークンを構築する。 これで、ユーザーは必要なトークンを入手したことになり、ユーザーはWebアプリケーションに戻され、そこで再びADFS Webサービス・エージェントがトークンを確認する。 エージェントと、リソース・パートナーのADFSサーバは、ユーザーのトークンが信頼できるアカウント・パートナーからのものであることを確認する。署名が有効である（不正に変更されていない）と判断された場合には、トークンに含まれる申告が引き出され、アプリケーションに渡される。アプリケーションはその申告と権限付与ロジック（承認マネージャによって提供されるか、あるいはWebアプリケーション開発者がコード化する）を使って、そのユーザーがそのWebアプリケーションで実行できる操作を制御する。

　

INDEX
	Insider's Eye
	Windows Server 2003 R2で強化する最新ID管理（1）
	Windows Server 2003 R2で強化する最新ID管理（2）

　

「Insider's Eye」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）