付録 B

  • [アーティクル]

「付録 B」では、パッシブ (ブラウザー ベース) クライアント シナリオおよびアクティブ (スマート) クライアント シナリオでのメッセージ シーケンスについて詳しく説明します。また、ブラウザーまたはクライアント、アプリケーション、発行者、Microsoft® Active Directory® などが互いに通信するときに、HTTP トラフィックおよび (該当する場合は) Kerberos トラフィックがどのように見えるかについての情報も提供します。

ブラウザー ベースのシナリオ

図 1 は、ブラウザー ベースのシナリオでのメッセージ シーケンスを示しています。

図 1

ブラウザー ベースのシナリオでのメッセージ シーケンス

図 2 は、ブラウザーによって生成されたトラフィックを示しています。

図 2

HTTP トラフィック

スクリーンショットに示した番号は、メッセージの図に示したステップに対応します。この例では、アプリケーションの名前は a-Expense.ClaimsAware です。たとえば、スクリーンショットのステップ 1 は、メッセージの図に示されている発行者への最初の HTTP リダイレクトを示しています。次の表では、「#」列の記号の意味を説明します。

記号 意味
矢印 矢印は、HTTP 302 リダイレクトを示します。
キー キーは、Kerberos チケットのトランザクションを示します (401 コードは、認証が必要であることを示します)。
地球 地球は、成功した要求への応答を示します。つまり、ユーザーは Web サイトにアクセスできます。

ステップ 1

匿名ユーザーが a-Expense をブラウズし、WSFederatedAuthenticationModule (FAM) がユーザーを発行者 (この例では、https://login.adatumpharma.com/FederationPassive にある) にリダイレクトします。要求 URL には、4 つのクエリ文字列パラメーターが含まれています。具体的には、wa (実行するアクション、この例では wsignin1.0)、wtrealm (このトークンが適用される証明書利用者、この例では a-Expense)、wctx (さまざまなパーティ間で伝達される戻り先 URL などのコンテキスト データ)、および wct (タイム スタンプ) です。

図 3 は、ステップ 1 の応答ヘッダーを示しています。

図 3

ステップ 1 の応答ヘッダー

a-Expense の FAM は、匿名ユーザーを発行者にリダイレクトします。

図 4 は、発行者に送信される、クエリ文字列を含むパラメーターを示しています。

図 4

クエリ文字列パラメーター

ステップ 2

発行者は、Windows 統合認証だけで構成された Active Directory フェデレーション サービス (ADFS) 2.0 です。図 5 は、ADFS がユーザーを統合サインオン ページにリダイレクトすることを示しています。

注意

ADFS は、Windows 統合認証、クライアント証明書認証、およびフォーム ベース認証のすべてまたは一部を許可するように構成できます。どちらの場合も、資格情報は Active Directory アカウントにマップされます。

 

図 5

ADFS がユーザーを Windows 統合認証ページにリダイレクトする

ステップ 3

IntegratedSignIn.aspx ページは、インターネット インフォメーション サービス (IIS) 上で Windows 統合認証を使用するように構成されています。つまり、このページは、HTTP 401 ステータス コードと "WWW-Authenticate: Negotiate" HTTP ヘッダーを使用して応答します。これを図 6 に示します。

図 6

ADFS が WWW-Authenticate: Negotiate ヘッダーを返す

IIS は WWW-Authenticate:Negotiate ヘッダーを返して、Kerberos または NTLM がサポートされていることをブラウザーに知らせます。

ステップ 4

この時点で、ユーザーは、Kerberos または NTLM を使用して Microsoft Windows® 資格情報での認証を行います。図 7 は、Kerberos ではなく、NTLM の HTTP トラフィックを示しています。

注意

メモ: ブラウザーやサービス プリンシパル名などのインフラストラクチャが正しく構成されている場合、クライアントは、ドメイン コントローラーでホストされているキー配布センターからのサービス チケットを要求することで、ステップ 4 を回避できます。クライアントは、このチケットを次の HTTP 要求で認証子と共に使用できます。

 

図 7

ADFS Web サイト上の NTLM ハンドシェイク

要求ヘッダーの Cookies/Login ノードは、NTLM ハンドシェイク プロセスを示しています。このプロセスは、クレーム、WS-Federation、SAML、WS-Trust とは関係がありません。Windows 統合認証を使用して構成されているすべてのサイトで、同じことが発生します。Kerberos の場合、このステップは発生しません。

ステップ 5

Windows 資格情報によるユーザーの認証が成功したので、ADFS は Windows ID に基づいて SAML トークンを生成できます。ADFS は、ステップ 1 で説明した wtrealm パラメーターを使用して、アプリケーションに関連付けられているクレーム マッピング ルールを参照し、実行します。ルールが実行されると結果として一連のクレームが生成され、SAML アサーションに含められて、ユーザーのブラウザーに送信されます。

次の XML コードは、生成されたトークンを示しています (わかりやすくするために、一部の属性と名前空間は省略されています)。

 

ステップ 6

ADFS は、トークンを生成したら、それをアプリケーションに送り返す必要があります。トークンは長さが 4 KB になる場合もあり、これはほとんどのブラウザーの URL のサイズの上限を超えているため、標準の HTTP リダイレクトは使用できません。代わりに、発行者は POST メソッドを含む <form> を生成します。トークンは隠しフィールドに格納されます。ページが読み込まれると、スクリプトはフォームを自動的に送信します。次の HTML コードは、発行者の応答を示します。

<html>

  <head>

    <title>Working...</title>

  </head>

  <body>

    <form 

      method="POST" 

      name="hiddenform" 

      action=

        "https://www.adatumpharma.com/a-Expense.ClaimsAware/">

      <input type="hidden" name="wa" value="wsignin1.0" />

      <input 

         type="hidden" 

         name="wresult" 

         value="&lt;t:RequestSecurityTokenResponse   

                  xmlns...&lt;/t:RequestSecurityTokenResponse>" 

      />

      <input 

         type="hidden" 

         name="wctx" 

         value="rm=0&id=passive&

                   ru=%2fa-Expense.ClaimsAware%2fdefault.aspx" 

      />

      <noscript>

        <p>Script is disabled. Click Submit to continue.</p>

        <input type="submit" value="Submit" />

      </noscript>

    </form>

    <script language="javascript">

      window.setTimeout(&apos;document.forms[0].submit()&apos;, 0);

    </script>

  </body>

</html>

アプリケーションが POST を受け取ると、処理の制御は FAM に移ります。FAM は AuthenticateRequest イベントをリッスンします。図 8 は、AuthenticateRequest イベントのハンドラーで発生する処理を順を追って示しています。

図 8

アプリケーションに対する最初の要求のロジック

FAM が実行する処理の 1 つに、セッション セキュリティ トークンの作成があります。ネットワーク トラフィックの観点から見ると、このトークンは FedAuth[n] という Cookie のセットであり、ClaimsPrincipal オブジェクトを圧縮、暗号化、およびエンコードした結果です。Cookie のサイズ制限を超えないようにするために、Cookie はチャンク化されます。図 9 は HTTP 応答を示しており、セッション トークンは 3 つの Cookie にチャンク化されています。

図 9

セッション トークンが 3 つの Cookie にチャンク化された Web サイトからの HTTP 応答

ステップ 7

後続の要求に基づいて、セッション セキュリティ トークン (FedAuth Cookie) がアプリケーションに送信されます。FAM が AuthenticationRequest イベントを処理する場合と同様にして、SAM が図 10 に示したロジックを実行します。

図 10

アプリケーションに対する後続の要求のロジック

要求ごとに FedAuth Cookies が送信されます。図 11 は、ネットワーク トラフィックを示します。

図 11

2 番目の HTTP 要求のトラフィック

アクティブ クライアント シナリオ

このシナリオでは、アクティブ クライアントと、ADFS 発行者が生成したトークンを信頼するように構成された Web サービスとの間の相互作用を説明します。図 12 に、詳細なメッセージ シーケンスの図を示します。

図 12

アクティブ クライアント シナリオでのメッセージ シーケンス

図 13 は、アクティブ クライアントのメッセージ シーケンスに対応する HTTP トラフィックを示しています。

図 13

HTTP トラフィック

このシナリオの 2 つのステップを詳しく説明します。

ステップ 1

Orders Web サービスは、wsFederationHttpBinding を使用して構成されています。このバインドは、クライアントが Web サービスを正常に呼び出すためには SAML トークンを SOAP セキュリティ ヘッダーに追加することが必要であるという Web サービス ポリシーを指定します。つまり、クライアントは、最初に資格情報のセット (ユーザー名とパスワード) を使用して発行者にアクセスし、SAML トークンを取得する必要があります。次のメッセージは、https://login.adatumpharma.com/adfs/services/trust/13/usernamemixed でホストされている ADFS 発行者 (ADFS) に送信される RequestSecurityToken (RST) を表しています(わかりやすくするために、XML コードは要約されています。一部の名前空間と要素は省略されています)。

発行者は、資格情報を使用してユーザーを認証し、該当するルールを実行して Active Directory (または、発行者がアクセスするように構成されている他の属性ストア) からユーザーの属性を取得します。

トークンを暗号化解除するための秘密キー (上記の中で強調表示されている "<e:CipherValue>U6TLBMVR/M4Ia2Su...") を持っている場合は、次のように表示されます。

ステップ 2

発行者からトークンを取得したら、クライアントは、トークンを SOAP セキュリティ ヘッダーに追加して、Web サービスを呼び出すことができます。これが Order Web サービスに送信される SOAP メッセージになります。

Windows Identity Foundation (WIF) と Windows Communication Foundation (WCF) は、SAML トークンを暗号化解除し、検証を実行します。クレームが ClaimsPrincipal オブジェクトに追加され、プリンシパルが WCF セキュリティ コンテキストに追加されます。WCF セキュリティ コンテキストは、クライアントが行おうとする操作の呼び出しと到着クレームを比較してチェックすることで、承認マネージャーで使用されます。

前の章  | 次の章

ページのトップへ