クレーム ベースのアーキテクチャ
Web には、ユーザーがハイパーリンクをクリックするだけでアクセスできる多くの対話型アプリケーションがあります。ユーザーはクリックと共に目的のページが表示されることを期待していますが、ログオンに多少時間がかかることもあります。ユーザーは、ログオン セッションを Web サイトが管理することも期待しますが、ほとんどのユーザーはその期待をそのような言葉では表しません。しかしユーザーは、自社の Web アプリケーションを使用する場合は毎回パスワードを入力することは避けたいと内心思っているはずです。クレームが Web で広く使用されるためには、シングル サインオンと呼ばれる使いやすいユーザー エクスペリエンスをサポートすることが重要です。
注意
クレーム ベースのアプリケーションでは、Web のシングル サインオンは、パッシブ フェデレーションと呼ばれることがあります。
Windows ドメインに属しているユーザーは、既にシングル サインオンの利点を十分に活用しています。1 日の始めにパスワードを一度入力すると、ネットワーク内のさまざまなリソースに対するアクセス権が付与されます。現在、パスワード入力の要求が毎回表示されるのは、意外と同時に、煩わしいと思われるようになりました。こうして、Windows 統合認証が提供する透過性に期待が集まっています。
皮肉にも、領域をまたぐ柔軟なソリューションとしての Kerberos の人気は下降しています。ドメイン コントローラーは組織内のすべてのリソースに対するキーを保持するため、ファイアウォールによる厳重な保護が適用されます。職場から離れているときは、VPN を使用して企業ネットワークにアクセスすることが求められます。また Kerberos は、情報提供という点では柔軟性を持ちません。ユーザーの電子メール アドレスなど、任意のクレームを含めるように Kerberos チケットを拡張するとよいのですが、この機能はまだ実現していません。
クレームは、他のプロトコルにはない柔軟性を提供するように設計されました。ユーザーの想像力と、それを許す IT 部門のポリシーがあれば、可能性が制限されることはありません。クレームを交換する標準プロトコルは、セキュリティ領域、ファイアウォール、異なるプラットフォームなどの境界を越えることを目的として設計されています。また、これらのプロトコルは、安全な相互通信が簡単に実現されることを望んだ多くの人々が設計しています。
クレームによって、アプリケーションを ID の複雑な管理から切り離すことができます。これにより、ユーザーの認証は、アプリケーションの責務ではなくなりました。アプリケーションが必要とするものは、信頼する発行者からのセキュリティ トークンだけです。IT 部門がセキュリティのアップグレードを決定し、ユーザー名とパスワードに代わってスマート カードを送信するようにユーザーに求めても、アプリケーションは影響を受けません。また、アプリケーションは、再コーディング、再コンパイル、または再構成を行う必要もありません。
もちろん、ドメイン コントローラーによる組織リソースの保護が有効であることに疑いはありません。また、信頼の問題を解決する方法や、ID のフェデレーションを行う企業間での契約の締結方法といったビジネス課題も未解決のままです。クレーム ベース ID によってこれらが変わることはありません。しかし、クレームを既存のシステムの最上位層に置けば、幅が広く柔軟なシングル サインオン ソリューションの実現を妨げている可能性がある技術的なハードルのいくつかを取り除くことができます。
注意
既存のセキュリティ システムと組み合わせてクレームを機能させることで、その有効範囲を拡大し、技術的な問題を軽減することができます。
クレーム ベースのアーキテクチャの詳細な内容
クレーム ベースのアプリケーションを作成する際、使用できるアーキテクチャ上のアプローチは複数あります。たとえば、Web アプリケーションと SOAP Web サービスはわずかながら異なる技術を使用しますが、ハンドシェイクの全体の輪郭が非常に似ていることがすぐにわかります。これは、目標が常に同じ (クレームを発行者からアプリケーションに安全な方法で送信する) だからです。この章では、ユーザー エクスペリエンス、パフォーマンスの影響、最適化の機会など、さまざまな観点からアーキテクチャを評価する方法、およびクレームを発行者からアプリケーションに送信する方法について説明します。また、クレームの設計方法やユーザー情報の取得方法に関するアドバイスも提供します。
これらのアーキテクチャの目標の多くは、ブラウザーまたはスマート クライアントを使用してフェデレーションを有効にすることです。スマート クライアントを使ったフェデレーションは、WS-Trust および WS-Federation のアクティブな要求側プロファイルに基づいています。これらのプロトコルは、スマート クライアント (Windows ベースのアプリケーションなど) とサービス (WCF サービスなど) の間の通信フロー (トークンを発行者に要求し、そのトークンを認証のためにサービスに送信する) を表します。
ブラウザーを使ったフェデレーションは、WS-Federation のパッシブな要求側プロファイルに基づいています。このプロファイルで記述される通信フローは、ブラウザーと複数の Web アプリケーションの間ですべて同じです。フェデレーションは、トークンの要求と受け渡しを行う際、ブラウザーのリダイレクト、HTTP GET、および POST に依存します。
ブラウザー ベースのアプリケーション
Microsoft® Windows Identity Foundation (WIF) は、クレーム対応のアプリケーションを構築できる .NET Framework クラスのセットです。その役割の 1 つとして、WS-Federation 要求の処理に必要なロジックを提供します。WS-Federation プロトコルは、WS-Trust や WS-Security などの他の標準プロトコルの上に構築されます。機能の 1 つとして、ブラウザー ベースのアプリケーションからセキュリティ トークンを要求できます。
WIF では、クレームはフォーム認証とよく似ています。ユーザーがサインインする必要がある場合、WIF はユーザーを発行者のログオン ページにリダイレクトします。ユーザーはこのページで認証され、リダイレクトされてアプリケーションに戻されます。図 1 に、ユーザーがブラウザー アプリケーションからシングル サインオンを使用できるようにするステップの最初のセットを示します。
図 1
ブラウザーを使ったシングル サインオン - パート 1
ASP.NET フォーム認証を使い慣れている場合は、Login.aspx というページが公開されるため、前の図に示した発行者がフォーム認証を使用することを前提にすることも考えられます。ただし、このページは、Windows 統合認証やクライアント証明書、またはスマート カードを要求するために IIS (Internet Information Server) で構成された単なる空のページである可能性があります。発行者は、そこにサインインするユーザーを認証する方法の中で、最も自然で安全な方法を使用するように構成する必要があります。場合によっては、簡単なユーザー名とパスワードの形式で十分なこともありますが、これには多少のやり取りが伴い、ユーザーの時間を消費します。Windows 統合認証は、発行者と同じドメイン内の従業員にとっては使いやすく安全です。
ユーザーが発行者のログオン ページにリダイレクトされるとき、発行者への指示として使用される複数のクエリ文字列引数が渡されます。2 つの重要な引数とそのサンプル値を示します。
wa=wsignin1.0
wa 引数は、"アクション" を表し、ログオン (wsignin1.0) とログオフ (wsignout1.0) のどちらを行うかを示します。
wtrealm=http://www.fabrikam.com/purchasing/
wtrealm 引数は、"ターゲット領域" を表し、アプリケーションを識別する URI (Uniform Resource Indicator) を保持します。発行者は URI を使用して、ユーザーがログオンするアプリケーションを識別します。また、URI は、アプリケーションのクレームの関連付けやアドレスへの返信など、他のタスクを発行者が実行するためにも使用されます。
発行者がユーザーを認証したら、発行者はアプリケーションが必要とするすべてのクレームを集め (ターゲットのアプリケーションを識別するために wtrealm パラメーターを使用します)、集めたクレームをセキュリティ トークンにパッケージ化し、それに発行者の秘密キーで署名します。暗号化されたトークンをアプリケーションが要求すると、発行者は、アプリケーションの証明書の公開キーを使用してトークンを暗号化します。
注意
発行者には使用中のアプリケーションが通知されるので、発行者はそのアプリケーションに必要なクレームだけを発行します。
ここで発行者は、ブラウザーに対してアプリケーションに戻るように要求します。ブラウザーは、クレームを処理するために、アプリケーションにトークンを送信します。これが完了すると、ユーザーはアプリケーションの使用を開始できます。
これを実行するために、発行者はブラウザーに HTML ページを返します。この HTML ページには、フォームがエンコードされたトークンを内部に保持する <form> 要素が含まれています。フォームの action 属性が設定されていると、アプリケーションで構成されている任意の URL にトークンが送信されます。通常、発行者は簡単な JavaScript コードも送信し、これによって自動的にフォームが自動ポストされるため、ユーザーがフォームを目にすることはありません。スクリプトが無効にされている場合は、ユーザーがボタンをクリックすることによってサーバーへの応答をポストする必要があります。図 2 に、このプロセスを示します。
図 2
ブラウザーを使ったシングル サインオン - パート 2
ここでは、ユーザーのエクスペリエンスの観点からこのプロセスを考察します。発行者が Windows 統合認証を使用している場合、ユーザーがアプリケーションへのリンクをクリックすると、ブラウザーがまず発行者にリダイレクトされてから、アプリケーションに戻ってくるまで、ユーザーは少しの間待機します。その後、ユーザーは追加で入力することなくアプリケーションにログオンします。ユーザー名とパスワードのフォームやスマート カードなど、ユーザーからの入力を発行者が要求すると、ユーザーはログオンのために進行を短時間止められ、その後アプリケーションを使用できるようになります。ユーザー側から見ると、クレームを使用するログオン プロセスは、ユーザーにとって最も重要なログオン対象と一体化しています。
ステップのシーケンスについて
前の図で示したステップは、時間の経過と共に発生するステップのシーケンスで示すこともできます。図 3 に、このシーケンスを示します。
図 3
ブラウザー ベースのメッセージ シーケンス
ユーザーが認証されていない場合、ブラウザーは発行者 (この場合は、Active Directory フェデレーション サービス (ADFS)) にトークンを要求します。ADFS は、必要な属性を Active Directory にクエリし、署名されたトークンをブラウザーに返します。
POST がアプリケーションに到達すると、その後は WIF が引き継ぎます。アプリケーションは、WSFederationAuthenticationModule (FAM) という WIF HTTP モジュールを構成してあり、アプリケーションへのこの POST をインターセプトして、トークンの処理を制御します。FAM は AuthenticateRequest イベントをリッスンします。イベント ハンドラーは、トークンの対象ユーザーの制限や有効期限のチェックなど、いくつかの検証手順を実行します。対象ユーザーの制限は、AudienceURI 要素によって定義されます。これにより、トークン内に存在することをアプリケーションが許容する URI が限定されます。FAM は発行者の公開キーを使用して、トークンが信頼された発行者によって署名されたこと、およびトークンが転送中に変更されなかったことの確認も行います。次に FAM は、トークンでクレームを解析し、HttpContext.User.Identity プロパティ (または、同等の Page.User プロパティ) を使用して、IClaimsPrincipal オブジェクトをアプリケーションに提示します。また、Cookie を発行してログオン セッションを開始します。これは、クレームの代わりにフォーム認証を使用した場合と同様です。したがって、ユーザーがサインオフするか Cookie を破棄するまで、またはセッションの有効期限が切れるまで (セッションは通常、その営業日の終わりまで続くように指定されます)、認証プロセスが再実行されることはありません。
図 4 に、アプリケーションが発行者からトークンを受信するとき、最初の要求に対して WIF が実行するステップを示します。
図 4
最初の要求に対するステップのシーケンス
FAM が実行するステップの 1 つに、セッション トークンの作成があります。ワイヤ上でこれは、FedAuth[n] という Cookie のシーケンスに変換されます。これらの Cookie は、ClaimsPrincipal オブジェクトおよび他のすべての属性の圧縮、暗号化、およびエンコードの結果です。どのサイズの制限も超えないようにするため、Cookie はチャンク化されます。
図 5 に、最初の要求に対応するネットワーク トラフィックの内容を示します。
図 5
Cookie のシーケンス
アプリケーションに対する後続の要求では、SessionAuthenticationModule が Cookie をインターセプトし、その Cookie を使用して ClaimsPrincipal オブジェクトを再構築します。図 6 に、後続の要求に対して WIF が実行するステップを示します。
図 6
後続の要求のステップ
図 7 に、後続の要求に対応するネットワーク トラフィックの内容を示します。
図 7
後続の応答に対応するネットワーク トラフィック
最初の要求と後続の要求のどちらについても、すべてのステップを SSL (Secure Sockets Layer) 経由で実行する必要があります。これにより、傍受者がトークンまたはログオン セッション Cookie のどちらかを盗み、それをアプリケーションで再生して正当なユーザーを偽装する行為を防ぐことができます。
パフォーマンスの最適化
パフォーマンスを最適化する機会はあるでしょうか? 答えはもちろん "はい" です。ログオン セッション Cookie を使用して、クライアント側の何らかの状態をキャッシュすることで、発行者とのやり取りの回数を減らすことができます。発行者も固有の Cookie を発行するので、ユーザーは発行者側でログオン状態を維持でき、多くのアプリケーションにアクセスできます。ユーザーが 2 つ目のアプリケーションにアクセスし、そのアプリケーションが同じ発行者にリダイレクトされたときの動作について考えてみます。発行者は、自身の Cookie を参照することで、ユーザーが最近認証されてその認証が現在も続いていることを認識します。このため、発行者は再度認証する必要がなく、直ちにトークンを発行できます。このようにして、クレームを使用することでインターネット対応のシングル サインオンをブラウザー ベースのアプリケーションで実現することができます。
注意
アプリケーションと発行者は、Cookies を使用してインターネット対応のシングル サインオンを実現します。
スマート クライアント
Web サービスを使用する場合は、ブラウザーを使用しません。代わりに、クレーム ベース ID プロトコルを処理するためのロジックを含む任意のクライアント アプリケーションを使用します。このとき、重要な働きをするプロトコルが 2 つあります。1 つは WS-Trust です。これは、発行者からセキュリティ トークンを取得する方法を示します。もう 1 つは WS-Security です。これは、そのセキュリティ トークンをクレーム ベースの Web サービスに渡す方法を示します。
SOAP ベースの Web サービスを使用するための手順について思い出してください。Microsoft Visual Studio® 開発システムのツールまたはコマンドライン ツールを使用して、サービスのアドレス、バインド、およびコントラクトの詳細情報を提供する WSDL (Web Service Definition Language) ドキュメントをダウンロードします。このツールはプロキシを生成し、WSDL ドキュメントで検出された情報を使用してアプリケーションの構成ファイルを更新します。この操作をクレーム ベースのサービスで行うと、そのサービスの WSDL ドキュメントとそのサービスに関連付けられた WS-Policy ドキュメントにより、サービスが信頼する発行者に関して必要なすべての詳細情報が提供されます。つまり、プロキシは、サービスに要求を行う前にその発行者からセキュリティ トークンを取得する必要があることを認識しています。この情報はクライアント アプリケーションの構成ファイルに格納されているため、実行時にプロキシは、サービスとやり取りする前にそのトークンを取得できます。ブラウザーの場合は、まずアプリケーションにアクセスしてから発行者側にリダイレクトされる必要があったため、これにより、ブラウザーでのシナリオに比べてハンドシェイクが多少最適化されます。図 8 に、スマート クライアントのステップのシーケンスを示します。
図 8
スマート クライアント ベースのメッセージ シーケンス
スマート クライアントのステップは、ブラウザー ベースのアプリケーションのステップに類似しています。スマート クライアントは、発行者とのやり取りを行い、WS-Trust を使用してセキュリティ トークンを要求します。ステップ 1 で、Orders Web サービスが WSFederationHttpBinding を使用して構成されます。このバインドは、Web サービス ポリシーの仕様を定めます。これにより、クライアントは、Web サービスを正常に呼び出すために、SAML トークンをセキュリティ ヘッダーに添付することが義務付けられます。つまり、クライアントは、最初に、資格情報のセット (ユーザー名とパスワードなど) を使用して発行者を呼び出し、SAML トークンを取得しなければなりません。ステップ 2 で、クライアントは、トークンをセキュリティ ヘッダーに添付することで Web サービスを呼び出すことができます。
図 9 に、スマート クライアントのシナリオで発生するメッセージのトレースを示します。
図 9
スマート クライアントのネットワーク トラフィック
WS-Trust 要求 (技術的にはセキュリティ トークンの要求 (RST) と呼ばれます) には、AppliesTo というフィールドが含まれます。このフィールドを使用して、スマート クライアントは、現在アクセスを試みている最終ターゲットの Web サービスの URI を示すことができます。これは、Web ブラウザーの場合に使用される wtrealm クエリ文字列引数に似ています。発行者は、ユーザーを認証した後では、どのアプリケーションがアクセスを求めているかがわかり、発行するクレームも決定できます。発行者は応答 (RSTR) を返信します。応答には、Web サービスの公開キーで暗号化された署名入りのセキュリティ トークンが含まれています。トークンには、証明キーが含まれています。これは、発行者によってランダムに生成された対称キーであり、クライアントもコピーを取得できるように RSTR の一部として含まれます。
次に、クライアント側で、SOAP エンベロープの <Security> ヘッダーを使用して Web サービスにトークンを送信することが求められます。クライアントは、証明キーを認識していることを示すために、このキーを使用して SOAP ヘッダーに署名する (その 1 つがタイム スタンプ) 必要があります。Web サービスは、この暗号化された追加の証拠により、呼び出し元が最初にトークンを発行されたユーザーであることを重ねて確認できます。
通常は、この時点で WS-SecureConversation プロトコルを使用してセッションを開始します。同じサービスに後で再接続する必要が生じたときに備えて、クライアントは通常 RSTR をその日の終わりまでキャッシュしておきます。
領域間での ID のフェデレーション
クレーム ベース ID に関するこれまでの説明を通して、発行者がユーザーを直接認証する場合のクレーム ベースのアプリケーションの設計方法と構築方法を十分に理解できたと思います。
ここではさらに、1 段階詳しい内容を学ぶことができます。発行者の機能を拡張することで、ユーザーに直接認証することを求めるのではなく、別の発行者からのセキュリティ トークンを受け入れるようにすることができます。発行者は、セキュリティ トークンを発行するだけでなく、発行者が信頼する他の発行者からのトークンを受け入れることも行うようになります。これにより、ユーザーは他の領域 (個別のセキュリティ ドメイン) と ID のフェデレーションを行うことができます。これは、きわめて強力な機能です。フェデレーション プロセスは発行者をどのように構成するかによって異なるため、実際のフェデレーション プロセスの大部分は IT スタッフによって実現されます。しかし、これらの可能性は、最終的にはアプリケーションの変更がまったく不要なままアプリケーションに機能が追加されることにもつながるため、認識しておくことが重要です。また、これらの可能性の一部は、アプリケーションの設計に影響を与える可能性もあります。
領域間 ID の利点
ユーザーの ID データベースを保守することは困難な作業です。ユーザー名とパスワードだけを保持するデータベースのような単純な場合でも、管理には手間がかかります。ユーザーはしばしばパスワードを忘れますが、セキュリティの低い多くの Web サイトが行っているように忘れたパスワードを電子メールで送信することさえ、セキュリティに対する企業の方針によっては禁止されていることがあります。社内のユーザーのデータベースを保守することでさえ面倒ならば、数百、数千のリモート ユーザーについてこれを行う煩わしさは想像を絶するでしょう。
リモート ユーザーの役割データベースの管理も同様に面倒です。たとえば、パートナー企業で購買アプリケーションを使用している Alice という従業員について考えてみます。IT スタッフが Alice のアカウントを準備した日、Alice は購買部門に勤務していました。このため、IT スタッフは Alice に Purchaser (購入者) ロールを割り当て、アプリケーションを使用する権限を付与しました。しかし、別の企業に勤務する Alice がいつ営業部門に異動するかを、あなたの企業が知るにはどうすればよいでしょうか。また、Alice が退職した場合はどうでしょうか。いずれの場合も Alice の地位の変更について知る必要がありますが、Alice の企業の人事部門の誰かが知らせてくれることは考えられません。
注意
Alice の ID は Alice の組織の資産なので、Alice の企業がその ID を管理する必要があります。また、リモート ユーザーに関する情報を格納しておくことは、あなたの企業の義務と考えられます。
格納してあるリモート ユーザーについてのデータがいつか古くなることは避けられません。パートナーの業務で使用されるアプリケーションは、どのようにすれば安全に公開できるでしょうか?
クレーム ベース ID の最も強力な機能の 1 つとして、ID の分散化があります。自社の発行者にリモート ユーザーの認証を直接任せる代わりに、他社に属する発行者との間に信頼関係を設定します。これにより、他社の発行者がその他社の領域でユーザーを認証することを自社の発行者が信頼することになります。あなたの企業のアプリケーションを使用する際に特別な資格情報が不要になるため、他社の従業員にとっては望ましい環境となります。彼らは、彼らがふだん社内で使用しているものと同じシングル サインオン メカニズムを使用します。自社のアプリケーションは、引き続き同じボーディング パスを取得するので、以前と同様に動作します。リモート ユーザーのためにボーディング パスに含めるクレームは、彼らが自社の従業員でないためにロールの権限が少ない可能性がありますが、発行者が責任を持って適切な割り当てを決定します。新しい組織がパートナーになっても、自社のアプリケーションを変更する必要はありません。アプリケーションへの発行者の展開は、クレームを使用することで得られる大きな利点の 1 つです。1 つの発行者を再構成するだけで、下流の多くのアプリケーションに多くの新しいユーザーがアクセスできるようになります。
注意
クレームを使用して ID を分散化し、リモート ユーザーの古いデータを取り除くことができます。
もう 1 つの利点は、クレームを使用するとユーザーのデータを論理的に格納できることです。使いやすくアクセスしやすいだけのストアにではなく、権限を持っているストアにデータを保持できます。
ID フェデレーションによって、新しいユーザーを迎える際の障害となっていた可能性があるハードルが取り除かれます。クレーム ベースのアプリケーションへのアクセスを許可する領域を企業が決定すると、IT スタッフは適切な信頼関係を設定できます。これにより、たとえば、Java を使用している企業の従業員に対して、各従業員にパスワードを発行せずにアプリケーションへのアクセスを許すことができます。これに必要なのは Java ベースの発行者だけで、数年前から利用できるようになっています。別の可能性は、クレーム ベース ID をサポートする Windows Live™ との間で ID のフェデレーションを行うことです。これにより、Windows Live ID を持つユーザーは誰でもアプリケーションを使用できます。
フェデレーション ID の動作
フェデレーション ID が単一領域内でどのように動作するかについては既に確認しました。図 2 は、自社のアプリケーションとその領域内のローカル発行者の間における ID フェデレーションの小さな例を示しています。自社の発行者が別の領域の発行者とフェデレーションを行っても、この関係は変わりません。唯一の変更は、パートナー企業のユーザーを直接認証するのではなく、パートナー企業によって発行されるセキュリティ トークンを受け入れるように、発行者を再構成したことです。発行者は、ユーザーを認証する別の発行者を信頼しているため、直接認証する必要がありません。これは、アプリケーションがその発行者を信頼する方法に似ています。
図 10 に、領域間で ID のフェデレーションを行うためのステップを示します。
図 10
領域間での ID のフェデレーション
これは、パートナーの領域で最初のハンドシェイクを行うことが追加されただけで、この章の最初の図で既に確認した内容とまったく同じです。ユーザーはまず、固有の領域の発行者によって認証されます。ユーザーはやり取りによって受信したトークンを発行者に提示します。発行者は、ユーザーを直接認証する代わりにトークンを受け入れます。これで発行者は、使用するアプリケーション用のトークンを発行できます。このトークンは、ユーザーがアプリケーションに送信するトークンです (もちろん、ユーザーはこのプロトコルについて何も知りません。これは、実際にはユーザーを代行するブラウザーまたはスマート クライアントです)。アプリケーションは、信頼する発行者によって署名されたトークンを受け入れるだけです。リモート ユーザーは、ローカル発行者からアプリケーションにトークンを送信しようとしても、アクセス権がありません。
この時点で、「なぜ私の会社は、自社のアプリケーションを使用するユーザーを認証するために、他社を信頼する必要があるのか。安全とは思えない」」と思われるかもしれません。クレーム ベース ID がない場合に、このしくみがどのように機能するかを考えてみます。両社の責任者が話し合い、契約に署名します。次に、パートナー企業の IT スタッフが自社の IT スタッフに連絡して、アカウントの準備が必要なユーザーとそのユーザーに必要なロールを明確に伝えます。契約は、確立された信頼の不正使用の防止を図るものです。このプロセスは、長年にわたって実績のある一般的な慣例です。
別の疑問として、「データは時間の経過と共に古くなることがわかっているのに、なぜリモート ユーザーのために手間をかけてアカウントの準備を行うのか」と思われるかもしれません。クレーム ベース ID の機能の要点は、信頼の自動化を支援することです。これにより、ユーザーがこちらのアプリケーションにアクセスするたびに、そのユーザーの最新情報を取得できます。Alice が退職した場合、Alice の企業の IT スタッフは、Alice のアカウントを直ちに無効にしようと考えます。企業に不満を持つ元従業員が企業のリソースへのアクセス権を持っている状態を避けるためです。これにより、Alice は、Alice の企業の発行者によって認証されることができなくなります。つまり、Alice はアプリケーションを使用できなくなります。Alice について、誰も連絡してくる必要がなかった点に注意してください。ID の管理を分散化することで、リモート ユーザーに関する質の高い情報 (信頼できる情報) をタイムリーに得ることができます。
注意
クレームを使用することで、ビジネス間の既存の信頼を自動化できます。
他の多くの企業と ID のフェデレーションを行う場合に想定される問題の 1 つは、すべてのフェデレーション関係について、自社の発行者が単一障害点になることです。発行者は、ドメイン コントローラーと同程度に厳重に、障害から保護される必要があります。機能の追加には常にリスクが伴いますが、追加によるメリットがコストの低減、セキュリティの向上、アプリケーションの簡素化、ユーザーの満足につながります。
ID 変換
発行者のジョブは、一般的な受信 ID (Kerberos チケットまたは X.509 証明書からの送信) を受け取り、それを、自社のアプリケーションが使用できるセキュリティ トークンに変換することです。このセキュリティ トークンは、アプリケーションがジョブを行うために必要なユーザーの ID の詳細情報をすべて含むという点で、ボーディング パスに似ています。おそらく、すぐに使用できるロールは、ユーザーの Windows グループではなくボーディング パスに含まれています。
注意
発行者のことは、"ID トランスフォーマー" と呼ぶことができます。発行者は、受信 ID をアプリケーションが理解できる内容に変換します。
プロトコルのもう一方の側には、ユーザーがいます。ユーザーの領域内の発行者はユーザーを認証する方法を理解しているので、ユーザーはシングル サインオン資格情報を使用して多くのアプリケーションにアクセスできます。ユーザーのローカル発行者は、ユーザーのローカル領域内のアプリケーションおよび他の領域内の発行者にクレームを提供します。これにより、ユーザーはローカルとリモートの両方にある多くのアプリケーションの特別な資格情報を知らなくても、各アプリケーションを使用できます。
最後の図「領域間での ID のフェデレーション」で、アプリケーションのローカル発行者について考察します。アプリケーションのローカル発行者は、他の領域のユーザーからセキュリティ トークンを受信します。アプリケーションのローカル発行者の最初のジョブは、信頼している選ばれた発行者によって発行されたものでない受信トークンの場合に、要求を拒否することです。しかし、この確認が終わると、ジョブはクレーム変換の 1 つになります。アプリケーションのローカル発行者は、リモート発行者が作成したクレームをアプリケーションが理解するクレームに変換する必要があります。実用例については、第 4 章「Web アプリケーション用のフェデレーション ID」を参照してください。
注意
ADFS は、ルール エンジンを使用してクレーム変換をサポートします。
ADFS では、この種の変換は、「この種類、この値のクレームを受け取ったら、代わりにこのクレームを発行する」というルールを使って行います。たとえば、アプリケーションが Managers というロールを持ち、このロールはマネージャー固有の機能に対する特別なアクセス権を付与するとします。あるクレームが領域内の Managers グループに直接マップすると、それによって Managers グループに属するローカル ユーザーは、常にアプリケーション内で Managers ロールを取得するようになります。パートナーの領域では、アプリケーション内のマネージャー固有の機能にアクセスする必要がある Supervisors と呼ばれるグループがあるとします。Supervisors から Managers への変換は、パートナーの発行者内で行われる可能性があります。行われない場合は、自社で行う必要があります。この変換は ADFS の別のルールを必要とします。ポイントは、2 つの企業がまったく同じボキャブラリを使用することはほぼあり得ないので、ADFS などの発行者はこの種の変換をサポートするために特別に設計されているということです。
ホーム領域検出
領域間フェデレーションの可能性について確認したので、次は、領域間フェデレーションがブラウザー ベースのアプリケーションでどのように動作するかについて考えます。以下にステップを示します。
- Alice は (リモート領域で) アプリケーションへのリンクをクリックします。
- Alice は以前のようにローカル発行者にリダイレクトされます。
- 発行者は、Alice のブラウザーを Alice の領域内の発行者にリダイレクトします。
- Alice のローカル発行者は、トークンを認証して発行してから、そのトークンを付けて Alice のブラウザーを発行者に送信します。
- 発行者はトークンを検証し、クレームを変換し、使用するアプリケーションのトークンを発行します。
- 発行者は、アプリケーションが必要とするクレームが含まれたトークンを付けて、Alice のブラウザーをアプリケーションに送信します。
ここで不可解なことがステップ 3 にあります。Alice の送信元がリモート領域であることを発行者はどのように知るのでしょうか? Alice がローカル ユーザーでないと発行者に判断させ、Alice を直接認証しようとすると失敗すると判断させたものは何でしょうか? Alice の送信元がリモート領域であると発行者が知ったとしても、どの領域であるか、どのようにして知ったのでしょうか? これは、パートナーが複数存在することに関係するようです。
この問題は、"ホーム領域検出" と呼ばれます。発行者は、Alice の送信元がローカル領域であるか、パートナーの組織であるかを特定する必要があります。Alice の送信元がローカルである場合、発行者は Alice を直接認証します。Alice の送信元がリモートである場合は、Alice が Alice のホーム領域の発行者によって認証されるために、発行者は Alice のリダイレクト先の URL を知る必要があります。
この問題を解決する方法は 2 つあります。最も簡単な方法は、ユーザーの助けを借りることです。ステップ 2 で、Alice のブラウザーがローカル ADFS にリダイレクトされたとき、プロトコルを一時停止し、Alice に Web ページを表示して、勤務先の企業を尋ねます (Alice の資格情報は、一覧に含まれる企業のうちの 1 つ、Alice の企業でのみ有効なので、これについて Alice が嘘をついても通じません)。Alice が自分の企業のリンクをクリックすると、発行者の実行する処理が決まり、プロトコルが再開します。次回からこの質問を Alice に尋ねることを避けるために、発行者は Alice のブラウザーに Cookie を設定します。これにより、発行者は、次回から質問をしなくても Alice の発行者が誰であるかがわかります。
注意
この方法の使用例については、第 3 章「Web 用のクレーム ベースのシングル サインオン」を参照してください。
この問題を解決する 2 番目の方法は、ステップ 1 で Alice がクリックするリンク内のクエリ文字列にヒントを追加することです。このクエリ文字列に、whr というパラメーターを含めます (hr はホーム領域 (home realm) の略称です)。
注意
IT スタッフは、リモート アプリケーションへのリンクが常にこの情報を含んでいるかどうかを確認します。これにより、アプリケーションがユーザーにとって使いやすくなると同時に、すべてのパートナーが表示されることがなくなることで企業のプライバシーが保護されます。
発行者 (ADFS 2.0) はこのヒントを検出して、ユーザーのホーム領域の URL に自動的にマップします。これにより、Alice の発行者が誰であるかをアプリケーションが発行者に渡すため、発行者はこの情報を Alice に尋ねる必要がありません。発行者は先ほどと同じように Cookie を使用して、Alice がこの質問に煩わされないようにします。
注意
この方法の使用例については、第 4 章「Web アプリケーション用のフェデレーション ID」を参照してください。
ホーム領域検出と Web サービス
Web アプリケーションには、Web ページを利用してユーザーのヘルプを取得する方法が適しているかもしれません。Web アプリケーションは、その本来の特性として対話型であり、ブラウザーは必要に応じてホーム領域検出ページを表示できます。しかし、スマート クライアントと Web サービスでは、この問題をどのように解決するのでしょうか? この場合は、情報カードを利用できます (情報カードについては、このガイドでは扱いません)。
クレーム ベースのアプリケーションの設計に関する考慮事項
クレームを設計する際の一般的な規範的ガイダンスを提供することは、間違いなく困難です。これは、クレームが特定のアプリケーションに深く依存しているためです。このセクションでは、一連の質問を示し、選択肢に応じて検討の対象となるいくつかのアプローチを提供します。
優れたクレームの条件とは
設計上の最も重要な決定の多くがそうであるように、この質問には、常に明確な答えが用意されているわけではありません。重要なことは、直面する課題と、選択肢の間のトレードオフについて理解することです。ここにいくつかの具体的な例があります。これらは、優れたクレームを作成するための一般的な基準について考える際のヒントになるかもしれません。
まず、ユーザーの電子メール アドレスを考慮します。これは、ほぼすべてのシステムでクレームの最有力候補です。電子メール アドレスは通常、ユーザーの ID ときわめて緊密に結びついているため、領域間で ID のフェデレーションを行う際に誰もが必要とします。電子メール名を使用すると、システムをユーザーに合わせて、大きく役立つようにパーソナライズすることができます。
Web サイトのスキンやテーマに関するユーザーの選択はどうするか? たしかに、これは "パーソナライズ" データですが、1 つのアプリケーションに固有のデータでもあり、これがユーザーのアイデンティティの一部であるという主張は通りにくいでしょう。アプリケーションは、これをローカルで管理する必要があります。
アプリケーションのデータに対するユーザーのアクセス許可はどうするか? アクセス許可をクレームとしてモデル化することは、一部のシステムでは意味のあることですが、承認レベルを細かくモデル化すると、クレームの数が増え過ぎて収拾がつかなくなる可能性があります。適切なアプローチは、クレームから取得する承認データと、別の方法で処理するデータとを区別する境界を定義することです。たとえば、領域間フェデレーションのシナリオでは、いくつかの上位レベルのロールに対する権限を他の領域が持つようにすることが有益である場合があります。その上で、アプリケーションは Windows 承認マネージャー (AzMan) などのツールを使用して、細かく区分けされたアクセス許可にそれらのロールをマップできます。しかし、細かく区分けされたアクセス許可を管理することを意図して設計された発行者を取得できていない場合は、クレームをかなり高いレベルに保っておくことをお勧めします。
属性をクレーム化する際は、必ず事前に以下の質問に自分で答えてみてください。
- このデータは、ユーザー ID をモデル化する手段のコア部分か?
- 発行者はこの情報に対する権限を持っているか?
- このデータは、複数のアプリケーションで使用されるか?
- このデータの管理を発行者に任せるか、それともアプリケーションに直接管理させるか?
ユーザーを一意に識別する方法
人は一意の識別子を持って生まれてくるわけではないので (実際、大部分の人々は自分のプライバシーを心にしまっています)、これは昔から厄介な問題であり、これからもそうでしょう。クレームによってこの問題が簡単になるわけではありません。幸いなことに、ユーザーが誰であるかをすべてのアプリケーションが正確に知る必要はないのです。たとえば、ショッピング カートを実装する場合は、リピート ユーザーを識別できるだけで十分です。多くのアプリケーションは、この程度さえ必要ではありません。しかし、一部のアプリケーションは、ユーザーごとの状態を保持して追跡する必要があるので、各ユーザーに一意の識別子が必要です。
従来型のアプリケーションは、通常、サインイン名を利用してユーザーを区別しています。では、クレーム ベースのアプリケーションの構築に着手したとき、認証の制御を諦めるとどうなるでしょうか? ユーザーを一意に識別するためには、1 つの (または複数を組み合わせた) クレームを選択し、そのユーザーがアプリケーションにアクセスするたびに、そのクレームの同じ値を発行者に提供してもらう必要があります。ユーザーの一意の識別子を表すクレームを提供するように発行者に依頼するのもよいかもしれません。これは、複数の発行者が関係する領域間フェデレーションの場合、複雑になることがあります。このような込み入ったシナリオでは、各発行者には自身を識別するための URI があり、それを使用することで、ユーザーに発行する識別子のスコープを設定できるという知識が役立つことがあります。このような URI は、たとえば、http://issuer.fabrikam.com/unique-user-id-assigned-from-fabrikams-realm です。
電子メール アドレスには、一意性や組み込み済みのスコープという便利な特性があるため、電子メールのクレームをユーザーの一意の識別子として使用するように選択することが考えられます。これを行う場合は、ユーザーのデータに関連付けられた電子メール アドレスをユーザーが変更できるようにするかどうかについて、事前に計画を立てておく必要があります。その際は、新しい電子メール アドレスをユーザーのデータに関連付けるための方法も必要です。
アクセスの可能性があるすべてのユーザーと使用可能なすべてのクレームの一覧を取得する方法
クレーム ベースのアプリケーションを構築する際に留意する重要なことの 1 つは、アプリケーションを使用できるすべてのユーザーを決して知ろうとしないということです。特定のユーザー ストアに基づいてプログラミングを行うことに伴う責任、心配、手間を軽減することと引き換えに、すべてのユーザーを制御することは諦めます。ユーザーは戸口に現れて、こちらが信頼する発行者から取得したトークンを提示します。そのトークンは、ユーザーが誰であるか、およびユーザーは何ができるかについて情報を提供します。また、必要なクレームが含まれないトークンは、信頼された発行元から送信された場合でも拒否する必要があります。正しい設計を行った場合は、フェデレーション シナリオと同様に新しいユーザーが他の領域から送信された場合でも、それらのユーザーをサポートするためにコードを変更する必要はありません。
では、どのようにすれば、アプリケーションにアクセスする権限を持つユーザーと持たないユーザーを管理者が選択するためのユーザー一覧を構築できるでしょうか? 答えは、"別の方法を探す" ことです。これは、発行者が承認判断にかかわる必要がある最適な例です。発行者は、アプリケーションを使用する権限のないユーザーにトークンを発行してはなりません。アプリケーションに何も手を加えることなく、これが実行されるように構成する必要があります。
クレーム ベースのアプリケーションを設計する場合は、アプリケーション開発者としての ID に対する責任がある程度軽減されたことを必ず確認してください。ID 関連のタスクをアプリケーション ロジックに組み込むことが困難または不可能と感じられたら、代わりに発行者がそのタスクを処理できないか検討してください。
クレームを発行する場所
発行者が 1 つしかない単純なシステムの場合、この質問は無意味です。しかし、アプリケーションからユーザーのホーム領域にある発行者まで、複数の発行者が 1 本の信頼パスにつながれるような複雑なシステムの場合、この質問は大きな意味を持つようになります。
注意
クレームは必ず権限を持っているソースから取得します。
質問に対する簡単な答えは、"一番多くを知っている発行者を使用する" ことです。
たとえば、個人の電子メール名などのクレームを考えます。ユーザーの電子メール名は、使用するアプリケーションによって変わることはありません。この種のクレームの場合、ユーザーのホーム領域の近くで発行することには意味があります。実際に、ユーザーの電子メール名に対して権限を持っている可能性が最も高いのは、チェーン内の最初の発行者 (ID プロバイダー) です。したがって、それよりも下流の発行者やアプリケーションは、その中心的なクレームの恩恵を被ることができます。電子メール名を更新する場合は、その中心的な場所で電子メール名を更新するだけで済みます。
ここで、アプリケーションに固有の "アクション" クレームについて考えてみます。経費報告書を作成するアプリケーションは、submitExpenseReport や approveExpenseReport などのアクションを許可または禁止する可能性があります。バグを追跡するアプリケーションなどの別の種類のアプリケーションは、それらとは大きく異なる reportBug や assignBug などのアクションを備えていることが考えられます。システムによっては、ロールやグループなどの上位レベルのクレームに基づいて、各アプリケーションがこれらのアプリケーションを内部で処理する方がシステムの性能を発揮できる場合があります。しかし、これらのアクションを取り出してクレームに入れると決めた場合は、アプリケーションに近い発行者がクレームに対して権限を持つことが最適です。この種のクレームに対してローカルの証明機関を持つと、中央の証明機関に連絡する必要がないため、ポリシーの変更をより短時間で実装できるようになります。
グループ クレームやロール クレームをどう扱うか? 従来のロール ベースのアクセス コントロール (RBAC) システムでは、ユーザーは 1 つまたは複数のグループに割り当てられ、グループはロールにマップされ、ロールはアクションにマップされます。このシステムが優れている理由は数多くあります。たとえば、あるアプリケーションにおけるロールからアクションへのマッピングは、そのことに習熟し、そのアプリケーションのために定義されたアクションを理解している個人が実行できます。たとえば、ユーザーからグループへのマッピングは、各グループの意味を理解している中央の管理者が実行できます。また、グループは中央のストアで管理する一方で、ロールとアクションは分散化して、それらを定義するさまざまな部署と製品グループで処理することができます。これにより、ID と承認データを必要に応じて集中化または分散化できるアジャイル システムを実現できます。
発行者は一般的に、組織と組織の境界に配置されます。たとえば、複数の部署を持つ企業を考えます。各部署は固有の発行者を持つことができ、企業は、企業に入ってくる、または企業から出て行くクレームのゲートウェイとなる中央の発行者を持ちます。類似の構造を持つ別の企業のアプリケーションにこの企業のユーザーがアクセスすると、要求は最終的に、次の 4 つの発行者によって処理されます。
注意
発行者は一般的に、組織の境界にあります。
- 部署の発行者。ユーザーを認証し、電子メール名および一定の初期状態のグループ クレームを提供します。
- 企業の中央の発行者。グループと、そのグループに基づくいくつかのロールを追加します。
- アプリケーションの中央の発行者。ユーザーの企業のロールをアプリケーションの企業が理解するロールにマップします (この発行者は、既に存在するロール クレームに基づいて新しくロール クレームを追加する場合もあります)。
- アプリケーションの部署の発行者。ロールをアクションにマップします。
要求がこれらの各境界を越えるとき、その境界にある発行者は、要求の要件とプライバシー ポリシーに基づいてターゲットのコンテキストに合ったクレームを発行することで、ユーザーのセキュリティ コンテキストを強化および抽出しています。電子メール名は最終のアプリケーションまで渡されるでしょうか? これは、その情報を持つアプリケーションの企業をユーザーの企業が信頼しているかどうか、また、その情報がアプリケーションに必要であるとアプリケーションの企業が考えるかどうかに依存します。