Insider's Eye シングル・サインオンでシンプルなリソース共有を実現するTrustBridge ――　TrustBridgeを利用すれば、社内のリソースを信頼できるパートナーに簡単に公開できるようになる。Microsoftは先行発表で業界標準の確立を狙う　――
Matt Rosoff 2002/09/06 Copyright(C) 2002, Redmond Communications Inc. and Mediaselect Inc.

---

本記事は、（株）メディアセレクトが発行する月刊誌「Directions on Microsoft日本語版」 2002年8月15日号 p.17の同名の記事を許可を得て転載したものです。同誌に関する詳しい情報は、本記事の最後に掲載しています。

　Microsoftが発表したソフトウェア認証ゲートウェイ「TrustBridge」により、企業は他社システムからアクセスしてきたユーザーの身元を確認できるようになり、信用できるパートナーへの社内リソースの公開が容易になる。Microsoftの認証サービス「Passport」も改良され、TrustBridgeベースのシステムと認証情報の交換が可能になる予定だ。

　最初の製品は2003年まで登場しないが、Microsoftはいまのうちにインターネット・ベースの認証の標準策定に影響力を行使し、Active Directory（AD）とWindows .NET Serverへ顧客の移行を促進したい考えである。

社内リソースの共有化

　TrustBridgeの目的は、組織内のリソースをパートナーのユーザーやアプリケーションと、より簡単に共有できるようにすることだ。例えばソフト会社は、次期製品の技術仕様とマーケティング計画をPR会社が読めるようにしたいだろう。理想的なのは、PR会社のユーザーがシングル・サインオンでソフト会社の情報にアクセスできるようにして、最初にPR会社にログオンすれば、ソフト会社に再度ログオンする必要をなくすことだ。

　しかし、ソフト会社は何らかの方法でPR会社のユーザーを認証（身元を確認）し、彼らが信頼できることを確認する必要がある。一般的な解決策の1つは、マルチプル・ユーザー・アカウントだ。つまり、ソフト会社がPR会社の従業員用にユーザー・アカウントを設け、そのアカウントにドキュメントへのアクセスを許可すればよい。

　ただし、マルチプル・アカウントの管理は費用がかかり、セキュリティ上のリスクも発生する。例えば、PR会社を解雇された従業員がソフト会社のアカウントを悪用して、同社のファイルにアクセスすることもあり得るからだ。

　マルチプル・アカウント方式では通常、シングル・サインオンは提供しない。ユーザーは一般に、アカウントごとにログオンする必要がある。この場合、企業が数十ないし数百のパートナーを抱え、それぞれに異なるレベルのアクセス権を与えたいとなると、問題は複雑化する。

　MicrosoftのWebユーザー用シングル・サインオン・システムのPassportは、マルチプル・アカウントに対する代案だ。企業はユーザー・アカウントをPassportのような単一の信頼できる組織にストアすれば、そこにすべてのユーザーの認証を委ねることができる。ここで問題となるのは、この信頼された組織がハッカーの大きな目標となり、唯一の障害発生地点となることだ。

　TrustBridgeにより、企業は第3のソリューション「フェデレーテッド・アイデンティティ（federated identity）」を利用することが可能になる。フェデレーテッド・アイデンティティ・システムでは、各組織がそれぞれのユーザーを認証し、それぞれのユーザー・アカウントを保持する。

　ユーザーがパートナーのリソースにアクセスしたいときは、ユーザーの所属組織がユーザーのアイデンティティ（認証データ）の証明書をパートナーに転送する。パートナーはユーザーの所属組織の信頼度に応じてアクセスを許可する。

　従って、上記の例のPR会社は各従業員を認証し、従業員がソフト会社のファイルにアクセスしようとするときは、従業員の認証データをソフトウェア会社に転送する。この方法で相互に信頼し合う組織の一団は「フェデレーション」と呼ばれる（Directions on Microsoft日本語版2001年12月15日号の「連盟（federation）のコンセプト」参照）。

　フェデレーテッド・アイデンティティ・システムは、アカウントの複製や集中化を行うシステムよりも安全で保守しやすい。なぜなら、ユーザーのアカウント情報と関連する機密情報（パスワードなど）は、ユーザーの雇用主か、インターネット・サービス・プロバイダ（ISP）、ないしユーザーが信頼するほかの所属組織、それら以外には流出しないからだ。

　さらに、フェデレーテッド・アイデンティティはシングル・サインオンを提供できる。ユーザーは所属組織で認証を行うと、所属組織がパートナーに対してユーザーを認証するため、ユーザー側はそれ以上何もする必要がない。

Webサービスベースのアイデンティティ

　企業にインストールされたTrustBridgeは、フェデレーテッド・アイデンティティのゲートウェイとして機能する。パートナーと認証データを交換し、共通のインターチェンジ・プロトコルを介して、企業とパートナーの認証システム間で変換を行う。

　インターチェンジ・プロトコルにより、フェデレーションに参加している組織は各種の認証システム、例えばKerberos（Windowsで広く使われている）やRemote Authentication Dial-In User Service（RADIUS、Windows Routing and Remote Accessサービスや多くのISPが採用）、公開キーインフラ（PKI）ベースのシステムなどを内部で用いることが可能だ。

　TrustBridgeが採用しているインターチェンジ・プロトコルは、Webサービス技術を利用する。同プロトコルは、Webサービスのデファクト・スタンダードであるSimple Object Access Protocol（SOAP）を用いて認証データを送受信する。また、WS-SecurityというSOAPエクステンションを用いて認証データを暗号化し、転送中に保護する。

　Microsoft、IBM、VeriSignが共同開発したWS-Securityは、認証データの搬送、SOAPメッセージの暗号化とデジタル署名の標準的な方法を定義する。WS-Securityにより、SOAPメッセージは認証データ以外のさまざまなセキュリティ情報を搬送可能になる（WS-Securityのエクステンションは、「コラム：Webサービスセキュリティ仕様案」を参照）。

　SOAPとWS-Securityをベースとするインターチェンジ・プロトコルは、インターネット経由で複数のコンピューティング・プラットフォームを相互接続するフェデレーションに、いくつかの利点をもたらす。まず、SOAPメッセージを標準のインターネット・プロトコル（例えばHTTP）で送信できるので、ファイアウォールを再設定しなくても認証データを交換できる。

　また、SOAPとWS-SecurityはすでにMicrosoft以外の多数のベンダによる支持を得ているため、Windows以外のプラットフォームでも利用可能なクロス・プラットフォーム対応になる可能性が高い。さらに、WS-Securityは複数の認証システムの認証データをサポートするように設計されており、システム間のブリッジの役割を果たすことができる。

　インターチェンジ・プロトコルをSOAPとWS-Securityベースにすることで、Kerberos v5認証システムのいくつかの問題も回避することが可能だ。

　Kerberos v5はフェデレーテッド・アイデンティティ（Kerberosでは“cross-realm”ないし“cross-domain”と呼ばれる）をサポートする認証システムの中で最も普及している。KerberosはSOAPやWS-Securityと比べれば、インターネット接続には向かない。Kerberosネットワークプロトコルは通常、ファイアウォールでブロックされるからだ（内部システムへのリモート・ログオンやDoS攻撃を防止するため）。ブロックされない場合でも、Network Access Translation（NAT）を行うファイアウォール越えのオペレーションは難しい。

　また、KerberosはWS-Securityよりも拡張性が乏しく、ブリッジ・プロトコルとしての適性も低い。Kerberosプロトコルを拡張することは可能だが、ほかのプロトコルの認証データを搬送し、プロトコル間をブリッジできるように拡張するのは容易ではない。

TrustBridgeとPassportによるサポート

　MicrosoftはTrustBridgeを2段階の大きなステップで実装しようとしている。

■TrustBridge for Windows Kerberos

　Microsoftは2003年にWindows版のTrustBridgeをリリースする予定だ。これにより、企業は任意のプラットフォーム（Linuxなどの非Windowsプラットフォームを含む）でKerberos v5を使い、インターネット経由でパートナーと認証データの交換が可能になる。

　同ソフトのパッケージングについてはまだ決定していないが、MicrosoftのWebサービス技術マーケティング・ディレクター、Steven VanRoekel氏によると、Windows .NET Serverのアップデート版か、Microsoftのファイアウォール製品の次期バージョン、Internet Security and Acceleration（ISA）Serverで提供される可能性が高い。

■Passport

　MicrosoftはPassportを改訂し、Kerberosを利用して、TrustBridgeがサポートするインターチェンジ・プロトコルのWebサイトや企業と、認証データを交換可能にする。また、Windows .NET ServerもPassportと認証データをやりとりし、PassportのユーザーIDをADアカウントにマッピングできるようになる。

　ほかの改良点（Passportユーザーがサインアップしたときの身元確認など）とともに、新しい機能は企業とPassportのフェデレーションを可能にし、新たな可能性を切り拓くものになる。例えば、TrustBridge（あるいはサードパーティの互換ソリューション）を利用する企業は、Passport IDを持つ任意の個人に社内リソースへのアクセスを許可することが可能になる。

　さらに、フェデレーテッドISPのユーザーは再度ログオンしなくても、Passportで保護されたWebサイトにアクセスできるようになる。彼らがネットワークに最初にサインインしたときの認証をPassportが認識できるからだ（詳細情報はDirections on Microsoft日本語版2001年12月15日号の「クローズドシステムからトラストブローカーへ　認証システムの統合を目指すPassport」参照）。

　Microsoftでは、いずれサードパーティがインターチェンジ・プロトコルでほかの認証システム（例えばRADIUS、PKIプロトコル）と接続するTrustBridgeのようなゲートウェイ製品の開発に取り組むことを期待している。IBMはTrustBridgeのWebサービス仕様の策定に協力したので、将来製品でそれらをサポートすると見られるが、具体的計画はまだ明らかにしていない。

目標は標準策定とADの採用推進

　TrustBridgeは少なくとも6カ月以内に登場することはなく、恐らく今後1年以上はかかるだろう。パッケージングなどの詳細も不明だ。こうした事実は、今回の発表がライバル企業（特にSunMicrosystems）より先にWebサービスの仕様を定義することが狙いだったことを示唆している。

　2002年2月、MicrosoftとIBM、そのほかの50社は、Webサービス向けの広範な標準（TrustBridgeの仕様も含む）を提案するWeb Services Interoperability Organization（WS-I）を組織した。OracleやSAPなど、Microsoftのライバル企業の多くが参加したが、Sunは加わらなかった。同社の懸念は、Microsoftが業界での影響力を行使して、Javaベースのソリューションではなく、Windowsと .NETプラットフォームをサポートする仕様を定義するのではないかということだ。

　Microsoftは現時点で発表することにより、今回の仕様案が実際に2003年には製品出荷に結び付くと顧客に信じ込ませようとしている。もう1つ重要なポイントは、動きの遅いWindowsユーザーに対し、ADへの移行とWindows .NET Serverの導入を促進することだ。

　そして今回の発表は、Passportをフェデレーションに対してオープンにするというMicrosoftの約束に技術的な裏付けを与え、より多くのWebサイトにPassportを採用するように働きかける効果があるだろう。

Directions on Microsoft日本語版 本記事は、（株）メディアセレクトが発行するマイクロソフト技術戦略情報誌「Directions on Microsoft日本語版」から、同社の許可を得て内容を転載したものです。Directions on Microsoftは、同社のWebサイトより定期購読の申込みができます。

　

コラム：Webサービス・セキュリティ仕様案 　過去数年間、MicrosoftとIBMは緊密に連携してWebサービスの各種仕様を定義してきた。例えば両社は、データを表現する手法としてXMLを、多様なシステム間でXMLデータをやりとりするフォーマットとしてSimple Object Access Protocol（SOAP）を、Webサービス間の相互検索・情報収集を支援する仕組みとしてWeb Services Description Language（WSDL）とUniversal Discovery, Description, and Identification（UDDI）を提案してきた。これらの仕様は業界で広く受け入れられ、一般にWebサービスという用語の一部と見なされている。 　しかし、両社はこれらの仕様がWebサービス関連のすべての問題を解決するには不十分だということに気付いた。特にWebサービス間での安全なデータ転送については規定されていない。 　そこでMicrosoftとIBM、VeriSignは2002年4月、「WS-Security」という新仕様を提案した。WS-Securityは署名付きの安全なSOAPメッセージを交換するための標準メカニズムを定義するものだ。認証チケットやトークンの情報は安全でなければならないため、TrustBridgeと改訂版PassportはWS-Securityを採用する。 　MicrosoftとIBMは、新仕様の発表と同時にホワイトペーパーを公開し、次のようなセキュリティ関連プロトコルを提示した。 WS-Policy：SOAPメッセージ内でセキュリティ・ポリシーを表現するための標準的方法。 WS-Privacy：SOAPメッセージ内でプライバシー・ポリシーを表現するための標準的方法。 WS-Secure Conversation：SOAPメッセージの交換を認証する標準的方法（例えばKerberosで使われるセッション・キーの設定、取得方法など）。 WS-Trust：2つの組織間の直接的な信用関係と、信頼できる第三者によって仲介された複数組織間の信用関係の両方を確立するための標準的メカニズム。 WS-Federation：WS-Security、WS-Policy、WS-Trust、WS-Secure Conversationの各サービスを組み合わせてフェデレーションを形成するための標準的方法。 WS-Authorization：Webサービスによる認証データとポリシーの管理方法（認証したユーザーに対して、何を許可するかを定義）。 　TrustBridgeとPassport改訂版は、これらの仕様（あるいはリリース時における発展形）のすべてをサポートする。 ■WS-Security仕様書 ■WS-Securityに関するIBMとMicrosoftのホワイト・ペーパー 「Security in a Web Services World: A Proposed Architecture and Roadmap」

「Insider's Eye」

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