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