Nepodporované scénáře
Z různých důvodů windows Communication Foundation (WCF) nepodporuje některé konkrétní scénáře zabezpečení. Například Systém Windows XP Home Edition neimplementuje ověřovací protokoly SSPI nebo Kerberos, a proto WCF nepodporuje spuštění služby s ověřováním systému Windows na této platformě. Jiné mechanismy ověřování, například uživatelské jméno/heslo a integrované ověřování HTTP/HTTPS, se podporují při spouštění WCF v systému Windows XP Home Edition.
Scénáře zosobnění
Zosobněná identita nemusí tokovat, když klienti můžou provádět asynchronní volání
Když klient WCF provádí asynchronní volání služby WCF pomocí ověřování systému Windows v rámci zosobnění, může k ověřování dojít s identitou procesu klienta místo zosobněné identity.
Windows XP a povolený soubor cookie zabezpečeného kontextového tokenu
WCF nepodporuje zosobnění a vyvolá se InvalidOperationException , pokud existují následující podmínky:
Operační systém je Windows XP.
Výsledkem režimu ověřování je identita Systému Windows.
Vlastnost Impersonation objektu je nastavena OperationBehaviorAttribute na Requiredhodnotu .
Vytvoří se token SCT (State-Based Security Context Token) (ve výchozím nastavení je vytváření zakázané).
SCT založené na stavu lze vytvořit pouze pomocí vlastní vazby. Další informace naleznete v tématu Postupy: Vytvoření tokenu kontextu zabezpečení pro zabezpečenou relaci.) V kódu je token povolen vytvořením elementu vazby zabezpečení (nebo SymmetricSecurityBindingElementAsymmetricSecurityBindingElement) pomocí SecurityBindingElement.CreateSspiNegotiationBindingElement(Boolean) metody nebo SecurityBindingElement.CreateSecureConversationBindingElement(SecurityBindingElement, Boolean) nastavení parametru requireCancellation na false. Parametr odkazuje na ukládání SCT do mezipaměti. Nastavením hodnoty povolíte false funkci SCT na základě stavu.
V konfiguraci je token povolen vytvořením <>customBinding, pak přidánímsecurity<> elementu a nastavením atributu authenticationMode SecureConversation a atributu requireSecurityContextCancellation na .true
Poznámka:
Předchozí požadavky jsou specifické. Například vytvoří prvek vazby, CreateKerberosBindingElement který vede k identitě Systému Windows, ale nevytvoří SCT. Proto jej můžete použít s Required možností v systému Windows XP.
Možný konflikt ASP.NET
WCF i ASP.NET můžou povolit nebo zakázat zosobnění. Když ASP.NET hostuje aplikaci WCF, může mezi nastavením konfigurace WCF a ASP.NET existovat konflikt. V případě konfliktu má nastavení WCF přednost, pokud Impersonation není vlastnost nastavena na NotAllowed, v takovém případě má přednost nastavení ASP.NET zosobnění.
Načtení sestavení může selhat v rámci zosobnění
Pokud zosobněný kontext nemá přístupová práva k načtení sestavení a pokud se poprvé pokusí modul CLR (Common Language Runtime) načíst sestavení pro danou doménu AppDomain, AppDomain uloží selhání do mezipaměti. Následné pokusy o načtení sestavení (nebo sestavení) selžou, i když se vrátí zosobnění, a dokonce i v případě, že vrácený kontext má přístupová práva k načtení sestavení. Důvodem je to, že CLR po změně kontextu uživatele znovu nepřepne zatížení. Chcete-li se z této chyby zotavit, je nutné restartovat doménu aplikace.
Poznámka:
Výchozí hodnota vlastnosti AllowedImpersonationLevelWindowsClientCredential třídy je Identification. Ve většině případů nemá kontext zosobnění na úrovni identifikace žádná práva k načtení dalších sestavení. Toto je výchozí hodnota, takže jde o velmi běžnou podmínku, o které je potřeba vědět. K zosobnění na úrovni identifikace dochází také v případě, že proces zosobnění nemá SeImpersonate oprávnění. Další informace najdete v tématu Delegování a zosobnění.
Delegování vyžaduje vyjednávání přihlašovacích údajů.
Pokud chcete používat ověřovací protokol Kerberos s delegování, musíte implementovat protokol Kerberos s vyjednáváním přihlašovacích údajů (někdy se označuje jako vícenožá nebo vícestupňová kerberos). Pokud implementujete ověřování protokolem Kerberos bez vyjednávání přihlašovacích údajů (někdy se označuje jako protokol Kerberos s jedním snímkem nebo protokolem Kerberos s jednou nohama), vyvolá se výjimka. Další informace o implementaci vyjednávání přihlašovacích údajů naleznete v tématu Ladění chyb ověřování systému Windows.
Kryptografie
Sha-256 se podporuje jenom pro použití symetrických klíčů
WCF podporuje různé algoritmy pro vytváření algoritmů hash pro šifrování a podpisy, které můžete určit pomocí sady algoritmů v systémových vazbách. Pro lepší zabezpečení wcf podporuje algoritmy SHA (Secure Hash Algorithm) 2, konkrétně SHA-256, pro vytváření hodnot hash hodnot hash podpisů. Tato verze podporuje SHA-256 pouze pro použití symetrických klíčů, jako jsou klíče Kerberos, a tam, kde certifikát X.509 není použit k podepsání zprávy. WCF nepodporuje podpisy RSA (používané v certifikátech X.509) s použitím hodnoty hash SHA-256, protože v winFX v současné době chybí podpora RSA-SHA256.
Hodnoty hash SHA-256 kompatibilní se standardem FIPS se nepodporují.
WCF nepodporuje hodnoty hash kompatibilní se standardem SHA-256 FIPS, takže algoritmus, které používají algoritmus SHA-256, nejsou podporovány wcf v systémech, kde je vyžadováno použití algoritmů kompatibilních se standardem FIPS.
Algoritmy kompatibilní se standardem FIPS můžou selhat, pokud je registr upravován.
Algoritmy kompatibilní se standardem FIPS (Federal Information Processing Standards) můžete povolit a zakázat pomocí modulu snap-in Konzoly MMC (Local Security Nastavení Microsoft Management Console). K nastavení v registru se dostanete také. Všimněte si však, že WCF nepodporuje použití registru k resetování nastavení. Pokud je hodnota nastavená na cokoli jiného než 1 nebo 0, může mezi CLR a operačním systémem dojít k nekonzistentním výsledkům.
Omezení šifrování AES kompatibilní se standardem FIPS
Šifrování AES kompatibilní se standardem FIPS nefunguje v duplexním zpětném volání v rámci zosobnění na úrovni identifikace.
Certifikáty CNG/KSP
Rozhraní API kryptografie: Nová generace (CNG) je dlouhodobá náhrada za CryptoAPI. Toto rozhraní API je dostupné v nespravovaném kódu v systémech Windows Vista, Windows Server 2008 a novějších verzích Windows.
Rozhraní .NET Framework 4.6.1 a starší verze nepodporují tyto certifikáty, protože ke zpracování certifikátů CNG/KSP používají starší rozhraní CryptoAPI. Použití těchto certifikátů s rozhraním .NET Framework 4.6.1 a staršími verzemi způsobí výjimku.
Existují dva možné způsoby, jak zjistit, jestli certifikát používá KSP:
p/invokeProveďte aCertGetCertificateContextPropertyzkontrolujtedwProvTypevrácenýCertGetCertificateContextProperty.certutilK dotazování certifikátů použijte příkaz z příkazového řádku. Další informace najdete v tématu Úlohy nástroje Certutil pro řešení potíží s certifikáty.
Zabezpečení zpráv selže, pokud se vyžaduje použití zosobnění ASP.NET a kompatibilita ASP.NET
WCF nepodporuje následující kombinaci nastavení, protože můžou zabránit výskytu ověřování klientů:
ASP.NET zosobnění je povoleno. To se provádí v souboru Web.config nastavením
impersonateatributu elementu><identityna .trueASP.NET režim kompatibility je povolen nastavením
aspNetCompatibilityEnabledatributu <serviceHostingEnvironment> natrue.Používá se zabezpečení režimu zpráv.
Alternativním řešením je vypnout režim kompatibility ASP.NET. Nebo pokud je vyžadován režim kompatibility ASP.NET, zakažte funkci zosobnění ASP.NET a místo toho použijte zosobnění poskytované WCF. Další informace najdete v tématu Delegování a zosobnění.
Selhání literálové adresy IPv6
Požadavky na zabezpečení selžou, když jsou klient a služba na stejném počítači a adresy literálů IPv6 se používají pro službu.
Adresy IPv6 literálu fungují, pokud jsou služba a klient na různých počítačích.
Selhání načítání WSDL s federovaným vztahem důvěryhodnosti
WCF vyžaduje pro každý uzel v federovaného řetězu důvěryhodnosti přesně jeden dokument WSDL. Přizadáváních Jedním zezpůsobůch služeb je jedním ze způsobů, jak se můžou objevit smyčky, které mohou vzniknout, je použití stahování WSDL s federovanými vztahy důvěryhodnosti se dvěma nebo více odkazy ve stejném dokumentu WS Běžným scénářem, který může tento problém způsobit, je federovaná služba, ve které je server tokenů zabezpečení a služba obsaženy ve stejné službě ServiceHost.
Příkladem této situace je služba s následujícími třemi adresami koncového bodu:
http://localhost/CalculatorService/service(služba)http://localhost/CalculatorService/issue_ticket(stS)http://localhost/CalculatorService/mex(koncový bod metadat)
Tím dojde k výjimce.
Tento scénář můžete udělat tak, že koncový bod umístíte issue_ticket jinam.
Atributy importu WSDL je možné ztratit.
WCF při importu WSDL ztratí přehled o atributech <wst:Claims> elementu RST v šabloně. K tomu dochází při importu WSDL, pokud zadáte <Claims> přímo nebo WSFederationHttpBinding.Security.Message.TokenRequestParametersIssuedSecurityTokenRequestParameters.AdditionalRequestParameters místo použití kolekcí typů deklarací identity přímo. Vzhledem k tomu, že import ztratí atributy, vazba neprojde správně přes WSDL, a proto je nesprávná na straně klienta.
Oprava spočívá v úpravě vazby přímo na klientovi po importu.