Windows Communication Foundation のセキュリティ動作
Windows Communication Foundation (WCF) では、動作によって、サービス レベルまたはエンドポイント レベルで実行時の動作が変更されます (動作全般に関する詳細については、「サービスのランタイム動作の指定」を参照してください)。セキュリティ動作により、資格情報、認証、承認、および監査ログの制御が可能になります。 動作は、プログラムまたは構成を通じて使用できます。
この記事では、セキュリティ機能に関連する以下の動作の構成について説明します。
- <serviceCredentials>
- <clientCredentials>
- <serviceAuthorization>
- <serviceSecurityAudit>
- <serviceMetadata>。この要素を使用すると、クライアントがアクセスしてメタデータを取得できる、セキュリティで保護されたエンドポイントを指定することもできます。
動作を使用した資格情報の設定
<serviceCredentials> と <clientCredentials> を使用して、サービスまたはクライアントの資格情報の値を設定します。 基になるバインド構成によって、資格情報を設定する必要があるかどうかが決まります。 たとえば、セキュリティ モードが None に設定されている場合、クライアントとサービスは相互に認証を行わないため、どの種類の資格情報も必要ありません。
一方、サービス バインディングでは、クライアント資格情報の種類が必要になることがあります。 その場合は、動作を使用して資格情報の値を設定することが必要になる場合があります (使用可能な資格情報の種類については、「資格情報の種類の選択」を参照してください)。Windows 資格情報を使用して認証を行う場合などは、実際の資格情報の値が環境によって自動的に設定されるため、資格情報の別のセットを指定する場合を除き、資格情報の値を明示的に設定する必要がないこともあります。
すべてのサービス資格情報は、<serviceBehaviors> の子要素となっています。 サービス資格情報として使用される証明書を次の例に示します。
<configuration>
<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior name="ServiceBehavior1">
<serviceCredentials>
<serviceCertificate findValue="000000000000000000000000000"
storeLocation="CurrentUser"
storeName="Root" x509FindType="FindByThumbprint" />
</serviceCredentials>
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
</configuration>
サービス資格情報
<serviceCredentials> には、4 つの子要素が含まれています。 以下のセクションでは、これらの要素とそれぞれの使い方について説明します。
<serviceCertificate> 要素
メッセージ セキュリティ モードを使用しているクライアントへのサービスの認証に使用する X.509 証明書を指定するには、この要素を使用します。 定期的に更新される証明書を使用している場合は、証明書のサムプリントが変更されます。 その場合、証明書を同じサブジェクト名で再発行できるため、X509FindType としてサブジェクト名を使用します。
要素の使用の詳細については、「方法: クライアント資格情報の値を指定する」を参照してください。
<clientCertificate> 要素の <certificate>
<certificate> 要素は、サービスがクライアントと安全に通信するために、クライアントの証明書をあらかじめ持っている必要がある場合に使用します。 このような状況は、双方向通信パターンを使用する場合に生じます。 より一般的な要求/応答パターンでは、クライアントが自身の証明書を要求に含め、サービスはこの証明書を使用して、クライアントへの応答をセキュリティで保護します。 ただし、双方向通信パターンには要求も応答もありません。 サービスは、クライアントの証明書を通信から推測できないため、クライアントへのメッセージをセキュリティで保護するためにクライアントの証明書が前もって必要になります。 クライアントの証明書を帯域外方式で取得し、この要素を使用して証明書を指定する必要があります。 双方向サービスの詳細については、「方法: 双方向コントラクトを作成する」を参照してください。
<clientCertificate> 要素の <authentication>
<authentication> 要素を使用すると、クライアントを認証する方法をカスタマイズできます。 CertificateValidationMode 属性は、None、ChainTrust、PeerOrChainTrust、PeerTrust、または Custom に設定できます。 既定では、レベルが ChainTrust に設定されて、チェーンの最上位のルート証明機関で終了する証明書の階層構造で各証明書が見つかるように指定されます。 これは最もセキュリティで保護されているモードです。 また、値を PeerOrChainTrust に設定することもできます。これは、信頼されたチェーン内の証明書と共に、自己発行された証明書 (ピア信頼) も受け入れるよう指定します。 自己発行の資格情報は信頼された証明機関から購入したものである必要はないため、この値はクライアントとサービスの開発およびデバッグに使用されます。 クライアントを展開するときは、代わりに ChainTrust 値を使用します。 また、値を Custom に設定することもできます。 Custom 値に設定する場合は、CustomCertificateValidatorType 属性を、証明書の検証に使用するアセンブリと型に設定する必要もあります。 独自のカスタム検証を作成するには、抽象 X509CertificateValidator クラスを継承する必要があります。
<issuedTokenAuthentication> 要素
発行されるトークンのシナリオには、3 つの段階があります。 最初の段階では、サービスにアクセスしようとしているクライアントが、セキュリティ トークン サービス (STS) に差し向けられます。 次に、STS がクライアントを認証し、その後、クライアントにトークン (通常は、SAML (Security Assertions Markup Language) トークン) を発行します。 最後に、クライアントがトークンを持ってサービスに戻ります。 サービスはトークンを調べ、トークンを認証することでクライアントの認証を可能にするデータを確認します。 トークンを認証するには、セキュリティ トークン サービスで使用される証明書がサービスによって認識されている必要があります。 <issuedTokenAuthentication> 要素は、このようなセキュリティ トークン サービス証明書のリポジトリです。 証明書を追加するには、<knownCertificates> を使用します。 次の例に示すように、証明書ごとに <add> を挿入します。
<issuedTokenAuthentication>
<knownCertificates>
<add findValue="www.contoso.com"
storeLocation="LocalMachine" storeName="My"
X509FindType="FindBySubjectName" />
</knownCertificates>
</issuedTokenAuthentication>
既定では、証明書はセキュリティ トークン サービスから取得する必要があります。 このような "既知" の証明書により、正当なクライアントのみがサービスにアクセスできるようになります。
SamlSecurityToken セキュリティ トークンを発行するセキュリティ トークン サービス (STS) を使用するフェデレーション アプリケーション内の <allowedAudienceUris> コレクションを使用する必要があります。 STS がセキュリティ トークンを発行する場合、このセキュリティ トークンに SamlAudienceRestrictionCondition を追加して、セキュリティ トークンの提供先となる Web サービスの URI を指定できます。 これにより、受け取り側 SamlSecurityTokenAuthenticator Web サービスは、次のようにしてこのチェックが行われるように指定することで、発行されたセキュリティ トークンがこの Web サービスを対象としていることを確認できます。
<issuedTokenAuthentication> の
audienceUriMode属性をAlwaysまたはBearerKeyOnlyに設定します。このコレクションに URI を追加して、有効な URI のセットを指定します。 これを行うには、各 URI に <add> を挿入します。
詳細については、「SamlSecurityTokenAuthenticator」を参照してください。
この構成要素の使用の詳細については、「方法: フェデレーション サービスで資格情報を構成する」を参照してください。
匿名の CardSpace ユーザーの許可
AllowUntrustedRsaIssuers 要素の <IssuedTokenAuthentication> 属性を true に設定すると、任意の RSA キー ペアで署名された自己発行トークンを提示することがすべてのクライアントに明示的に許可されます。 このキーには、発行者のデータが関連付けられていないため、発行者は信頼されません。 CardSpace ユーザーは、ID の自己提供クレームを含む自己発行カードを作成できます。 この機能を使用するときは十分に注意してください。 この機能を使用する場合は、RSA 公開キーを、ユーザー名と一緒にデータベースに格納する必要のある比較的安全なパスワードとして考えます。 サービスへのクライアント アクセスを許可する前に、クライアントから提示された RSA 公開キーを、提示されたユーザー名に対応する格納済みの公開キーと比較して検証します。 これは、ユーザーが各自のユーザー名を登録し、自己発行の RSA 公開キーに関連付けることができる登録プロセスが確立されていることが前提となります。
クライアントの資格情報
クライアント資格情報は、相互認証が必要な場合にサービスに対するクライアントの認証に使用されます。 また、このセクションを使用して、クライアントがサービスの証明書によってサービスへのメッセージをセキュリティで保護する必要がある場合に使用するサービス証明書を指定することもできます。
セキュリティ トークン サービスまたはローカル発行者から発行されたトークンを使用するフェデレーション シナリオの一部として、クライアントを構成することもできます。 フェデレーション シナリオの詳細については、「フェデレーションと発行済みトークン」を参照してください。 次のコードに示すように、すべてのクライアント資格情報は <endpointBehaviors> の下にあります。
<behaviors>
<endpointBehaviors>
<behavior name="EndpointBehavior1">
<clientCredentials>
<clientCertificate findValue="cn=www.contoso.com"
storeLocation="LocalMachine"
storeName="AuthRoot" x509FindType="FindBySubjectName" />
<serviceCertificate>
<defaultCertificate findValue="www.cohowinery.com"
storeLocation="LocalMachine"
storeName="Root" x509FindType="FindByIssuerName" />
<authentication revocationMode="Online"
trustedStoreLocation="LocalMachine" />
</serviceCertificate>
</clientCredentials>
</behavior>
</endpointBehaviors>
</behaviors>
<clientCertificate> 要素
この要素で、クライアントの認証に使用する証明書を設定します。 詳細については、「方法: クライアント資格情報の値を指定する」を参照してください。
<httpDigest>
この機能は、Windows の Active Directory およびインターネット インフォメーション サービス (IIS) と共に有効にする必要があります。 詳細については、「IIS 6.0 でのダイジェスト認証」を参照してください。
<issuedToken> 要素
<issuedToken> には、トークンのローカル発行者やセキュリティ トークン サービスで使用する動作の構成に使用する要素が含まれます。 ローカル発行者を使用するようにクライアントを構成する手順については、「方法: ローカル発行者を設定する」を参照してください。
<ocalIssuerAddress>
既定のセキュリティ トークン サービス アドレスを指定します。 これは、セキュリティ トークン サービスの URL を WSFederationHttpBinding が提供しない場合、またはフェデレーション バインディングの発行者アドレスが http://schemas.microsoft.com/2005/12/ServiceModel/Addressing/Anonymous または null の場合に使用されます。 そのような場合、ClientCredentials は、ローカルの発行者およびバインディングのアドレスと共に構成し、その発行者と通信するために使用する必要があります。
<issuerChannelBehaviors>
セキュリティ トークン サービスとの通信時に使用する WCF クライアントの動作を追加するには、<issuerChannelBehaviors> を使用します。 <endpointBehaviors> セクションでクライアントの動作を定義します。 定義された動作を使用するには、<add> 要素を <issuerChannelBehaviors> 要素に追加し、2 つの属性を設定します。 次の例に示すように、issuerAddress をセキュリティ トークン サービスの URL に設定し、behaviorConfiguration 属性を定義済みのエンドポイントの動作の名前に設定します。
<clientCredentials>
<issuedToken>
<issuerChannelBehaviors>
<add issuerAddress="http://www.contoso.com"
behaviorConfiguration="clientBehavior1" />
</issuerChannelBehaviors>
</issuedToken>
</clientCredentials>
<serviceCertificate> 要素
サービス証明書の認証を制御するには、この要素を使用します。
<defaultCertificate> 要素には、サービスで証明書が指定されていないときに使用する証明書を 1 つ格納できます。
特定のサービスに関連付けられているサービス証明書を設定するには、<scopedCertificates> と <add> を使用します。 <add> 要素には、証明書をサービスに関連付けるために使用する targetUri 属性があります。
<authentication> 要素は、証明書の認証に使用する信頼のレベルを指定します。 既定のレベルは "ChainTrust" に設定され、チェーンの最上位の信頼された証明機関で終了する証明書の階層構造で各証明書を検索するよう指定します。 これは最もセキュリティで保護されているモードです。 また、値を "PeerOrChainTrust" に設定することもできます。これは、信頼されたチェーン内の証明書と共に、自己発行された証明書 (ピア信頼) も受け入れることを指定します。 自己発行の資格情報は信頼された証明機関から購入したものである必要はないため、この値はクライアントとサービスの開発およびデバッグに使用されます。 クライアントを展開するときは、代わりに "ChainTrust" 値を使用します。 値を "Custom" または "None" に設定できます。"Custom" 値を使用するには、CustomCertificateValidatorType 属性も証明書の検証に使用するアセンブリと型に設定する必要があります。 独自のカスタム検証を作成するには、抽象 X509CertificateValidator クラスを継承する必要があります。 詳細については、「方法: カスタム証明書検証を使用するサービスを作成する」を参照してください。
<authentication> 要素には、証明書が失効していないかどうかをチェックする方法を指定する RevocationMode 属性が含まれます。 既定値は "online" です。この場合、証明書が失効していないかどうかが自動的にチェックされます。 詳細については、「証明書の使用」を参照してください。
ServiceAuthorization
<serviceAuthorization> 要素には、認可、カスタム ロール プロバイダー、および偽装に影響する要素が含まれます。
PrincipalPermissionAttribute クラスは、サービス メソッドに適用されます。 この属性は、保護メソッドの使用を承認するときに使用するユーザー グループを指定します。 既定値は "UseWindowsGroups" で、リソースにアクセスしようとしている ID を Windows グループ ("管理者" や "ユーザー" など) で検索するよう指定します。 次のコードに示すように、"UseAspNetRoles" を指定して、<system.web> 要素の下で構成されるカスタム ロール プロバイダーを使用することもできます。
<system.web>
<membership defaultProvider="SqlProvider"
userIsOnlineTimeWindow="15">
<providers>
<clear />
<add
name="SqlProvider"
type="System.Web.Security.SqlMembershipProvider"
connectionStringName="SqlConn"
applicationName="MembershipProvider"
enablePasswordRetrieval="false"
enablePasswordReset="false"
requiresQuestionAndAnswer="false"
requiresUniqueEmail="true"
passwordFormat="Hashed" />
</providers>
</membership>
<!-- Other configuration code not shown.-->
</system.web>
roleProviderName 属性で principalPermissionMode を使用する方法を次のコードに示します。
<behaviors>
<behavior name="ServiceBehaviour">
<serviceAuthorization principalPermissionMode ="UseAspNetRoles"
roleProviderName ="SqlProvider" />
</behavior>
<!-- Other configuration code not shown. -->
</behaviors>
セキュリティ監査を構成する
書き込み先のログと、ログに記録するイベントの種類を指定するには、<serviceSecurityAudit> を使用します。 詳細については、「監査」を参照してください。
<behaviors>
<serviceBehaviors>
<behavior name="NewBehavior">
<serviceSecurityAudit auditLogLocation="Application"
suppressAuditFailure="true"
serviceAuthorizationAuditLevel="Success"
messageAuthenticationAuditLevel="Success" />
</behavior>
</serviceBehaviors>
</behaviors>
セキュリティで保護されたメタデータ交換
メタデータをクライアントにエクスポートすると、構成やクライアント コードのダウンロードが可能になるため、サービスとクライアントの開発者にとって便利です。 サービスが悪意のあるユーザーに公開されないようにするために、SSL over HTTP (HTTPS) 機構を使用して転送をセキュリティで保護できます。 転送を保護するには、まず、サービスをホストしているコンピューターの特定のポートに適切な X.509 証明書をバインドする必要があります。 (詳細については、「証明書の使用」を参照してください。) 次に、<serviceMetadata> をサービス構成に追加し、HttpsGetEnabled 属性を true に設定します。 最後に、次の例に示すように、HttpsGetUrl 属性をサービス メタデータ エンドポイントの URL に設定します。
<behaviors>
<serviceBehaviors>
<behavior name="NewBehavior">
<serviceMetadata httpsGetEnabled="true"
httpsGetUrl="https://myComputerName/myEndpoint" />
</behavior>
</serviceBehaviors>
</behaviors>