サービスのセキュリティ保護Securing Services

Windows Communication Foundation (WCF) サービスのセキュリティは、転送セキュリティと承認という2つの主要な要件で構成されています。Security of a Windows Communication Foundation (WCF) service consists of two primary requirements: transfer security and authorization. (セキュリティイベントの監査の3番目の要件については、「監査」を参照してください)。簡単に言えば、転送セキュリティには、認証 (サービスとクライアントの両方の id の確認)、機密性 (メッセージの暗号化)、整合性 (改ざんを検出するためのデジタル署名) などがあります。(A third requirement, auditing of security events, is described in Auditing.) In brief, transfer security includes authentication (verifying the identity of both the service and the client), confidentiality (message encryption), and integrity (digital signing to detect tampering). 承認は、たとえば、特権のあるユーザーだけがファイルを読み取ることができるなど、リソースへのアクセスを制御することです。Authorization is the control of access to resources, for example, allowing only privileged users to read a file. WCF の機能を使用すると、2つの主要な要件を簡単に実装できます。Using features of WCF, the two primary requirements are easily implemented.

@No__t-0 クラス (または構成の<basicHttpBinding >要素) を除き、すべての定義済みバインドに対して転送セキュリティが既定で有効になります。With the exception of the BasicHttpBinding class (or the <basicHttpBinding> element in configuration), transfer security is enabled by default for all of the predefined bindings. このセクションのトピックでは、2 つの基本的なシナリオ、インターネット インフォメーション サービス (IIS) でホストされるイントラネット サービス上で転送セキュリティと承認を実装するシナリオと、IIS でホストされるサービス上で転送セキュリティと承認を実装するシナリオについて説明します。The topics in this section cover two basic scenarios: implementing transfer security and authorization on an intranet service hosted on Internet Information Services (IIS), and implementing transfer security and authorization on a service hosted on IIS.

注意

Windows XP Home では、Windows 認証をサポートしていません。Windows XP Home does not support Windows authentication. このため、このシステムではサービスを実行しないでください。Therefore, you should not run a service on that system.

セキュリティの基礎Security Basics

セキュリティは、 資格情報に依存します。Security relies on credentials. 資格情報は、エンティティが本物であることを証明しますA credential proves that an entity is who it claims to be. (エンティティには、個人、ソフトウェアプロセス、会社、または承認可能なすべてのものを指定できます)。たとえば、サービスのクライアントがidクレームを作成し、資格情報が何らかの方法で要求を証明します。(An entity can be a person, a software process, a company, or anything that can be authorized.) For example, a client of a service makes a claim of identity, and the credential proves that claim in some manner. 通常のシナリオでは、資格情報の交換が行われます。In a typical scenario, an exchange of credentials occurs. 最初に、サービスがその ID のクレームを作成し、資格情報を使用してクライアントにそのクレームを証明します。First, a service makes a claim of its identity and proves it to the client with a credential. 次に、クライアントが ID のクレームを作成し、サービスに資格情報を提示します。Conversely, the client makes a claim of identity and presents a credential to the service. 両方がお互いの資格情報を信頼した場合、 セキュリティで保護されたコンテキスト を確立できます。このコンテキストでは、すべてのメッセージは機密性が保護された状態で交換され、すべてのメッセージはその整合性を保護するために署名されます。If both parties trust the other's credentials, then a secure context can be established in which all messages are exchanged in confidentiality, and all messages are signed to protect their integrity. サービスはクライアントの ID を確立した後で、クライアントの資格情報のクレームをグループの ロール または メンバーシップ に適合できます。After the service establishes the client's identity, it can then match the claims in the credential to a role or membership in a group. いずれの場合も、クライアントが属するロールまたはグループを使用して、サービスは、そのクライアントがロール特権またはグループ特権に基づいて限られた操作を実行することを 承認 します。In either case, using the role or the group to which the client belongs, the service authorizes the client to perform a limited set of operations based on the role or group privileges.

Windows セキュリティ機構Windows Security Mechanisms

クライアントとサービスのコンピューターが、両方がネットワークにログオンする必要がある Windows ドメインに存在する場合、資格情報は Windows インフラストラクチャによって提供されます。If the client and the service computer are both on a Windows domain that requires both to log on to the network, the credentials are provided by Windows infrastructure. この場合、コンピューターのユーザーがネットワークにログオンすると資格情報が確立されます。In that case, the credentials are established when a computer user logs on to the network. ネットワーク上の各ユーザーおよび各コンピューターは、信頼されたユーザーおよびコンピューターの集合に属することを検証される必要があります。Every user and every computer on the network must be validated as belonging to the trusted set of users and computers. Windows システムでは、このようなユーザーとコンピューターは、 セキュリティ プリンシパルとも呼ばれます。On a Windows system, every such user and computer is also known as a security principal.

Kerberos コントローラーによるサポートがある Windows ドメインでは、Kerberos コントローラーは、チケットを各セキュリティ プリンシパルに付与することをベースにしたスキームを使用します。On a Windows domain backed by a Kerberos controller, the Kerberos controller uses a scheme based on granting tickets to each security principal. コントローラーによって付与されたチケットは、システムの他のチケット付与システムによって信頼されます。The tickets the controller grants are trusted by other ticket granters in the system. エンティティが何らかの操作を実行しようとしたり、コンピューター上のファイルやディレクトリなどの リソース にアクセスしようとしたりすると、その都度チケットの有効性が検査され、検査に合格した場合、プリンシパルに操作用の別のチケットが付与されます。Whenever an entity tries to perform some operation or access a resource (such as a file or directory on a machine), the ticket is examined for its validity and, if it passes, the principal is granted another ticket for the operation. このチケットの付与方法は、操作ごとにプリンシパルを検証する方法よりも効率的です。This method of granting tickets is more efficient than the alternative of trying to validate the principal for every operation.

Windows ドメインで従来より使用されている安全性が低い機構に、NT LAN Manager (NTLM) があります。An older, less-secure mechanism used on Windows domains is NT LAN Manager (NTLM). Kerberos を使用できない場合 (通常、ワークグループなどの Windows ドメインの外部)、代わりに NTLM を使用できます。In cases where Kerberos cannot be used (typically outside of a Windows domain, such as in a workgroup), NTLM can be used as an alternative. NTLM は、IIS のセキュリティ オプションとしても使用できます。NTLM is also available as a security option for IIS.

Windows システムでは、各コンピューターとユーザーにロールとグループのセットを割り当てることによって承認が機能します。On a Windows system, authorization works by assigning each computer and user to a set of roles and groups. たとえば、各 Windows コンピューターは、 管理者のロールに属するユーザー (またはユーザー グループ) がセットアップし、管理する必要があります。For example, every Windows computer must be set up and controlled by a person (or group of people) in the role of the administrator. もう 1 つのロールは、 ユーザーのロールです。このロールのアクセス許可は、管理者ロールより制限されます。Another role is that of the user, which has a much more constrained set of permissions. ロール以外に、ユーザーはグループにも割り当てられます。In addition to the role, users are assigned to groups. グループによって、複数のユーザーが同じロールで動作できます。A group allows multiple users to perform in the same role. このため、実際 Windows コンピューターは、ユーザーをグループに割り当てることによって管理されます。In practice, therefore, a Windows machine is administered by assigning users to groups. たとえば、複数のユーザーをコンピューターのユーザー グループに割り当て、限られた人数のユーザーを管理者グループに割り当てることができます。For example, several users can be assigned to the group of users of a computer, and a much more constrained set of users can be assigned to the group of administrators. ローカル コンピューターでは、管理者は新しいグループを作成して、他のユーザー (または他のグループ) をそのグループに割り当てることもできます。On a local machine, an administrator can also create new groups and assign other users (or even other groups) to the group.

Windows を実行しているコンピューターでは、ディレクトリの各フォルダーを保護できます。On a computer running Windows, every folder in a directory can be protected. つまり、フォルダーを選択して、そのフォルダーのファイルにアクセスできるユーザー、およびそのユーザーがファイルのコピー、ファイルの変更 (最大限の特権が与えられている場合)、ファイルの削除、またはフォルダーへのファイルの追加を実行できるかどうかを制御できます。That is, you can select a folder and control who can access the files, and whether or not they can copy the file, or (in the most privileged case) change a file, delete a file, or add files to the folder. これは、アクセス制御と呼ばれ、その機構はアクセス制御リスト (ACL) と呼ばれます。This is known as access control, and the mechanism for it is known as the access control list (ACL). ACL を作成するとき、アクセス権を 1 つまたは複数のグループおよびドメインの個別のメンバーに割り当てることができます。When creating the ACL, you can assign access privileges to any group or groups, as well as individual members of a domain.

WCF インフラストラクチャは、これらの Windows セキュリティ機構を使用するように設計されています。The WCF infrastructure is designed to use these Windows security mechanisms. したがって、イントラネットに展開するサービスを作成していて、そのクライアントを Windows ドメインのメンバーに限定する場合、セキュリティを簡単に実装できます。Therefore, if you are creating a service that is deployed on an intranet, and whose clients are restricted to members of the Windows domain, security is easily implemented. 有効なユーザーだけがドメインにログオンできます。Only valid users can log on to the domain. ログオン後、Kerberos コントローラーによって、各ユーザーは他のコンピューターまたはアプリケーションとの間にセキュリティで保護されたコンテキストを確立できます。After users are logged on, the Kerberos controller enables each user to establish secure contexts with any other computer or application. ローカル コンピューターでは、グループを簡単に作成でき、特定のフォルダーを保護する場合、そのグループを使用してローカル コンピューター上でアクセス権を割り当てることができます。On a local machine, groups can be easily created, and when protecting specific folders, those groups can be used to assign access privileges on the computer.

イントラネット サービスでの Windows セキュリティの実装Implementing Windows Security on Intranet Services

Windows ドメインでのみ実行するアプリケーションをセキュリティで保護するには、 WSHttpBinding または NetTcpBinding バインディングの既定のセキュリティ設定を使用できます。To secure an application that runs exclusively on a Windows domain, you can use the default security settings of either the WSHttpBinding or the NetTcpBinding binding. 既定では、同じ Windows ドメインのすべてのユーザーが WCF サービスにアクセスできます。By default, anyone on the same Windows domain can access WCF services. ドメイン内にいるユーザーは、ネットワークにログオン済みなので信頼できます。Because those users have logged on to the network, they are trusted. サービスとクライアントの間で交換されるメッセージは、機密性を保護するために暗号化され、整合性を保護するために署名されます。The messages between a service and a client are encrypted for confidentiality and signed for integrity. Windows セキュリティを使用するサービスを作成する方法の詳細については、「方法: Windows 資格情報を使用してサービスをセキュリティで保護する」を参照してください。For more information about how to create a service that uses Windows security, see How to: Secure a Service with Windows Credentials.

PrincipalPermissionAttribute クラスを使用した承認Authorization Using the PrincipalPermissionAttribute Class

コンピューター上のリソースへのアクセスを制限する必要がある場合、最も簡単な方法は PrincipalPermissionAttribute クラスを使用することです。If you need to restrict the access of resources on a computer, the easiest way is to use the PrincipalPermissionAttribute class. この属性を使用すると、ユーザーが指定の Windows グループまたはロールに属しているか、特定のユーザーであることを要求して、サービス操作の呼び出しを制限できます。This attribute enables you to restrict the invocation of service operations by demanding that the user be in a specified Windows group or role, or to be a specific user. 詳細については、「方法: PrincipalPermissionAttribute クラスを使用してアクセスを制限する」を参照してください。For more information, see How to: Restrict Access with the PrincipalPermissionAttribute Class.

偽装Impersonation

偽装は、リソース アクセスの制御に使用できるもう 1 つの機構です。Impersonation is another mechanism that you can use to control access to resources. 既定では、IIS でホストされるサービスは、ASPNET アカウントの ID で実行されます。By default, a service hosted by IIS will run under the identity of the ASPNET account. ASPNET アカウントは、アクセス許可のあるリソースにだけアクセスできます。The ASPNET account can access only the resources for which it has permission. ただし、ASPNET サービス アカウントを除外し、他の特定の ID によるフォルダーへのアクセスを許可するように ACL を設定できます。However, it is possible to set the ACL for a folder to exclude the ASPNET service account, but allow certain other identities to access the folder. ここで問題となるのが、ASPNET アカウントがフォルダーにアクセスできない場合に、他のユーザーがフォルダーにアクセスできるようにする方法です。The question then becomes how to allow those users to access the folder if the ASPNET account is not allowed to do so. これは、偽装を使用することで解決できます。偽装によって、サービスは特定のリソースにアクセスするためにクライアントの資格情報を使用できます。The answer is to use impersonation, whereby the service is allowed to use the credentials of the client to access a particular resource. もう 1 つの例は、特定のユーザーだけがアクセス許可を持つ SQL Server データベースにアクセスする場合です。Another example is when accessing a SQL Server database to which only certain users have permission. 偽装の使用方法の詳細については、「方法: サービスでクライアントを偽装する」および「委任と偽装」を参照してください。For more information about using impersonation, see How to: Impersonate a Client on a Service and Delegation and Impersonation.

インターネット上のセキュリティSecurity on the Internet

インターネット上のセキュリティは、イントラネット上のセキュリティと同じ要件で構成されます。Security on the Internet consists of the same requirements as security on an intranet. サービスは、信頼性を証明するために資格情報を提示する必要があり、クライアントは、サービスに対して ID を証明する必要があります。A service needs to present its credentials to prove its authenticity, and clients need to prove their identity to the service. クライアントの ID が証明されると、サービスは、クライアントによるリソースへのアクセスを制御できます。Once a client's identity is proven, the service can control how much access the client has to resources. ただし、インターネットではさまざまな種類が混在しているので、提示される資格情報は、Windows ドメインで使用される資格情報とは異なります。However, due to the heterogeneous nature of the Internet, the credentials presented differ from those used on a Windows domain. Kerberos コントローラーが資格情報のチケットを使用して、ドメインでユーザーの認証を処理するのに対し、インターネットでは、サービスとクライアントは、資格情報を提示するための複数の異なる方法のいずれかに依存します。Whereas a Kerberos controller handles the authentication of users on a domain with tickets for credentials, on the Internet, services and clients rely on any one of several different ways to present credentials. ただし、このトピックの目的は、インターネット上でアクセス可能な WCF サービスを作成できるようにするための一般的なアプローチを提供することです。The objective of this topic, however, is to present a common approach that enables you to create a WCF service that is accessible on the Internet.

IIS と ASP.NET の使用Using IIS and ASP.NET

インターネット セキュリティの要件、およびその問題を解決するための機構は、新しいものではありません。The requirements of Internet security, and the mechanisms to solve those problems, are not new. IIS は、マイクロソフトのインターネット用 Web サーバーであり、これらの問題に対処する多くのセキュリティ機能を備えています。さらに、ASP.NET には、WCF サービスで使用できるセキュリティ機能が含まれています。IIS is Microsoft's Web server for the Internet and has many security features that address those problems; in addition, ASP.NET includes security features that WCF services can use. これらのセキュリティ機能を利用するには、IIS で WCF サービスをホストします。To take advantage of these security features, host an WCF service on IIS.

ASP.NET メンバーシップとロール プロバイダーの使用Using ASP.NET Membership and Role Providers

ASP.NET には、メンバーシップとロール プロバイダーが用意されています。ASP.NET includes a membership and role provider. プロバイダーは、呼び出し元を認証するためのユーザー名とパスワードの組み合わせのデータベースであり、これによって、各呼び出し元のアクセス特権を指定することもできます。The provider is a database of user name/password pairs for authenticating callers that also allows you to specify each caller's access privileges. WCF では、構成によって既存のメンバーシップとロールプロバイダーを簡単に使用できます。With WCF, you can easily use a pre-existing membership and role provider through configuration. この機能を示すサンプル アプリケーションについては、「 メンバーシップとロール プロバイダー 」のサンプルを参照してください。For a sample application that demonstrates this, see the Membership and Role Provider sample.

IIS で使用する資格情報Credentials Used by IIS

Kerberos コントローラーによるサポートがある Windows ドメインとは異なり、インターネットには、随時ログオンしている多数のユーザーを管理するための共通のコントローラーがありません。Unlike a Windows domain backed by a Kerberos controller, the Internet is an environment without a single controller to manage the millions of users logging on at any time. 代わりに、インターネットの資格情報は、ほとんどの場合、X.509 証明書 (SSL (Secure Sockets Layer) 証明書とも呼ばれる) の形で提示されます。Instead, credentials on the Internet most often are in the form of X.509 certificates (also known as Secure Sockets Layer, or SSL, certificates). この証明書は、通常、 証明機関によって発行されます。この証明機関は、証明書の信頼性を保証するサードパーティの企業および証明書が発行された個人です。These certificates are typically issued by a certification authority, which can be a third-party company that vouches for the authenticity of the certificate and the person it has been issued to. インターネット上にサービスを公開するには、このような信頼された証明書を提供して、サービスを認証する必要があります。To expose your service on the Internet, you must also supply such a trusted certificate to authenticate your service.

それでは、どのように信頼された証明書を取得するのでしょうか。The question arises at this point, how do you get such a certificate? その方法の 1 つは、サービスを展開する準備とそのサービスの証明書を購入する準備ができたら、Authenticode、VeriSign などのサードパーティ証明機関に連絡する方法です。One approach is to go to a third-party certification authority, such as Authenticode or VeriSign, when you are ready to deploy your service, and purchase a certificate for your service. ただし、WCF を使用した開発フェーズで、証明書の購入をコミットする準備ができていない場合、運用環境のデプロイをシミュレートするために使用できる x.509 証明書を作成するためのツールと手法が用意されています。However, if you are in the development phase with WCF and not yet ready to commit to purchasing a certificate, tools and techniques exist for creating X.509 certificates that you can use to simulate a production deployment. 詳細については、「証明書の使用」を参照してください。For more information, see Working with Certificates.

セキュリティ モードSecurity Modes

WCF セキュリティのプログラミングには、いくつかの重要な決定事項が伴います。Programming WCF security entails a few critical decision points. 最も基本的な決定の 1 つは、 セキュリティ モードを選択することです。One of the most basic is the choice of security mode. 2 つの主要なセキュリティ モードとして、 トランスポート モードメッセージ モードがあります。The two major security modes are transport mode and message mode.

3 番目のモードは、2 つの主要モードのセマンティクスを組み合わせたもので、 メッセージ資格情報付きトランスポート モードです。A third mode, which combines the semantics of both major modes, is transport with message credentials mode.

セキュリティ モードによって、メッセージをセキュリティで保護する方法が決まります。それぞれのモードには、次に示す利点と欠点があります。The security mode determines how messages are secured, and each choice has advantages and disadvantages, as explained below. セキュリティモードの設定の詳細については、「方法: セキュリティモードを設定する」を参照してください。For more information about setting the security mode, see How to: Set the Security Mode.

トランスポート モードTransport Mode

ネットワークとアプリケーションの間には複数の層があります。There are several layers between the network and the application. この層の 1 つが トランスポート 層で、エンドポイント間のメッセージ転送を管理します 。One of these is the transport layer , which manages the transfer of messages between endpoints. 現時点では、WCF では複数のトランスポートプロトコルが使用されており、それぞれがメッセージの転送をセキュリティで保護できることを理解しておく必要があります。For the present purpose, it is only required that you understand that WCF uses several transport protocols, each of which can secure the transfer of messages. (トランスポートの詳細については、「トランスポート」を参照してください)。(For more information about transports, see Transports.)

一般的に使用されるプロトコルは HTTP ですが、その他にも TCP があります。A commonly used protocol is HTTP; another is TCP. この各プロトコルは、プロトコルに固有の機構によってメッセージ転送をセキュリティで保護できます。Each of these protocols can secure message transfer by a mechanism (or mechanisms) particular to the protocol. たとえば、HTTP プロトコルは SSL over HTTP (一般的に "HTTPS" と省略される) を使用してセキュリティで保護されます。For example, the HTTP protocol is secured using SSL over HTTP, commonly abbreviated as "HTTPS." そのため、セキュリティのトランスポート モードを選択するときは、同時に、プロトコルによって指定された機構の使用を選択することになります。Thus, when you select the transport mode for security, you are choosing to use the mechanism as dictated by the protocol. たとえば、 WSHttpBinding クラスを選択し、そのセキュリティ モードをトランスポートに設定した場合、セキュリティ機構として SSL over HTTP (HTTPS) を選択することになります。For example, if you select the WSHttpBinding class and set its security mode to Transport, you are selecting SSL over HTTP (HTTPS) as the security mechanism. トランスポート モードの利点は、セキュリティが比較的低いレベルで統合されるので、メッセージ モードよりも効率的であるという点です。The advantage of the transport mode is that it is more efficient than message mode because security is integrated at a comparatively low level. トランスポート モードを使用するとき、トランスポートの仕様に基づいてセキュリティ機構を実装する必要があります。これによって、トランスポートを経由した Point-to-Point からのみメッセージを安全にフローできます。When using transport mode, the security mechanism must be implemented according to the specification for the transport, and thus messages can flow securely only from point-to-point over the transport.

メッセージ モードMessage Mode

一方、メッセージ モードでは、セキュリティ データを各メッセージの一部として追加することによってセキュリティを提供します。In contrast, message mode provides security by including the security data as part of every message. XML および SOAP のセキュリティ ヘッダーを使用して、メッセージの整合性と機密性を確保するために必要な資格情報とその他のデータを各メッセージに追加します。Using XML and SOAP security headers, the credentials and other data needed to ensure the integrity and confidentiality of the message are included with every message. 各メッセージにはセキュリティ データが追加され、各メッセージを個別に処理する必要があるので、パフォーマンスが犠牲になりますEvery message includes security data, so it results in a toll on performance because each message must be individually processed. (トランスポートモードでは、トランスポート層がセキュリティで保護されると、すべてのメッセージが自由にフローされます)。ただし、メッセージセキュリティは、トランスポートセキュリティよりも1つの利点があります。これは、より柔軟です。(In transport mode, once the transport layer is secured, all messages flow freely.) However, message security has one advantage over transport security: it is more flexible. つまり、セキュリティ要件はトランスポートによって決定されません。That is, the security requirements are not determined by the transport. メッセージをセキュリティで保護するために、任意の種類のクライアント資格情報を使用できますYou can use any type of client credential to secure the message. (トランスポート モードでは、トランスポート プロトコルによって、使用できるクライアント資格情報の種類が決まります)。(In transport mode, the transport protocol determines the type of client credential that you can use.)

メッセージ資格情報付きトランスポートTransport with Message Credentials

3 番目のモードは、トランスポート セキュリティとメッセージ セキュリティの利点を組み合わせています。The third mode combines the best of both transport and message security. このモードでは、トランスポート セキュリティを使用して、各メッセージの機密性と整合性を効率的に確保できます。In this mode, transport security is used to efficiently ensure the confidentiality and integrity of every message. 同時に、各メッセージには、その資格情報データが追加されるので、メッセージを認証できます。At the same time, every message includes its credential data, which allows the message to be authenticated. 認証と共に、承認も実装できます。With authentication, authorization can also be implemented. 送信者を認証することによって、送信者の ID に応じてリソースへのアクセスが許可または拒否されます。By authenticating a sender, access to resources can be granted (or denied) according to the sender's identity.

クライアント資格情報の種類と資格情報の値の指定Specifying the Client Credential Type and Credential Value

セキュリティ モードを選択した後で、必要に応じて、クライアント資格情報の種類を指定することもできます。After you have selected a security mode, you may also want to specify a client credential type. クライアント資格情報の種類では、サービスでの認証時にクライアントが使用する必要がある種類を指定します。The client credential type specifies what type a client must use to authenticate itself to the server.

ただし、すべてのシナリオにクライアント資格情報の種類が必要とは限りません。Not all scenarios require a client credential type, however. SSL over HTTP (HTTPS) を使用して、サービスはクライアントに対して認証を行います。Using SSL over HTTP (HTTPS), a service authenticates itself to the client. この認証の一部として、 ネゴシエーションと呼ばれるプロセスで、サービスの証明書がクライアントに送信されます。As part of this authentication, the service's certificate is sent to the client in a process called negotiation. SSL によってセキュリティで保護されたトランスポートによって、すべてのメッセージの機密性が確保されます。The SSL-secured transport ensures that all messages are confidential.

クライアントの認証が必要なサービスを作成している場合、クライアント資格情報の種類の選択肢は、選択したトランスポートとモードによって異なります。If you are creating a service that requires that the client be authenticated, your choice of a client credential type depends on the transport and mode selected. たとえば、HTTP トランスポートを使用して、トランスポート モードを選択する場合、基本、ダイジェストなどのいくつかの選択肢がありますFor example, using the HTTP transport and choosing transport mode gives you several choices, such as Basic, Digest, and others. (これらの資格情報の種類の詳細については、「 HTTP 認証について」を参照してください)。(For more information about these credential types, see Understanding HTTP Authentication.)

Windows ドメインで、そのネットワークの他のユーザーだけが利用できるサービスを作成している場合、最も使いやすいのは、Windows クライアント資格情報の種類です。If you are creating a service on a Windows domain that will be available only to other users of the network, the easiest to use is the Windows client credential type. ただし、場合によっては、サービスにも証明書を提供する必要があります。However, you may also need to provide a service with a certificate. 詳細については、「 How to: Specify Client Credential Values」を参照してください。This is shown in How to: Specify Client Credential Values.

資格情報の値Credential Values

資格情報の値 とは、サービスが使用する実際の資格情報です。A credential value is the actual credential the service uses. 資格情報の種類を指定したら、サービスを実際の資格情報で構成する必要があります。Once you have specified a credential type, you may also need to configure your service with the actual credentials. Windows を選択し、サービスを Windows ドメインで実行する場合は、実際の資格情報の値を指定しません。If you have selected Windows (and the service will run on a Windows domain), then you do not specify an actual credential value.

IdentityIdentity

WCF では、 idという用語はサーバーとクライアントに対して異なる意味を持ちます。In WCF, the term identity has different meanings to the server and the client. つまり、サービスを実行しているとき、ID は認証後にセキュリティ コンテキストに割り当てられます。In brief, when running a service, an identity is assigned to the security context after authentication. 実際の ID を表示するには、 WindowsIdentity クラスの PrimaryIdentity プロパティと ServiceSecurityContext プロパティを確認します。To view the actual identity, check the WindowsIdentity and PrimaryIdentity properties of the ServiceSecurityContext class. 詳細については、「方法: セキュリティコンテキストを調べる」を参照してください。For more information, see How to: Examine the Security Context.

反対に、クライアントでは、ID はサービスを検証するために使用されます。In contrast, on the client, identity is used to validate the service. 設計時に、クライアント開発者は<identity >要素をサービスから取得した値に設定できます。At design time, a client developer can set the <identity> element to a value obtained from the service. 実行時に、クライアントは、要素の値をサービスの実際の ID と照合してチェックします。At run time, the client checks the value of the element against the actual identity of the service. チェックが失敗した場合、クライアントは通信を終了します。If the check fails, the client terminates the communication. 特定のユーザー ID でサービスを実行している場合の値はユーザー プリンシパル名 (UPN) で、コンピューター アカウントでサービスを実行している場合の値はサービス プリンシパル名 (SPN) です。The value can be a user principal name (UPN) if the service runs under a particular user's identity or a service principal name (SPN) if the service runs under a machine account. 詳細については、「サービス id と認証」を参照してください。For more information, see Service Identity and Authentication. 資格情報には、証明書、つまり証明書を識別する証明書内のフィールドも使用できます。The credential could also be a certificate, or a field found on a certificate that identifies the certificate.

保護レベルProtection Levels

ProtectionLevel プロパティは、 ServiceContractAttribute クラス、 OperationContractAttribute クラスなどのいくつかの属性クラスで使用します。The ProtectionLevel property occurs on several attribute classes (such as the ServiceContractAttribute and the OperationContractAttribute classes). 保護レベルは、サービスをサポートするメッセージ (またはメッセージ部分) が署名されるのか、署名および暗号化されるのか、または署名と暗号化なしで送信されるのかを指定する値です。The protection level is a value that specifies whether the messages (or message parts) that support a service are signed, signed and encrypted, or sent without signatures or encryption. プロパティの詳細については、「保護レベルについて」およびプログラミング例については、「方法: ProtectionLevel プロパティを設定する」を参照してください。For more information about the property, see Understanding Protection Level, and for programming examples, see How to: Set the ProtectionLevel Property. @No__t-0 を使用してサービスコントラクトを設計する方法の詳細については、「サービスコントラクトの設計」を参照してください。For more information about designing a service contract with the ProtectionLevel in context, see Designing Service Contracts.

関連項目See also