サポートされていないシナリオ
さまざまな理由により、特定のセキュリティ シナリオは Windows Communication Foundation (WCF) でサポートされていません。 たとえば、Windows XP Home Edition は SSPI または Kerberos 認証プロトコルを実装しないため、このプラットフォーム上での Windows 認証を使用するサービスの実行は WCF でサポートされていません。 Windows XP Home Edition で WCF を実行している場合、ユーザー名とパスワードや、HTTP または HTTPS 統合認証などの他の認証機構がサポートされます。
偽装シナリオ
クライアントが非同期呼び出しを行うと、偽装 ID はフローしない場合がある
WCF クライアントが、偽装で Windows 認証を使用して WCF サービスへの非同期呼び出しを行うと、偽装 ID ではなくクライアント プロセスの ID で認証が行われる場合があります。
Windows XP と有効化されたセキュリティ コンテキスト トークン クッキー
偽装は WCF でサポートされておらず、以下の条件に該当する場合、InvalidOperationException が発生します。
オペレーティング システムが Windows XP である。
認証モードで Windows ID が生成された。
OperationBehaviorAttribute の Impersonation プロパティは Required に設定されます。
状態ベースのセキュリティ コンテキスト トークン (SCT: Security Context Token) が作成された (既定では、作成は無効になっています)。
状態ベースの SCT はカスタム バインディングの使用によってのみ作成できます。 詳細については、「方法: セキュリティで保護されたセッションに対しセキュリティ コンテキスト トークンを作成する」を参照してください。 コードでトークンを有効にするには、SecurityBindingElement.CreateSspiNegotiationBindingElement(Boolean) または SecurityBindingElement.CreateSecureConversationBindingElement(SecurityBindingElement, Boolean) メソッドを使用して、セキュリティ バインド要素 (SymmetricSecurityBindingElement または AsymmetricSecurityBindingElement) を作成し、requireCancellation パラメーターを false に設定します。 このパラメーターは、SCT のキャッシュを参照します。 値を false に設定することによって、状態ベースの SCT 機能が有効になります。
または、構成でトークンを有効にするには、<customBinding> を作成して、<security> 要素を追加し、authenticationMode 属性を SecureConversation に、requireSecurityContextCancellation 属性を true に設定します。
Note
上記の要件は限定的です。 たとえば、CreateKerberosBindingElement は Windows ID を生成するバインド要素を作成しますが、SCT を確立しません。 したがって、Windows XP 上で Required オプションと共に使用できます。
考えられる ASP.NET との競合
WCF と ASP.NET はいずれも、偽装を有効にすることも無効にすることもできます。 ASP.NET で WCF アプリケーションをホストする場合、WCF と ASP.NET の構成設定の間に競合が存在する可能性があります。 競合が発生した場合、WCF の設定が優先されます。ただし、Impersonation プロパティを NotAllowed に設定している場合は、ASP.NET の偽装設定が優先されます。
偽装を有効にすると、アセンブリの読み込みに失敗する場合がある
偽装されたコンテキストにアセンブリを読み込むためのアクセス権がない場合、共通言語ランタイム (CLR: Common Language Runtime) が AppDomain のアセンブリを初めて読み込もうとしたときに、その AppDomain はエラーをキャッシュします。 この場合、偽装を元に戻した後、元に戻されたコンテキストにアセンブリを読み込むためのアクセス権があったとしても、それ以降のアセンブリの読み込みは失敗します。 これは、ユーザー コンテキストの変更後に、CLR で読み込みが再試行されないためです。 このエラーから回復するには、アプリケーション ドメインを再起動する必要があります。
Note
AllowedImpersonationLevel クラスの WindowsClientCredential プロパティの既定値は Identification です。 ほとんどの場合、ID レベルの偽装コンテキストには、追加のアセンブリを読み込むための権限がありません。 これは既定値であるため、非常に一般的な状態として認識しておく必要があります。 ID レベルの偽装は、偽装プロセスが SeImpersonate 権限を持たない場合にも発生します。 詳細については、「委任と偽装」を参照してください。
委任には資格情報ネゴシエーションが必要
委任で Kerberos 認証プロトコルを使用するには、資格情報ネゴシエーションを使用する Kerberos プロトコル ("マルチレッグ" Kerberos または "マルチステップ" Kerberos とも呼ばれます) を実装する必要があります。 資格情報ネゴシエーションを使用しない Kerberos 認証 (ワンショット Kerberos またはシングルレッグ Kerberos とも呼ばれる) を実装した場合は、例外がスローされます。 資格情報ネゴシエーションを実装する方法の詳細については、「Windows 認証エラーのデバッグ」を参照してください。
暗号化
対称キーを使用する場合にのみサポートされる SHA-256
さまざまな暗号化アルゴリズムと署名ダイジェスト作成アルゴリズムが WCF でサポートされています。これらのアルゴリズムは、システム指定のバインディングでアルゴリズム スイートを使用して指定できます。 セキュリティを強化するため、WCF では、署名ダイジェスト ハッシュを作成するためにセキュア ハッシュ アルゴリズム (SHA: Secure Hash Algorithm) 2 (具体的には SHA-256) がサポートされています。 このリリースは、Kerberos キーなどの対称キーを使用する場合、およびメッセージに署名するために X.509 証明書を使用しない場合に限り SHA-256 をサポートします。 現時点で RSA-SHA256 は WinFX でサポートされていないため、WCF では SHA-256 ハッシュを使用した RSA 署名 (X.509 証明書で使用) がサポートされていません。
サポートされていない FIPS 準拠の SHA-256 ハッシュ
FIPS 準拠の SHA-256 ハッシュは WCF でサポートされていません。したがって、FIPS 準拠のアルゴリズムを使用する必要のあるシステムにおいて、SHA-256 を使用するアルゴリズム スイートは WCF でサポートされません。
レジストリを編集すると、FIPS 準拠のアルゴリズムが失敗する場合がある
連邦情報処理規格 (FIPS: Federal Information Processing Standards) 準拠のアルゴリズムを有効または無効にするには、Microsoft 管理コンソール (MMC: Microsoft Management Console) のローカル セキュリティ設定スナップインを使用します。 レジストリでこの設定にアクセスすることもできます。 ただし、レジストリを使用した設定のリセットは WCF でサポートされていません。 値を 1 または 0 以外に設定すると、CLR とオペレーティング システム間で不整合が発生する可能性があります。
FIPS 準拠の AES 暗号化の制限
FIPS 準拠の AES 暗号化は、ID レベルの偽装での双方向コールバックでは機能しません。
CNG または KSP 証明書
CNG (Cryptography API: Next Generation) は、CryptoAPI に代わるものとして長期的な視野に立って開発されました。 この API は、Windows Vista、Windows Server 2008、およびそれ以降の Windows バージョンのアンマネージド コード内で使用できます。
.NET Framework 4.6.1 以前のバージョンでは、従来の CryptoAPI を使用して CNG または KSP 証明書を処理するため、これらの証明書はサポートされません。 これらの証明書を .NET Framework 4.6.1 以前のバージョンで使用すると、例外が発生します。
証明書に KSP が使用されているかどうかを知る方法は 2 つあります。
p/invokeをCertGetCertificateContextPropertyに対して実行し、返されたdwProvTypeでCertGetCertificateContextPropertyを調べる。コマンド ラインから
certutilコマンドを使用して証明書のクエリを実行する。 詳細については、「証明書のトラブルシューティングに関する Certutil タスク」を参照してください。
ASP.NET の偽装と ASP.NET 互換を使用する必要がある場合にメッセージ セキュリティが失敗する
次の設定の組み合わせはクライアント認証の妨げとなる可能性があるため、この組み合わせは WCF でサポートされていません。
ASP.NET の偽装を有効にする。 これを行うには、Web.config ファイルで <
identity> 要素のimpersonate属性をtrueに設定します。<serviceHostingEnvironment> の
aspNetCompatibilityEnabled属性をtrueに設定して、ASP.NET 互換モードを有効にしている。メッセージ モード セキュリティを使用している。
これを回避するには、ASP.NET 互換モードを無効にします。 ASP.NET 互換モードが必要な場合は、ASP.NET の偽装機能を無効にし、代わりに WCF で提供される偽装機能を使用します。 詳細については、「委任と偽装」を参照してください。
IPv6 リテラル アドレス エラー
クライアントとサービスが同じコンピューター上に存在し、サービスに対して IPv6 リテラル アドレスが使用されている場合は、セキュリティ要求が失敗します。
IPv6 リテラル アドレスは、サービスとクライアントがそれぞれ異なるコンピューター上に存在する場合に機能します。
フェデレーション信頼での WSDL 取得エラー
WCF では、フェデレーション信頼チェーンの各ノードに対して WSDL ドキュメントが正確に 1 つだけ要求されます。 エンドポイントを指定するときにループにならないように注意する必要があります。 ループになる場合の例の 1 つは、フェデレーション信頼チェーンの WSDL ダウンロードの使用で、同じ WSDL ドキュメントの中に複数のリンクがある場合です。 この問題がよく発生するシナリオは、セキュリティ トークン サーバーとセキュリティ トークン サービスが同じ ServiceHost の中にあるフェデレーション サービスです。
そのような状況の例は次の 3 つのエンドポイント アドレスを使うサービスです。
http://localhost/CalculatorService/service(サービス)http://localhost/CalculatorService/issue_ticket(STS)http://localhost/CalculatorService/mex(メタデータ エンドポイント)
これによって例外がスローされます。
このシナリオでエラーを避けるには、issue_ticket エンドポイントを別のところに置きます。
WSDL インポート属性が失われる可能性
WSDL インポートの際に、WCF は <wst:Claims> テンプレート内の RST 要素にあるインポート属性を追跡できなくなることがあります。 これは、クレームの種類のコレクションを直接使用する代わりに <Claims> を直接 WSFederationHttpBinding.Security.Message.TokenRequestParameters または IssuedSecurityTokenRequestParameters.AdditionalRequestParameters 内で指定した場合に、WSDL インポートの際に発生します。 インポートが属性を失うので、WSDL を介して正しいバインディングのラウンド トリップが行われません。したがって、クライアント側で不適切になります。
解決策は、インポートを行った後、クライアント側で直接バインディングを変更することです。