セキュリティ アーキテクチャ

ここでは、Windows Communication Foundation (WCF) セキュリティ コンポーネントの機能を変更または拡張する際に使用できるさまざまな拡張ポイントについて説明します。これらの拡張ポイントを理解するには、WCF のセキュリティ アーキテクチャ全体を理解する必要があります。このトピックでは、WCF のセキュリティ アーキテクチャについて、そのコンポーネントとコンポーネント間の関係という観点から説明します。また、このセクションで後述する拡張ポイントがアーキテクチャ モデル全体にどのように組み込まれているかについても説明します。

WCF セキュリティ コンポーネントのスコープ

WCF セキュリティは、WCF アーキテクチャの複数のコンポーネントをカバーします。WCF におけるセキュリティの主な目標は、WCF フレームワーク上で構築されたアプリケーションの整合性、機密性、認証、承認、および監査の各機能を提供することです。WCF アーキテクチャでは、これらの機能が次のように分割されています。

• 転送セキュリティ - メッセージの機密性とデータ整合性を実現し、通信参加者の認証を行います。
• 承認 - 承認決定を行うためのフレームワークを提供します。
• 監査 - セキュリティ関連イベントを監査ログに記録します。

セキュリティ モードとこのドキュメントのスコープ

転送セキュリティは、次のセキュリティ モードのいずれかを使用して実行できます。

• トランスポート。3 つの通信セキュリティ機能はすべて、クライアントとサーバー間でのメッセージの転送に使用するトランスポートによって提供されます。
• メッセージ。転送セキュリティは SOAP メッセージ レベルでのみ提供されます。つまり、セキュリティは XML レベルの SOAP メッセージに直接適用されます。
• メッセージ資格情報付きトランスポート。トランスポート セキュリティはトランスポート層とメッセージ層の両方で実行されます。トランスポート層では、通信の機密性とデータ整合性を確保し、サービス認証を行います。メッセージ層では、クライアント認証を行います。

このドキュメントでは、これ以降、メッセージ セキュリティ モードに重点を置いていますが、メッセージ資格情報付きトランスポート モードにも適用できる情報もあります。具体的には、このドキュメントの中でクライアント認証に適用される部分は、メッセージ資格情報付きトランスポート モードにも当てはまります。メッセージ資格情報付きトランスポート モードでは、メッセージ層を使用してメッセージ モードと同様にクライアント認証を実行するからです。

承認および監査コンポーネントの説明は、すべてのセキュリティ モードに同様に適用されます。したがって、このドキュメントに記載されたこれらのコンポーネントに関連するすべての情報は、サポートされているすべてのセキュリティ モードに適用されます。

メッセージ セキュリティ モードの概念

WS-Security モデル

メッセージ セキュリティ モードの基盤は、WS-Security 仕様です。WS-Security 仕様では、SOAP メッセージへのセキュリティの適用を可能にするフレームワークが定義されています。仕様では、デジタル署名および暗号化と組み合わせたセキュリティ トークンを使用して、SOAP メッセージの保護と認証を行うメッセージ セキュリティ モデルが指定されています。仕様については、「Web Services Security (WS-Security)」を参照してください。

用語

セキュリティ トークンは、クレームをアサートします。セキュリティ トークンを使用して、認証シークレットまたは認証キーとセキュリティ ID 間のバインディングをアサートできます。

クレームは、エンティティ (名前、ID、グループ、キー、特権など) について、エンティティによって作成される宣言です。クレームを作成したエンティティをクレーム発行者と呼び、自身に関するクレームが作成されたエンティティをクレームのサブジェクトと呼びます。

クレーム発行者は、キーを使用してセキュリティ トークンの署名または暗号化を行うことで、そのセキュリティ トークン内のクレームを保証または承認できます。これにより、セキュリティ トークン内のクレームの認証を行うことができます。

メッセージ署名は、メッセージの作成元と整合性の検証に使用されます。また、メッセージ作成者がキーを認識していることを示す場合にもメッセージ署名が使用されます。通常、サードパーティによって発行されるこのキーは、セキュリティ トークン内のクレームを確認し、その ID (およびセキュリティ トークンによって表されるその他のクレーム) を、作成したメッセージにバインドするために使用します。

セキュリティ トークン

WS-Security では、さまざまな種類のセキュリティ トークンが定義されています。また、他のセキュリティ トークンの種類を独自に定義できる拡張性のあるモデルも提供されます。トークンの種類のすべての定義に、トークンの XML シリアル化が含まれます。これにより、トークンの表現をメッセージに直接追加できます。

WS-Security に定義されているセキュリティ トークンの種類の一部を以下に示します。

• ユーザー名トークン
• X.509 証明書トークン
• Kerberos トークン
• SAML トークン

トークンの使用方法は 4 つ定義されています。また、メッセージに添付されるトークンは必ずこれらのカテゴリのいずれかに分類されます。

• SignedSupporting
• SignedEndorsing
• SignedEncrypted
• EncryptedEndorsing

.NET Framework 3.0 では、クライアント メッセージは、同一種類のトークンを 1 つしか含むことができませんが、複数の種類のトークンを含むことができます。

.NET Framework 3.5 では、クライアント メッセージは複数の種類のトークンを含むことができるだけでなく、同一種類のトークンを複数含むこともできます。

この機能により、次のようなさまざまなシナリオが可能になります。

• インクリメンタルなクレーム送信。すべての操作が同じクレームのセットを要求するサービスがある一方、追加のクレームを必要とする操作を含むサービスもあります。操作ごとに別々に発行されたトークンを使用するのではなく、クライアントが以前に発効されたトークンでクレームのセットを取得している場合、別の操作を呼び出すとき、必要に応じて追加のクレームを、別に発行されたトークンを使って取得できます。
• 複数要因の認証。クライアントが操作の実行を許可される前に、複数の発行者から発行されたトークンやさまざまなクレーム セットを含む発行済みトークンを収集する必要がある場合、WCF では、発行済みトークンをトークンの 1 つの種類と見なすため、このシナリオでは、2 種類の発行済みサポート トークンをメッセージに含めることができるようになっている必要があります。

この方法でサービスを構成することはできません。サービスに含めることができるサポート トークンは 1 つだけです。

詳細な情報については、次のページを参照してください。 「方法 : 同じ型の複数のセキュリティ トークンを使用する」を参照してください。

WS-Security 実装

WS-Security はメッセージ セキュリティの基盤であるため、WCF の WS-Security 実装は、メッセージ セキュリティ モード全体の基礎となります。メッセージ セキュリティ モードの機能を拡張するには、WS-Security 実装のしくみを理解しておく必要があります。

WCF における WS-Security 実装では、以下を処理します。

• SOAP メッセージとの間でのセキュリティ トークンのシリアル化。
• セキュリティ トークンの認証。
• メッセージ署名の適用と検証。
• SOAP メッセージの暗号化と復号化。

WCF 拡張ポイントでは、最初の 2 つの項目をカスタマイズできます。既存のセキュリティ トークンのシリアル化を変更したり、WCF セキュリティで既存のセキュリティ トークンを認証する方法を変更したりできます。また、WCF セキュリティにセキュリティ トークンの新しい種類を導入し、シリアル化や認証機能を含めることもできます。

以降の各トピックでは、WS-Security 実装の拡張ポイントを使用して、セキュリティ トークンの機能をカスタマイズする方法について説明します。

承認

セキュリティ トークンは、受信メッセージから逆シリアル化され、認証されます。認証プロセスにより、一連の承認ポリシー オブジェクトが作成されます。各オブジェクトは、セキュリティ トークンのデータの一部を表します。このデータは、承認ステージで使用されます。

承認ポリシーによって、特定のセキュリティ トークンが表すクレーム セットが作成されます。このクレーム セットは、ServiceAuthorizationManager と AuthorizationContext プロパティ内のロジックに提供され、承認決定に使用されます。

ID

クレームに加え、WCF は、(.NET Framework セキュリティ モデルによって作成された) 既存のインフラストラクチャに対して呼び出し元を表す IIdentity インターフェイスの実装を作成します 。この IIdentity インスタンスは、セキュリティ トークンが Windows アカウントに割り当てられている場合は呼び出し元の Windows ID を表し、それ以外の場合は呼び出し元の名前を含むプライマリ ID を表します。これらの ID には、ServiceSecurityContext を使用してアクセスすることもできます (詳細な情報については、次のページを参照してください。 「方法 : セキュリティ コンテキストを調べる」を参照してください)。次の方法のいずれかを使用すると、WCF で ID を作成する方法をカスタマイズできます。

• SecurityTokenAuthenticator クラスのカスタム拡張機能を実装する。
• MembershipProvider クラスを拡張するか、カスタムの IAuthorizationPolicy 実装を作成して ServiceAuthorizationManager にプラグインすることにより、ASP.NET と統合する。
• カスタムの IAuthorizationPolicy を作成する。

カスタム メンバシップ プロバイダが機能するのは、呼び出し元の認証にユーザー名/パスワード認証を使用する場合だけです。MembershipProvider は、ユーザー名とパスワードの組み合わせを検証します 。この組み合わせが有効であれば、WCF は、MembershipProvider による検証の後に、認証済みの呼び出し元を表すプライマリ ID を作成します。

既存の .NET Framework セキュリティ インフラストラクチャとの統合を容易にするために、WCF では、CurrentPrincipal プロパティは、呼び出し元を表す IPrincipal インスタンスに既定で設定されます。IPrincipal インスタンスは、生成された IIdentity に含まれる情報に基づいて作成されます。

ASP.NET の RoleProvider と統合することにより、IIdentity をさらに拡張できます。RoleProvider によって、呼び出し元が属するロールのセットが追加されます。承認ロジックは、この情報を利用してアクセス決定を行います。

ID 詳細については、 、「サービス ID と認証」を参照してください。

セキュリティで保護されたメッセージの送信

次の図は、メッセージ セキュリティ モードの使用時に、クライアント側でメッセージがセキュリティ保護されるしくみを示します。この図は、関与するコンポーネントとコンポーネント間の関係を示しています。

1. アプリケーション コードが実行され、メッセージが生成されます。
2. トークンの準備ステージで、クライアント資格情報 (X.509 証明書など) が添付されます。フェデレーション シナリオでは、資格情報を提供するためにトークン発行者に連絡します。
3. 資格情報を使用して、セキュリティ トークンが作成されます。
4. トークン認証ステージで、トークンが検証されます。
5. 最後に、セキュリティ トークンがシリアル化され、送信されます。

セキュリティで保護されたメッセージの受信

次の図は、受信側でセキュリティで保護されたメッセージをネットワークから取り出し、検証するときに発生するプロセスを示します。

1. セキュリティ トークンが逆シリアル化され、トークン認証ステージで処理されます。必要に応じて、この時点で ASP.NET メンバシップ プロバイダを使用してユーザー名とパスワードを指定できます。
2. 認証後、承認ポリシーが抽出されます。
3. 承認ポリシーの評価ステージでは、承認ポリシーが評価され、クレームを評価コンテキストに追加できます。この時点で、外部承認ポリシーも使用されます。次の手順と同様に、この手順は ServiceAuthorizationManager のメソッドによって実行されます。
4. サービス承認ステージでは、承認ポリシーによって追加されたクレームに基づいて、適切な承認が与えられます。この手順は、ServiceAuthorizationManager のメソッドによって実行されます。
5. 呼び出し元が偽装を許可しており、サービス メソッドが偽装を要求した場合、またはサービス承認動作で ImpersonateCallerForAllOperations プロパティが設定されている場合は、承認が行われた後に呼び出し元の偽装が行われます。詳細な情報については、次のページを参照してください。 「WCF の委任と偽装」を参照してください。
6. この時点で、WCF は、資格情報を使用して PrincipalPermission を生成します。また、必要に応じて、この時点で ASP.NET ロール プロバイダを使用できます。
7. アプリケーション コードが実行されます。

セキュリティ拡張ポイントの概要

次の図は、WCF セキュリティ コンポーネントで提供される拡張ポイントを示します。この図は、メッセージ処理の中で拡張ポイントに到達した時点に基づいて、4 つのカテゴリに分かれています。前の 2 つのセクションで説明したように、これらのカテゴリはメッセージ セキュリティ処理の各ステージに対応します。また、この図は、既存のインフラストラクチャ テクノロジを WCF セキュリティと統合できることも示しています。

関連項目

リファレンス

PrincipalPermission
ServiceAuthorizationManager
ServiceSecurityContext

概念

Windows Communication Foundation のアーキテクチャ
WCF の委任と偽装

その他の技術情報

カスタム資格情報と資格情報の検証