アイデンティティの委任はいつ使うべきか

  • [アーティクル]

ID 委任とは

ID 委任は、Active Directory フェデレーション サービス (AD FS) 2.0 の機能の 1 つで、これを使用すると、管理者が指定するアカウントがユーザーを偽装できます。ユーザーを偽装するアカウントは、デリゲートと呼ばれます。この委任機能は多くの分散アプリケーションにとって欠かせません。これの分散アプリケーションでは、発生元要求の承認チェーン内にある各アプリケーション、データベース、またはサービスに対して、一連のアクセス制御チェックを順番に行う必要があります。実際のシナリオでは、多くの場合、"フロントエンド" の Web アプリケーションは、Microsoft SQL Server データベースに接続された Web サービスなどのセキュリティ保護が強化された "バックエンド" からデータを取得する必要があります。

たとえば、既存のパーツ注文 Web サイトをプログラムによって機能拡張して、パートナー組織が自組織の購入履歴とアカウント ステータスを参照できるようにすることができます。セキュリティ上の理由により、パートナーのすべての財務データは、専用の SQL (構造化照会言語) サーバーのセキュリティ保護されたデータベースに格納されます。この状況では、フロントエンドのアプリケーションのコードから、パートナー組織の財務データに関する情報を取得することはできません。このため、アプリケーションは、ネットワーク上の他の場所に存在する別のコンピューターからデータを取得する必要があります。この例の場合、それはパーツのデータベース (バックエンド) の Web サービスをホストするコンピューターです。

このデータ取得処理を成功させるには、次の図に示すように、Web アプリケーションとパーツのデータベースの Web サービスとの間で "ハンドシェイク" という一連の承認を行う必要があります。

元の要求が Web サーバー自体に対して行われ、その Web サーバーが属する組織はアクセスを試みたユーザーの組織とはまったく別であると考えられるため、要求と共に送信されるセキュリティ トークンは、Web サーバーおよび他のすべてのコンピューターにアクセスするために必要な承認基準を満たしません。このため、元のユーザーの要求に応える唯一の方法は、リソース パートナー組織に中間的なフェデレーション サーバーを配置し、適切なアクセス権限を持つセキュリティ トークンをこのサーバーに再発行させることです。

ID 委任のしくみ

多層アプリケーション アーキテクチャの Web アプリケーションは、共通のデータや機能にアクセスするために Web サービスを呼び出すことがあります。これらの Web サービスにとって、元のユーザーの ID を知ることは、承認の判断を行ったり監査を円滑に進める上で重要です。この場合、フロントエンドの Web アプリケーションは、Web サービスに対してユーザーをデリゲートとして提示します。AD FS 2.0 は、Active Directory のアカウントが別の証明書利用者に対してユーザーとして動作することを許可することにより、このシナリオをサポートします。ID 委任のシナリオを次の図に示します。

  1. Frank は、別の組織の Web アプリケーションからパーツ注文の履歴にアクセスを試みます。Frank のクライアント コンピューターは、フロントエンドのパーツ注文 Web アプリケーション用の AD FS 2.0 に対してトークンを要求し、受け取ります。

  2. クライアント コンピューターは、クライアントの ID を証明するために、手順 1 で取得したトークンを含む要求を Web アプリケーションに送信します。

  3. Web アプリケーションは、Web サービスと通信して、クライアントのトランザクションを完了する必要があります。Web アプリケーションは、AD FS 2.0 にアクセスして、Web サービスとやり取りするための委任トークンを取得します。委任トークンは、ユーザーとして動作するためにデリゲートに対して発行するセキュリティ トークンです。AD FS 2.0 は、クライアントに関するクレームと共に委任トークンを Web サービスに返します。

  4. Web アプリケーションは、手順 3 で AD FS 2.0 から取得したトークンを使用して、クライアントとして動作する Web サービスにアクセスします。委任トークンを確認することで、Web サービスは、Web アプリケーションがクライアントとして動作しているかどうかを判断できます。Web サービスはその承認ポリシーを実行し、要求のログを記録し、Frank が要求した必要なパーツの履歴データを Web アプリケーション経由で Frank に提供します。

特定のデリゲートについて、AD FS 2.0 は、Web アプリケーションが委任トークンを要求できる Web サービスを制限することができます。クライアント コンピューターは、Active Directory アカウントがなくてもこの操作を実行できます。既に述べたように、Web サービスは、ユーザーとして動作するデリゲートの ID を簡単に特定できます。このため、Web サービスは、クライアント コンピューターに直接アクセスするかデリゲート経由でアクセスするかに応じて、動作を変更できます。

ID 委任向けに AD FS 2.0 を構成する

データ取得処理のために必要であれば、いつでも AD FS 2.0 管理スナップインを使用して、ID 委任向けに AD FS 2.0 を構成できます。構成が完了すると、AD FS 2.0 は、承認コンテキストを含む新しいセキュリティ トークンを生成できます。バックエンド サービス保護されたデータへのアクセスを提供する前に、この承認コンテキストを要求することがあります。

AD FS 2.0 では、偽装可能なユーザーは制限されません。ID 委任を行うように構成された AD FS 2.0 は、次のことを実行します。

  • ユーザーを偽装するためのトークンを要求する証明機関をどのサーバーに委任するかを決定します。

  • 委任されるクライアント アカウントの ID コンテキストと、デリゲートとして動作するサーバーの両方を設定し、両者を明確に区別します。

ID 委任を構成するには、AD FS 2.0 管理スナップインで委任承認ルールを証明書利用者の信頼に追加します。これを行う方法の詳細については、「チェックリスト: 証明書利用者の信頼のクレーム ルールを作成する」(英語) を参照してください。

ID 委任向けにフロントエンド Web アプリケーションを構成する

Web のフロントエンド アプリケーションまたはサービスを適切にプログラミングし、委任要求を AD FS 2.0 コンピューターにリダイレクトするために開発者が使用できる選択肢は複数存在します。Web アプリケーションをカスタマイズして ID 委任と連動させる方法の詳細については、「Windows Identity Foundation SDKhttps://go.microsoft.com/fwlink/?LinkId=122266」(英語) を参照してください。