Windows Communication Foundation (WCF) では、いくつかの方法でアクセスを制御できます。 このトピックでは、さまざまなメカニズムについて簡単に説明し、各メカニズムを使用するタイミングについて提案します。これは、使用する正しいメカニズムを選択するのに役立ちます。 アクセス テクノロジは、複雑さの順に一覧表示されます。 最も簡単なのは PrincipalPermissionAttributeです。最も複雑なのは ID モデルです。
これらのメカニズムに加えて、「委任と偽装」では、WCF での偽装 と委任について説明します。
PrincipalPermissionAttribute
PrincipalPermissionAttributeは、サービス メソッドへのアクセスを制限するために使用されます。 この属性をメソッドに適用すると、Windows グループまたは ASP.NET ロールの特定の呼び出し元の ID またはメンバーシップを要求するために使用できます。 クライアントが X.509 証明書を使用して認証される場合、サブジェクト名と証明書の拇印で構成されるプライマリ ID が付与されます。
PrincipalPermissionAttributeを使用して、サービスが実行されているコンピューター上のリソースへのアクセスを制御します。また、サービスのユーザーが常にサービスが実行されているのと同じ Windows ドメインに含まれるかどうかを制御します。 アクセス レベル (なし、読み取り専用、読み取り/書き込みなど) を指定した Windows グループを簡単に作成できます。
属性の使用方法の詳細については、「 方法: PrincipalPermissionAttribute クラスを使用してアクセスを制限する」を参照してください。 ID の詳細については、「サービス ID と認証」を参照してください。
ASP.NET メンバーシップ プロバイダー
ASP.NET の機能は、メンバーシップ プロバイダーです。 メンバーシップ プロバイダーは技術的にはアクセス制御メカニズムではありませんが、サービスのエンドポイントにアクセスできる可能性のある ID のセットを制限することで、サービスへのアクセスを制御できます。 メンバーシップ機能には、Web サイトのユーザーがサイトのアカウントを確立できるようにするユーザー名とパスワードの組み合わせを設定できるデータベースが含まれています。 メンバーシップ プロバイダーを使用するサービスにアクセスするには、ユーザーが自分のユーザー名とパスワードでログオンする必要があります。
注
WCF サービスが承認目的でデータベースを使用するには、まず ASP.NET 機能を使用してデータベースを設定する必要があります。
既存の ASP.NET Web サイトのメンバーシップ データベースが既にあり、同じユーザーが同じユーザー名とパスワードで承認されたサービスを使用できるようにする場合は、メンバーシップ機能を使用することもできます。
WCF サービスでメンバーシップ機能を使用する方法の詳細については、「 方法: ASP.NET メンバーシップ プロバイダーを使用する」を参照してください。
ASP.NET ロール プロバイダー
ASP.NET のもう 1 つの機能は、ロールを使用して承認を管理できることです。 ASP.NET ロール プロバイダーを使用すると、開発者はユーザーのロールを作成し、各ユーザーをロールまたはロールに割り当てることができます。 メンバーシップ プロバイダーと同様に、ロールと割り当てはデータベースに格納され、ASP.NET ロール プロバイダーの特定の実装によって提供されるツールを使用して設定できます。 メンバーシップ機能と同様に、WCF 開発者はデータベース内の情報を使用して、ロールによってサービス ユーザーを承認できます。 たとえば、前述の PrincipalPermissionAttribute アクセス制御メカニズムと組み合わせてロール プロバイダーを使用できます。
既存の ASP.NET ロール プロバイダー データベースがあり、WCF サービスで同じルールとユーザー割り当てを使用する場合は、ASP.NET ロール プロバイダーを使用することもできます。
ロール プロバイダー機能の使用方法の詳細については、「 方法: サービスで ASP.NET ロール プロバイダーを使用する」を参照してください。
承認マネージャー
もう 1 つの機能は、Authorization Manager (AzMan) と ASP.NET ロール プロバイダーを組み合わせてクライアントを承認します。 ASP.NET が Web サービスをホストする場合、AzMan をアプリケーションに統合して、サービスへの承認が AzMan を通じて行われるようにすることができます。 ASP.NET ロール マネージャーには、アプリケーション ロールの管理、ロールのユーザーの追加と削除、ロール メンバーシップの確認を行うことができる API が用意されていますが、ユーザーが名前付きタスクまたは操作の実行を許可されているかどうかを照会することはできません。 AzMan を使用すると、個々の操作を定義し、それらをタスクに結合できます。 AZMan では、ロール チェックに加えて、ユーザーがタスクを実行できるかどうかを確認することもできます。 ロールの割り当てとタスクの承認は、アプリケーションの外部で構成することも、アプリケーション内でプログラムによって実行することもできます。 AzMan 管理 Microsoft 管理コンソール (MMC) スナップインを使用すると、管理者はロールが実行時に実行できるタスクを変更したり、各ユーザーのロールのメンバーシップを管理したりできます。
既存の AzMan インストールに既にアクセスでき、AzMan/ロール プロバイダーの組み合わせの機能を使用してサービス ユーザーを承認する場合は、AzMan と ASP.NET ロール プロバイダーを使用することもできます。
AzMan と ASP.NET ロール プロバイダーの詳細については、「 方法: ASP.NET 2.0 で Authorization Manager (AzMan) を使用する」を参照してください。 AzMan と WCF サービスのロール プロバイダーの使用方法の詳細については、「 方法: サービスで ASP.NET Authorization Manager ロール プロバイダーを使用する」を参照してください。
ID モデル
ID モデルは、クライアントを承認するための要求とポリシーを管理できる一連の API です。 ID モデルを使用すると、呼び出し元がサービスに対して自身を認証するために使用した資格情報に含まれるすべての要求を調べ、その要求をサービスのポリシーのセットと比較し、比較に基づいてアクセスを許可または拒否できます。
細かく制御する必要があり、アクセスを許可する前に特定の条件を設定する機能が必要な場合は、ID モデルを使用します。 たとえば、 PrincipalPermissionAttributeを使用する場合、条件は単にユーザーの ID が認証され、特定のロールに属していることです。 これに対し、ID モデルを使用すると、ユーザーが 18 歳以上で、ドキュメントの表示を許可される前に有効な運転免許証を所有している必要があることを示すポリシーを作成できます。
ID モデル要求ベースのアクセス制御を利用できる 1 つの例は、発行されたトークン シナリオでフェデレーション資格情報を使用する場合です。 フェデレーショントークンと発行済みトークンの詳細については、「 フェデレーショントークンと発行済みトークン」を参照してください。
ID モデルの詳細については、「ID モデルを使用 した要求と承認の管理」を参照してください。