サポートされていないシナリオUnsupported Scenarios

Windows Communication Foundation (WCF) では、さまざまな理由により、特定のセキュリティシナリオがサポートされていません。For various reasons, Windows Communication Foundation (WCF) does not support some specific security scenarios. たとえば、Windows XPWindows XP Home Edition では SSPI または Kerberos 認証プロトコルが実装されていないため、WCF では、そのプラットフォームで Windows 認証を使用してサービスを実行することはサポートされていません。For example, Windows XPWindows XP Home Edition does not implement the SSPI or Kerberos authentication protocols, and therefore WCF does not support running a service with Windows authentication on that platform. Windows XP Home Edition で WCF を実行する場合は、ユーザー名/パスワードや HTTP/HTTPS 統合認証などの他の認証メカニズムがサポートされます。Other authentication mechanisms, such as username/password and HTTP/HTTPS integrated authentication are supported when running WCF under Windows XP Home Edition.

偽装シナリオImpersonation Scenarios

クライアントが非同期呼び出しを行うと、偽装 ID はフローしない場合があるImpersonated Identity Might Not Flow When Clients Make Asynchronous Calls

WCF クライアントが、偽装で Windows 認証を使用して WCF サービスへの非同期呼び出しを行うと、偽装 ID ではなくクライアント プロセスの ID で認証が行われる場合があります。When a WCF client makes asynchronous calls to a WCF service using Windows authentication under impersonation, authentication might occur with the identity of the client process instead of the impersonated identity.

WCF では偽装がサポートされていないため、次の条件に該当する場合は InvalidOperationException がスローされます。WCF does not support impersonation and an InvalidOperationException is thrown when the following conditions exist:

  • オペレーティング システムが Windows XPWindows XP である。The operating system is Windows XPWindows XP.

  • 認証モードで Windows ID が生成された。The authentication mode results in a Windows identity.

  • ImpersonationOperationBehaviorAttribute プロパティが Required に設定されています。The Impersonation property of the OperationBehaviorAttribute is set to Required.

  • 状態ベースのセキュリティ コンテキスト トークン (SCT: Security Context Token) が作成された (既定では、作成は無効になっています)。A state-based security context token (SCT) is created (by default, creation is disabled).

状態ベースの SCT はカスタム バインディングの使用によってのみ作成できます。The state-based SCT can only be created using a custom binding. 詳細については、「方法: セキュリティで保護されたセッションのセキュリティコンテキストトークンを作成する」を参照してください。コードでは、トークンは SecurityBindingElement.CreateSspiNegotiationBindingElement(Boolean) または SecurityBindingElement.CreateSecureConversationBindingElement(SecurityBindingElement, Boolean) メソッドを使用してセキュリティバインド要素 (SymmetricSecurityBindingElement または AsymmetricSecurityBindingElement) を作成し、requireCancellation パラメーターを falseに設定することによって有効にします。For more information, see How to: Create a Security Context Token for a Secure Session.) In code, the token is enabled by creating a security binding element (either SymmetricSecurityBindingElement or AsymmetricSecurityBindingElement) using the SecurityBindingElement.CreateSspiNegotiationBindingElement(Boolean) or the SecurityBindingElement.CreateSecureConversationBindingElement(SecurityBindingElement, Boolean) method and setting the requireCancellation parameter to false. このパラメーターは、SCT のキャッシュを参照します。The parameter refers to the caching of the SCT. 値を false に設定することによって、状態ベースの SCT 機能が有効になります。Setting the value to false enables the state-based SCT feature.

または、構成において、<customBinding> を作成し、<security> 要素を追加して authenticationMode 属性に SecureConversation および requireSecurityContextCancellation 属性に true を設定することによってもトークンが有効になります。Alternatively, in configuration, the token is enabled by creating a <customBinding>, then adding a <security> element, and setting the authenticationMode attribute to SecureConversation and the requireSecurityContextCancellation attribute to true.

注意

上記の要件は限定的です。The preceding requirements are specific. たとえば、CreateKerberosBindingElement は Windows ID を生成するバインド要素を作成しますが、SCT を確立しません。For example, the CreateKerberosBindingElement creates a binding element that results in a Windows identity, but does not establish an SCT. したがって、RequiredWindows XPWindows XP オプションと共に使用できます。Therefore, you can use it with the Required option on Windows XPWindows XP.

考えられる ASP.NET との競合Possible ASP.NET Conflict

WCF と ASP.NET は、どちらも偽装を有効または無効にすることができます。WCF and ASP.NET can both enable or disable impersonation. ASP.NET が WCF アプリケーションをホストする場合、WCF と ASP.NET の構成設定の間に競合が存在する可能性があります。When ASP.NET hosts an WCF application, a conflict may exist between the WCF and ASP.NET configuration settings. 競合が発生した場合は、Impersonation プロパティが NotAllowedに設定されていない限り、WCF 設定が優先されます。この場合、ASP.NET impersonation 設定が優先されます。In case of conflict, the WCF setting takes precedence, unless the Impersonation property is set to NotAllowed, in which case the ASP.NET impersonation setting takes precedence.

偽装を有効にすると、アセンブリの読み込みに失敗する場合があるAssembly Loads May Fail Under Impersonation

偽装されたコンテキストにアセンブリを読み込むためのアクセス権がない場合、共通言語ランタイム (CLR: Common Language Runtime) が AppDomain のアセンブリを初めて読み込もうとしたときに、その AppDomain はエラーをキャッシュします。If the impersonated context does not have access rights to load an assembly and if it is the first time the common language runtime (CLR) is attempting to load the assembly for that AppDomain, the AppDomain caches the failure. この場合、偽装を元に戻した後、元に戻されたコンテキストにアセンブリを読み込むためのアクセス権があったとしても、それ以降のアセンブリの読み込みは失敗します。Subsequent attempts to load that assembly (or assemblies) fail, even after reverting the impersonation, and even if the reverted context has access rights to load the assembly. これは、ユーザー コンテキストの変更後に、CLR が読み込みを再試行しないためです。This is because the CLR does not re-attempt the load after the user context is changed. このエラーから回復するには、アプリケーション ドメインを再起動する必要があります。You must restart the application domain to recover from the failure.

注意

AllowedImpersonationLevel クラスの WindowsClientCredential プロパティの既定値は Identification です。The default value for the AllowedImpersonationLevel property of the WindowsClientCredential class is Identification. ほとんどの場合、ID レベルの偽装コンテキストには、追加のアセンブリを読み込むための権限がありません。In most cases, an identification-level impersonation context has no rights to load any additional assemblies. これは既定値であるため、非常に一般的な状態として認識しておく必要があります。This is the default value, so this is a very common condition to be aware of. ID レベルの偽装は、偽装プロセスが SeImpersonate 権限を持たない場合にも発生します。Identification-level impersonation also occurs when the impersonating process does not have the SeImpersonate privilege. 詳細については、「委任と偽装」を参照してください。For more information, see Delegation and Impersonation.

委任には資格情報ネゴシエーションが必要Delegation Requires Credential Negotiation

委任で Kerberos 認証プロトコルを使用するには、資格情報ネゴシエーションを使用する Kerberos プロトコル ("マルチレッグ" Kerberos または "マルチステップ" Kerberos とも呼ばれます) を実装する必要があります。To use the Kerberos authentication protocol with delegation, you must implement the Kerberos protocol with credential negotiation (sometimes called multi-leg or multi-step Kerberos). 資格情報ネゴシエーションを使用しない Kerberos 認証 (ワンショット Kerberos またはシングルレッグ Kerberos とも呼ばれる) を実装した場合は、例外がスローされます。If you implement Kerberos authentication without credential negotiation (sometimes called one-shot or single-leg Kerberos), an exception is thrown. 資格情報ネゴシエーションを実装する方法の詳細については、「 Windows 認証エラーのデバッグ」を参照してください。For more information about how to implement credential negotiation, see Debugging Windows Authentication Errors.

暗号Cryptography

対称キーを使用する場合にのみサポートされる SHA-256SHA-256 Supported Only for Symmetric Key Usages

WCF では、システム指定のバインディングでアルゴリズムスイートを使用して指定できる、さまざまな暗号化および署名ダイジェスト作成アルゴリズムがサポートされています。WCF supports a variety of encryption and signature digest creation algorithms that you can specify using the algorithm suite in the system-provided bindings. セキュリティを強化するために、WCF では、署名ダイジェストハッシュを作成するためのセキュアハッシュアルゴリズム (SHA) 2 アルゴリズム (具体的には SHA-256) がサポートされています。For improved security, WCF supports Secure Hash Algorithm (SHA) 2 algorithms, specifically SHA-256, for creating signature digest hashes. このリリースは、Kerberos キーなどの対称キーを使用する場合、およびメッセージに署名するために X.509 証明書を使用しない場合に限り SHA-256 をサポートします。This release supports SHA-256 only for symmetric key usages, such as Kerberos keys, and where an X.509 certificate is not used to sign the message. 現在のところ、WCF では、x.509 証明256書で使用される RSA 署名はサポートされていません。これは、WinFX で RSA SHA256 がサポートされていないためです。WCF does not support RSA signatures (used in X.509 certificates) using SHA-256 hash due to the current lack of support for RSA-SHA256 in the WinFX.

サポートされていない FIPS 準拠の SHA-256 ハッシュFIPS-Compliant SHA-256 Hashes not Supported

WCF では、256 SHA-1 FIPS 準拠ハッシュはサポートされていないため、FIPS 準拠アルゴリズムを使用するシステムでは、SHA-256 を使用するアルゴリズムスイートが WCF でサポートされません。WCF does not support SHA-256 FIPS-compliant hashes, so algorithm suites that use SHA-256 are not supported by WCF on systems where use of FIPS compliant algorithms is required.

レジストリを編集すると、FIPS 準拠のアルゴリズムが失敗する場合があるFIPS-Compliant Algorithms May Fail if Registry Is Edited

連邦情報処理規格 (FIPS: Federal Information Processing Standards) 準拠のアルゴリズムを有効または無効にするには、Microsoft 管理コンソール (MMC: Microsoft Management Console) のローカル セキュリティ設定スナップインを使用します。You can enable and disable Federal Information Processing Standards (FIPS)-compliant algorithms by using the Local Security Settings Microsoft Management Console (MMC) snap-in. レジストリでこの設定にアクセスすることもできます。You can also access the setting in the registry. ただし、WCF では、レジストリを使用した設定のリセットはサポートされていません。Note, however, that WCF does not support using the registry to reset the setting. 値を 1 または 0 以外に設定すると、CLR とオペレーティング システム間で不整合が発生する可能性があります。If the value is set to anything other than 1 or 0, inconsistent results can occur between the CLR and the operating system.

FIPS 準拠の AES 暗号化の制限FIPS-Compliant AES Encryption Limitation

FIPS 準拠の AES 暗号化は、ID レベルの偽装での双方向コールバックでは機能しません。FIPS compliant AES encryption does not work in duplex callbacks under identification level impersonation.

CNG/KSP 証明書CNG/KSP Certificates

CRYPTOGRAPHY API: Next Generation (CNG) は、CryptoAPI の長期的な後継です。Cryptography API: Next Generation (CNG) is the long-term replacement for the CryptoAPI. この API は、Windows Vista、Windows Server 2008Windows Server 2008 以降の Windows バージョンのアンマネージコードで使用できます。This API is available in unmanaged code on Windows Vista, Windows Server 2008Windows Server 2008 and later Windows versions.

.NET Framework 4.6.1 以前のバージョンでは、従来の CryptoAPI を使用して CNG/KSP 証明書を処理するため、これらの証明書はサポートされません。.NET Framework 4.6.1 and earlier versions do not support these certificates because they use the legacy CryptoAPI to handle CNG/KSP certificates. これらの証明書を .NET Framework 4.6.1 以前のバージョンで使用すると、例外が発生します。The use of these certificates with .NET Framework 4.6.1 and earlier versions will cause an exception.

証明書に KSP が使用されているかどうかを知る方法は 2 つあります。There are two possible ways to tell if a certificate uses KSP:

  • p/invokeCertGetCertificateContextProperty に対して実行し、返された dwProvTypeCertGetCertificateContextProperty を調べる。Do a p/invoke of CertGetCertificateContextProperty, and inspect dwProvType on the returned CertGetCertificateContextProperty.

  • 証明書を照会するには、コマンドラインから certutil コマンドを使用します。Use the certutil command from the command line for querying certificates. 詳細については、「証明書のトラブルシューティングに関する Certutil タスク」を参照してください。For more information, see Certutil tasks for troubleshooting certificates.

ASP.NET の偽装と ASP.NET 互換を使用する必要がある場合にメッセージ セキュリティが失敗するMessage Security Fails if Using ASP.NET Impersonation and ASP.NET Compatibility Is Required

WCF では、クライアント認証が行われないようにするため、次の設定の組み合わせはサポートされていません。WCF does not support the following combination of settings because they can prevent client authentication from occurring:

  • ASP.NET の偽装が有効になっています。ASP.NET Impersonation is enabled. これは、web.config ファイルで、<identity> 要素の impersonate 属性を trueに設定することによって行われます。This is done in the Web.config file by setting the impersonate attribute of the <identity> element to true.

  • ASP.NET 互換モードを有効にするには<serviceHostingEnvironment >aspNetCompatibilityEnabled 属性を trueに設定します。ASP.NET compatibility mode is enabled by setting the aspNetCompatibilityEnabled attribute of the <serviceHostingEnvironment> to true.

  • メッセージ モード セキュリティを使用している。Message mode security is used.

回避策として、ASP.NET 互換モードをオフにします。The work-around is to turn off the ASP.NET compatibility mode. または、ASP.NET 互換モードが必要な場合は、ASP.NET 権限借用機能を無効にし、代わりに WCF によって提供される偽装を使用します。Or, if the ASP.NET compatibility mode is required, disable the ASP.NET impersonation feature and use WCF-provided impersonation instead. 詳細については、「委任と偽装」を参照してください。For more information, see Delegation and Impersonation.

IPv6 リテラル アドレス エラーIPv6 Literal Address Failure

クライアントとサービスが同じコンピューター上に存在し、サービスに対して IPv6 リテラル アドレスが使用されている場合は、セキュリティ要求が失敗します。Security requests fail when the client and service are on the same machine, and IPv6 literal addresses are used for the service.

IPv6 リテラル アドレスは、サービスとクライアントがそれぞれ異なるコンピューター上に存在する場合に機能します。Literal IPv6 addresses work if the service and client are on different machines.

フェデレーション信頼での WSDL 取得エラーWSDL Retrieval Failures with Federated Trust

WCF では、フェデレーション信頼チェーン内のノードごとに1つの WSDL ドキュメントが必要です。WCF requires exactly one WSDL document for each node in the federated trust chain. エンドポイントを指定するときにループにならないように注意する必要があります。Be careful not to set up a loop when specifying endpoints. ループになる場合の例の 1 つは、フェデレーション信頼チェーンの WSDL ダウンロードの使用で、同じ WSDL ドキュメントの中に複数のリンクがある場合です。One way in which loops can arise is using a WSDL download of federated trust chains with two or more links in the same WSDL document. この問題がよく発生するシナリオは、セキュリティ トークン サーバーとセキュリティ トークン サービスが同じ ServiceHost の中にあるフェデレーション サービスです。A common scenario that can produce this problem is a federated service where the Security Token Server and the service are contained inside the same ServiceHost.

そのような状況の例は次の 3 つのエンドポイント アドレスを使うサービスです。An example of this situation is a service with the following three endpoint addresses:

  • http://localhost/CalculatorService/service (サービス)http://localhost/CalculatorService/service (the service)

  • http://localhost/CalculatorService/issue_ticket (STS)http://localhost/CalculatorService/issue_ticket (the STS)

  • http://localhost/CalculatorService/mex (メタデータエンドポイント)http://localhost/CalculatorService/mex (the metadata endpoint)

これによって例外がスローされます。This throws an exception.

このシナリオでエラーを避けるには、issue_ticket エンドポイントを別のところに置きます。You can make this scenario work by putting the issue_ticket endpoint elsewhere.

WSDL インポート属性が失われる可能性WSDL Import Attributes can be Lost

WSDL インポートの際に、WCF は <wst:Claims> テンプレート内の RST 要素にあるインポート属性を追跡できなくなることがあります。WCF loses track of the attributes on a <wst:Claims> element in an RST template when doing a WSDL import. これは、クレームの種類のコレクションを直接使用する代わりに <Claims> を直接 WSFederationHttpBinding.Security.Message.TokenRequestParameters または IssuedSecurityTokenRequestParameters.AdditionalRequestParameters 内で指定した場合に、WSDL インポートの際に発生します。This happens during a WSDL import if you specify <Claims> directly in WSFederationHttpBinding.Security.Message.TokenRequestParameters or IssuedSecurityTokenRequestParameters.AdditionalRequestParameters instead of using the claim type collections directly. インポートが属性を失うので、WSDL を介して正しいバインディングのラウンド トリップが行われません。したがって、クライアント側で不適切になります。Since the import loses the attributes, the binding does not round trip properly through WSDL and hence is incorrect on the client side.

解決策は、インポートを行った後、クライアント側で直接バインディングを変更することです。The fix is to modify the binding directly on the client after doing the import.

参照See also