次の方法で共有

フェデレーション

  • [アーティクル]

フェデレーションを使用すると、割り当て間の他のメンバーに承認機関を委任できます。 たとえば、次のビジネス上の問題を考えてみましょう。自動車部品製造会社 Contoso Ltd は、顧客 Fabrikam Inc の承認された従業員が Contoso の部品注文 Web サービスに安全にアクセスできるようにしたいと考えています。 このシナリオの 1 つのセキュリティ ソリューションは、Contoso が Fabrikam で信頼メカニズムを設定し、アクセス承認の決定を Fabrikam に委任することです。 このプロセスは、次のように機能する可能性があります。

  • Fabrikam は、Contoso のパートナーになると、Contoso との信頼契約を設定します。 この手順の目的は、Fabrikam の承認を表し、Contoso に受け入れられるセキュリティ トークンの種類とコンテンツについて合意することです。 たとえば、サブジェクト名 "CN=Fabrikam Inc Supplier STS" を持つ信頼できる X.509 証明書が、Contoso Web サービスによって受け入れられるその SAML の SAML トークンに署名する必要があると判断される場合があります。 また、発行された SAML トークンのセキュリティ要求は、'' (パーツ参照承認の場合) または 'https://schemas.contoso.com/claims/lookuphttps://schemas.contoso.com/claims/order' (パーツの順序付け承認の場合) のいずれかであると判断できます。
  • Fabrikam の従業員が内部パーツ注文アプリケーションを使用すると、最初に Fabrikam 内のセキュリティ トークン サービス (STS) に連絡します。 その従業員は、内部の Fabrikam セキュリティ メカニズム (Windows ドメインのユーザー名/パスワードなど) を使用して認証され、パーツの注文に対する承認が検証され、適切な要求を含む有効期間の短い SAML トークンが発行され、上記で決定した X.509 証明書によって署名されます。 その後、パーツ注文アプリケーションは、発行された SAML トークンを提示する Contoso サービスに連絡して、注文タスクを認証して実行します。

ここで、Fabrikam STS は "発行元" として機能し、Contoso パーツ サービスは "証明書利用者" として機能します。 フェデレーションの発行元パーティと証明書利用者を示す図。

フェデレーション機能

フェデレーション シナリオに関係する関係者またはロールに対してサポートされているセキュリティ機能を次に示します。

  • クライアント側: STS からセキュリティ トークンを取得するために、 WsRequestSecurityToken 関数を 使用できます。 または、CardSpace や LiveID などのクライアント側のセキュリティ トークン プロバイダー ライブラリを使用し、その出力を使用して WsCreateXmlSecurityToken を使用してセキュリティ トークンをローカルに作成することもできます。 どちらの方法でも、クライアントがセキュリティ トークンを取得したら、チャネルを保護するための WS_SSL_TRANSPORT_SECURITY_BINDING などのトランスポート セキュリティ バインディングと共に、トークンを提示する WS_XML_TOKEN_MESSAGE_SECURITY_BINDING を指定するチャネルをサービスに作成できます。
  • サーバー側: SAML トークンを発行するセキュリティ トークン サービスとのフェデレーション シナリオでは、サーバーはチャネルを保護するために WS_SSL_TRANSPORT_SECURITY_BINDINGなどのトランスポート セキュリティ バインディングと共に 、WS_SAML_MESSAGE_SECURITY_BINDING を使用できます。
  • STS 側: STS は Web サービス アプリケーションであり、他のセキュリティで保護された Web サービスと同様に、リスナー作成時に セキュリティ記述 構造を使用して、セキュリティ トークンを要求するユーザーのセキュリティ要件を指定できることに注意してください。 その後、受信要求メッセージ ペイロードを解析してトークン要求を検証し、発行されたトークンを応答メッセージ ペイロードとして返送できます。 現時点では、これらの解析と発行の手順に役立つ機能は提供されていません。

クライアント側では、トークンの種類を知ったり、トークンの種類固有の処理を行ったりすることなく、発行されたセキュリティ トークンを XML セキュリティ トークンとして汎用的に処理できることに注意してください。 ただし、サーバーは特定のセキュリティ トークンの種類を理解して処理する必要があります。 セキュリティ トークンの要求と応答の手順では、WS-Trust仕様で定義されているコンストラクトを使用します。

より複雑なフェデレーション シナリオ

フェデレーション シナリオには、フェデレーション チェーンを形成する複数の STS が含まれる場合があります。 次の例を確認してください。

  • クライアントは、LiveID ユーザー名/パスワードを使用して LiveID STS に対して認証を行い、セキュリティ トークン T1 を取得します。
  • クライアントは T1 を使用して STS1 に対して認証を行い、セキュリティ トークン T2 を取得します。
  • クライアントは T2 を使用して STS2 に対して認証を行い、セキュリティ トークン T3 を取得します。
  • クライアントは T3 を使用してターゲット サービス S に対して認証を行います。

ここで、LiveID STS、STS1、STS2、S はフェデレーション チェーンを形成します。 フェデレーション チェーン内の STS は、アプリケーション シナリオ全体でさまざまな役割を果たしている場合があります。 このような STS 機能ロールの例としては、ID プロバイダー、承認の意思決定者、匿名化、リソース マネージャーなどがあります。

STS 要求パラメーターとメタデータ交換

クライアントが WsRequestSecurityToken 呼び出しを成功させるには、その呼び出しのパラメーター (必要なトークンの種類や要求の種類など)、STS への要求チャネルの セキュリティ記述 要件、STS の エンドポイント アドレス を把握する必要があります。 クライアント アプリケーションでは、この情報を決定するために次のいずれかの手法を使用できます。

  • 設計時の決定の一環として、アプリケーション内の情報をハード コーディングします。
  • この情報は、ローカル アプリケーション デプロイャーによって設定されたアプリケーション レベルの構成ファイルから読み取ります。
  • WS_ISSUED_TOKEN_MESSAGE_SECURITY_BINDING_CONSTRAINT構造の メタデータ インポート 機能を使用して、実行時にこの情報を動的 に 検出します。

フェデレーションでの動的 MEX の使用を示すために、上記の 3 つの STS の例を考えてみましょう。 クライアントは最初に S を使用して動的 MEX を実行し、T3 (STS2 から何を要求するか) と STS2 動的 MEX アドレス (STS2 を検索する場所) に関する情報を取得します。 その後、その情報を使用して、STS2 で動的 MEX を実行し、T2 や STS1 に関する情報を検出します。

したがって、動的 MEX ステップは、フェデレーション チェーンを構築するために順序 4、3、2、1 で行われ、トークン要求とプレゼンテーションステップは、フェデレーション チェーンをアンワインドするために順序 1、2、3、4 で行われます。

注意

Windows 7 および Windows Server 2008 R2: WWSAPI では、Lightweight Web Services Security Profile (LWSSP) で定義されている Ws-Trust と Ws-SecureConversation のみがサポートされます。 Microsoft の実装の詳細については、LWSSP の MESSAGE 構文 に関するセクションを参照してください。