Print-friendly Version
執筆者: Martin Gee、ICSynergy International、2007 年 4 月 17 日
堅牢なセキュリティーソフトウェアやシステムへの要求が日増しに高まっている今日では、代わりとなる認証および信頼メカニズムが人気を集めています。特に、ユーザー名とパスワードによる認証モデルはセキュリティーに関する多くの不正行為の根本原因の典型的なものとなっています。なぜでしょう。第 1 に、我々の多くはパスワードをどこかに記録するため、簡単に盗み見られてしまいます。第 2 に、我々は記憶しやすいパスワードを作成しがちですが、そうしたパスワードは推測や検出も容易になります。その結果、このモデルに沿ってプロセスを確立してしまった企業が、大規模なシステム変更なしに システムのセキュリティー保護と最適化を実現できる方法を、探し求めているのです。
Windows CardSpace (以下 CardSpace) を取り上げます。これはここ数か月間で注目を集めている、Microsoft がリードする仕様です。CardSpace は、デジタル資格管理用の InfoCard と呼ばれるセキュリティートークンを採用する単純化されたパラダイムを定義しており、Windows XP と Vista で利用可能になっています。
OpenSSO は、Sun Java System Access Manager のソースコードに基づく、Sun のオープンな Web アクセス管理プロジェクトです。java.net 上のオープンソース Project CardSpace の一環として、ICSynergy は OpenSSO を拡張し、CardSpace が単純な認証モジュールの 1 つとして含まれるようにしました。さらに、ICSynergy は、OpenSSO および Sun Java System Access Manager 向けの商用 CardSpace 実装とトレーニングプログラム を提供しています。
この記事では、CardSpace-OpenSSO 認証モジュールの利点、基本アーキテクチャー、およびプロセスフローについて説明します。
目次
CardSpace は、サーバーとクライアント双方の信頼モデルとそのメカニズムを明確に定義しています。xmldsig のような SAML (Security Assertion Markup Language) 関連要素など、その構成要素を活用すれば、ユーザー独自のニーズに合わせてツールキットを作成またはカスタマイズできます。前述したように、この認証モジュールの目的は、ユーザー名とパスワードのモデルに代わる代替システムを構築することで、時代遅れのアプローチに依存しないですむようにする、あるいはその依存度を低減することです。この目的の達成に重要となる要素の 1 つは、ユーザーを CardSpace にスムーズに移行させるための計画です。
CardSpace による認証は単純です。ユーザーは、Web サイトにアクセスできるように InfoCard を提供します。その背後には信頼モジュールが存在しますが、それらのモジュールの具体例については後述します。図 1 にプロセスフローを示します。
図 1:CardSpace による認証メカニズムのプロセスフロー
利点 InfoCard の主な利点は、電子メールや配送先住所など、クレームと呼ばれる一般的な属性を格納および提供できることです。通常、クレームは機密データではないため、CardSpace 対応サイトは InfoCard の値に従ってサービスを処理できます。InfoCard をサポートする Web サイトは、クレームを指定することを、カード選択プロセスの一部としてユーザーに義務づけることができます。その結果、次の 2 つの利点が生まれます。
時間短縮およびデータ内の誤りの減少
目的のサイトに応じてクレームを選択できる柔軟性
より高度な設計では、クレームを拡張してより機密性の高いデータを含めることができます。
ユーザーインタフェース ユーザーは自身の InfoCard をどこに格納するのでしょうか。CardSpace の CardSelector の中です。これは仮想的な財布であり、この中には、ユーザーが作成したカードや信頼できるサイト経由でユーザーに対して発行されたカードが収められます。CardSpace 対応サイトにアクセスしたユーザーは、顧客や従業員など、そのエンティティーとの関係が反映された適切な InfoCard を選択するように、CardSelector から求められます。図 2 に典型的なインタフェースを示します。
図 2:CardSpace での InfoCard の管理
CardSelector にはその他の機能も備わっています。たとえば、管理されたカードを使用するシナリオでは、CardSelector はトークンや情報のブローカとして機能します。読み進めてください。
InfoCard の種類 CardSpace は次の 2 種類の InfoCard をサポートします。
自己発行 InfoCard: ユーザーが CardSelector を使って作成する InfoCard であり、その InfoCard をどこで認証用に使用するかを指定します。自己発行 InfoCard をサポートする Web サイトは通常、ユーザーとそのサイトを持つ団体との間の信頼を確立するために、登録を必要とします。
管理された InfoCard: 信頼できるアイデンティティープロバイダ (IdP)、つまり、あるユーザーがそのユーザーが主張するとおりの人であることを真に証明することのできるエンティティー、によってユーザー向けに発行されます。CardSpace の仕様では、管理されたカードおよびサーバー側コンポーネントの責任と役割が明確に定義されています。 好例としてオンラインバンキングが挙げられます。財務情報などの信用データの転送が発生する Web トランザクションでは、ユーザー、IdP、および InfoCard を受け付けるサイト (通常は銀行) の間の信頼モデルが必須となります。
この節では、ユーザー Martin Gee が CardSpace と OpenSSO を使ってアプリケーションにアクセスできるようにするための構造とプロセスフローについて説明します。
コンポーネントおよび目標 CardSpace アーキテクチャーに含まれる主要コンポーネントは、次のとおりです。
サーバー側コンポーネント: InfoCard のコンシューミングサービスと、アクセス管理に必要とされる機能を提供します。一例として OpenSSO サーバーが挙げられますが、その構成要素は次のとおりです。
設定済みの OpenSSO インスタンス: Web コンテナ内で実行されます。ICSynergy はこの認証モジュールを Apache Tomcat を使って開発しましたが、同社はまもなく Sun Java System Application Server のオープンソースプロジェクトである GlassFish に作業を移します。
SSL (Secure Sockets Layer) 対応 Web コンテナ: CardSelector はこれを使って InfoCard を転送します。この転送は SSL チャネルでのみ行われますが、これは、認証局が発行した本物の証明書を入手する必要があることを意味します。CardSpace は信頼できない証明書をサポートしません 。
認証モジュール: InfoCard とクレームをコンシュームします。
補助的なアクセス管理サービス: セッションやポリシーなどの管理です。
クライアント側コンポーネント: CardSelector 経由で InfoCard を転送します。これは、Internet Explorer 7.0、Firefox のいずれかのブラウザと適切な CardSpace 拡張を使って設定された Windows クライアントです。Vista 以外のマシンの場合は、.NET 3.0 ランタイムをインストールします。注: Microsoft 製以外の CardSelector が使用可能になりました。必ず最新の .NET ランタイムをインストールおよび設定してください。関連情報については、「参考文献 」を参照してください。
認証機能の準備が完了したら、次のステップは、次のサービスを含むプロセスを設計することです。
保護されたアプリケーションへの InfoCard クレームのセキュリティー保護された転送
補助的なユーザー登録
時代遅れの認証システムからのユーザーの移行
プロセスフロー 前の項で説明したトポロジやユーザープロセスフローの背景にある概念は、OpenSSO が CardSpace 機能をサポートする一方、保護されたアプリケーションは InfoCards のコンシューム方法を意識する必要がない、というものです。したがって、スケーラビリティーにおける柔軟性の向上、保守の低減、全体的なセキュリティーレベルの向上を図れます。図 3 に、疎結合された CardSpace 対応アプリケーションと連携する OpenSSO のプロセスフローを示します。
図 3:CardSpace 対応アプリケーションのプロセスフロー
黄色の三角形は OpenSSO ポリシーエージェントを表しますが、このエージェントは、ユーザー認証、URL、対象、認証モジュール、時刻などに関するポリシールールを適用することによって、アプリケーションへの Web トラフィックを制御します。このアーキテクチャーでは、ポリシーエージェントの機能を活用することで、保護されたアプリケーションへとつながる HTTP フローへの信用データの挿入と、後続の InfoCard クレームの共有を実現しています。
ユーザーが InfoCard アクセスをはじめて行う場合のプロセスを、次に示します。
Open SSO によって管理される InfoCard プロンプト画面から、ユーザー Martin が「Log In」をクリックします。
図 4 を参照してください。
図 4:認証用のプロンプト画面
InfoCard を選択するための画面が表示されます。図 2 を参照してください。
Martin が適切な InfoCard を選択します。 これは初回のアクセスであるため、図 5 の画面が表示され、InfoCard をユーザーのアカウントにリンクするかどうかを尋ねられます。これが、ユーザー名とパスワードによる認証モデルからセキュリティーレベルの高い InfoCard モデルへの、ICSynergy による軽量な移行の始まりです。
図 5:アカウントリンクの移行画面
ユーザーが「Yes」をクリックすると、CardSpace はその手順を実行するために OpenSSO へのログインをユーザーに要求します。図 6 を参照してください。
図 6:OpenSSO にログインするためのプロンプト画面
Martin が自身のユーザー名とパスワードを使ってログインします。図 7 を参照してください。
図 7:ログイン画面
Martin の資格の認証が完了するとすぐに、その旨が通知されます。この時点で、ユーザー名とパスワードによる認証モデルから InfoCard 認証モデルへの移行が完了します。図 8 を参照してください。
図 8:ログイン成功の通知
このアーキテクチャーでは、Martin が「Requested URL」をクリックすると、OpenSSO のユーザープロファイル編集画面が表示されます。図 9 を参照してください。
図 9:OpenSSO のユーザープロファイル編集画面
この記事では、CardSpace と OpenSSO を使って設計された、登録プロセスを含む典型的なセキュリティーアーキテクチャーについて概説しました。将来の記事では、管理されたカードを詳しく取り上げる予定です。
InfoCard は、適切に調整された移行プロセスが用意されていれば、リスクがますます増大している時代遅れの「ユーザー名とパスワードによる認証モデル」に代わる、現実的な選択肢となりえます。新しい技術ではいつもそうですが、エンドユーザーとサポートスタッフの教育が主要な、そしてしばしば難易度の高い作業となります。
CardSpace は電子商取引の分野に非常に適しているため、B2C の世界でおそらく広く受け入れられることになるでしょう。まだ多少時間がかかるでしょうが、CardSpace、連携、および Web サービスを組み合わせた高度な開発が目前に近づいています。
Project CardSpace にぜひお越しください。我々の目的は、この認証モジュールを OpenSSO の一部として配布することです。ぜひ我々の仲間に加わってください。