Nem támogatott forgatókönyvek
A Windows Communication Foundation (WCF) különböző okokból nem támogat bizonyos konkrét biztonsági forgatókönyveket. A Windows XP Home Edition például nem implementálja az SSPI- vagy Kerberos-hitelesítési protokollokat, ezért a WCF nem támogatja a Windows-hitelesítéssel rendelkező szolgáltatások futtatását ezen a platformon. Más hitelesítési mechanizmusok, például a felhasználónév/jelszó és a HTTP/HTTPS integrált hitelesítés támogatottak a WCF Windows XP Home Edition rendszerben történő futtatásakor.
Megszemélyesítési forgatókönyvek
Előfordulhat, hogy a megszemélyesített identitás nem áramlik, amikor az ügyfelek aszinkron hívásokat kezdeményeznek
Ha egy WCF-ügyfél aszinkron hívásokat intéz egy WCF-szolgáltatáshoz Windows-hitelesítéssel megszemélyesítéssel, a megszemélyesített identitás helyett az ügyfélfolyamat identitásával történő hitelesítés történhet.
A Windows XP és a biztonságos környezet jogkivonatának cookie-ja engedélyezve van
A WCF nem támogatja a megszemélyesítést, és InvalidOperationException a következő feltételek fennállása esetén egy dobás történik:
Az operációs rendszer Windows XP.
A hitelesítési mód windowsos identitást eredményez.
A Impersonation tulajdonság értéke a OperationBehaviorAttribute következő.Required
Létrejön egy állapotalapú biztonsági környezeti jogkivonat (SCT) (alapértelmezés szerint a létrehozás le van tiltva).
Az állapotalapú SCT csak egyéni kötéssel hozható létre. További információ : Biztonsági környezet jogkivonatának létrehozása biztonságos munkamenethez.) A kódban a jogkivonat egy biztonsági kötési elem létrehozásával (vagy SymmetricSecurityBindingElementAsymmetricSecurityBindingElement) a SecurityBindingElement.CreateSspiNegotiationBindingElement(Boolean) metódussal SecurityBindingElement.CreateSecureConversationBindingElement(SecurityBindingElement, Boolean) és a requireCancellation paraméter falsebeállításával engedélyezve van. A paraméter az SCT gyorsítótárazására hivatkozik. Az érték beállítása az false állapotalapú SCT-funkció engedélyezése érdekében.
A konfigurációban a jogkivonatot úgy is engedélyezheti, hogy létrehoz egy <customBinding>elemet, majd hozzáad egy <>securityelemet, és beállítja az authenticationMode attribútumot a SecureConversation-hez és az requireSecurityContextCancellation attribútumhoz.true
Feljegyzés
A fenti követelmények konkrétak. A kötés például létrehoz egy kötési elemet, CreateKerberosBindingElement amely Windows-identitást eredményez, de nem hoz létre SCT-t. Ezért a Windows XP-ben is használhatja ezt a Required lehetőséget.
Lehetséges ASP.NET ütközés
A WCF és a ASP.NET egyaránt engedélyezhetik vagy letilthatják a megszemélyesítést. Ha ASP.NET WCF-alkalmazást üzemeltet, ütközés léphet fel a WCF és ASP.NET konfigurációs beállítások között. Ütközés esetén a WCF-beállítás elsőbbséget élvez, hacsak a Impersonation tulajdonság nincs beállítva NotAllowed, ebben az esetben a ASP.NET megszemélyesítési beállítás elsőbbséget élvez.
A szerelvénybetöltések megszemélyesítéssel meghiúsulhatnak
Ha a megszemélyesített környezet nem rendelkezik hozzáférési jogosultságokkal egy szerelvény betöltéséhez, és ha a közös nyelvi futtatókörnyezet (CLR) először próbálja betölteni az adott AppDomain szerelvényét, a rendszer gyorsítótárazza a AppDomain hibát. A szerelvény (vagy szerelvények) későbbi betöltése sikertelen, még a megszemélyesítés visszaállítása után is, és még akkor is, ha a visszaállított környezet hozzáférési jogosultságokkal rendelkezik a szerelvény betöltéséhez. Ennek az az oka, hogy a CLR nem állítja újra a terhelést a felhasználói környezet módosítása után. A hiba utáni helyreállításhoz újra kell indítania az alkalmazástartományt.
Feljegyzés
Az osztály tulajdonságának alapértelmezett értéke AllowedImpersonationLevel a WindowsClientCredential következő Identification. A legtöbb esetben az azonosítási szintű megszemélyesítési környezetnek nincs jogosultsága további szerelvények betöltésére. Ez az alapértelmezett érték, ezért ez egy nagyon gyakori feltétel, amiről tisztában kell lennie. Az azonosítási szintű megszemélyesítés akkor is előfordul, ha a megszemélyesítési folyamat nem rendelkezik jogosultsággal SeImpersonate . További információ: Delegálás és megszemélyesítés.
A delegáláshoz hitelesítő adatok egyeztetése szükséges
Ha a Kerberos hitelesítési protokollt delegálással szeretné használni, a Kerberos-protokollt hitelesítő adatok egyeztetésével kell implementálnia (más néven több lábból vagy többlépéses Kerberosból). Ha a Kerberos-hitelesítést hitelesítő adatok egyeztetése nélkül valósítja meg (más néven egylövetű vagy egylábas Kerberos), a rendszer kivételt jelez. A hitelesítő adatok egyeztetésének implementálásáról további információt a Windows-hitelesítési hibák hibakeresése című témakörben talál.
Kriptográfia
Az SHA-256 csak szimmetrikus kulcshasználatokhoz támogatott
A WCF számos titkosítási és aláírás-kivonatoló algoritmust támogat, amelyeket a rendszer által biztosított kötésekben az algoritmuscsomag használatával adhat meg. A nagyobb biztonság érdekében a WCF támogatja a Secure Hash Algorithm (SHA) 2 algoritmusokat, különösen az SHA-256-ot az aláírás-kivonatoló kivonatok létrehozásához. Ez a kiadás csak szimmetrikus kulcshasználatokhoz, például Kerberos-kulcsokhoz támogatja az SHA-256-ot, és ahol nem használ X.509-tanúsítványt az üzenet aláírásához. A WCF nem támogatja az SHA-256 kivonatot használó (X.509-tanúsítványokban használt) RSA-aláírásokat, mivel jelenleg nem támogatott az RSA-SHA256 a WinFX-ben.
A FIPS-kompatibilis SHA-256 kivonatok nem támogatottak
A WCF nem támogatja az SHA-256 FIPS-kompatibilis kivonatokat, ezért az SHA-256-ot használó algoritmuscsomagokat a WCF nem támogatja olyan rendszereken, ahol FIPS-kompatibilis algoritmusok használatára van szükség.
A FIPS-kompatibilis algoritmusok sikertelenek lehetnek, ha a beállításjegyzéket szerkesztik
A Microsoft Management Console (MMC) helyi biztonsági Gépház beépülő moduljával engedélyezheti és letilthatja a szövetségi információfeldolgozási szabványoknak (FIPS) megfelelő algoritmusokat. A beállításjegyzékben is elérheti a beállítást. Vegye figyelembe azonban, hogy a WCF nem támogatja a beállításjegyzék használatát a beállításjegyzék alaphelyzetbe állításához. Ha az érték értéke nem 1 vagy 0, következetlen eredmények léphetnek fel a CLR és az operációs rendszer között.
FIPS-kompatibilis AES-titkosítás korlátozása
A FIPS-kompatibilis AES-titkosítás nem működik kétoldalas visszahívásokban azonosítási szintű megszemélyesítés esetén.
CNG/KSP-tanúsítványok
Titkosítási API: A Következő generációs (CNG) a CryptoAPI hosszú távú cseréje. Ez az API nem felügyelt kódban érhető el Windows Vista, Windows Server 2008 és újabb Windows-verziókon.
.NET-keretrendszer 4.6.1 és korábbi verziók nem támogatják ezeket a tanúsítványokat, mert az örökölt CryptoAPI-t használják a CNG/KSP-tanúsítványok kezelésére. A tanúsítványok használata a .NET-keretrendszer 4.6.1-ben és a korábbi verziókban kivételt okoz.
Kétféleképpen állapítható meg, hogy egy tanúsítvány KSP-t használ-e:
Végezze el a következőt
p/invokeCertGetCertificateContextProperty, és vizsgálja megdwProvTypea visszaadottCertGetCertificateContextPropertyelemet.A tanúsítványok lekérdezéséhez használja a
certutilparancssorból származó parancsot. További információkért tekintse meg a tanúsítványok hibaelhárításával kapcsolatos Certutil-feladatokat.
Az üzenet biztonsága meghiúsul, ha ASP.NET megszemélyesítés és ASP.NET kompatibilitás szükséges
A WCF nem támogatja a beállítások alábbi kombinációját, mert megakadályozhatják az ügyfélhitelesítést:
ASP.NET megszemélyesítés engedélyezve van. Ez a Web.config fájlban történik az elem
trueattribútumánakidentity><beállításávalimpersonate.ASP.NET kompatibilitási mód a serviceHostingEnvironment>
trueattribútumának< beállításávalaspNetCompatibilityEnabledengedélyezve van.A rendszer üzenetmód-biztonságot használ.
A megkerülő megoldás a ASP.NET kompatibilitási mód kikapcsolása. Vagy ha a ASP.NET kompatibilitási módra van szükség, tiltsa le a ASP.NET megszemélyesítési funkciót, és használja helyette a WCF által biztosított megszemélyesítést. További információ: Delegálás és megszemélyesítés.
IPv6-címhiba
A biztonsági kérések meghiúsulnak, ha az ügyfél és a szolgáltatás ugyanazon a gépen található, és a szolgáltatáshoz IPv6-literális címeket használnak.
A literális IPv6-címek akkor működnek, ha a szolgáltatás és az ügyfél különböző gépeken van.
WSDL-beolvasási hibák összevont megbízhatósággal
A WCF-nek pontosan egy WSDL-dokumentumra van szüksége az összevont megbízhatósági lánc egyes csomópontjaihoz. Ügyeljen arra, hogy ne állítson be hurkot a végpontok megadásakor. A hurkok keletkezésének egyik módja az összevont megbízhatósági láncok WSDL-letöltésének használata két vagy több hivatkozással ugyanabban a WSDL-dokumentumban. A problémát okozó gyakori forgatókönyv egy összevont szolgáltatás, amelyben a biztonsági jogkivonat-kiszolgáló és a szolgáltatás ugyanabban a ServiceHostban található.
Erre a helyzetre példa egy szolgáltatás, amely a következő három végpontcímet tartalmazza:
http://localhost/CalculatorService/service(a szolgáltatás)http://localhost/CalculatorService/issue_ticket(az STS)http://localhost/CalculatorService/mex(a metaadat-végpont)
Ez kivételt eredményez.
Ezt a forgatókönyvet úgy teheti működőképessé, hogy a issue_ticket végpontot máshová helyezi.
A WSDL importálási attribútumai elveszhetnek
A WCF a WSDL-importálás során elveszíti a sablon egy <wst:Claims> elemének RST attribútumait. Ez a WSDL-importálás során történik, ha közvetlenül WSFederationHttpBinding.Security.Message.TokenRequestParametersIssuedSecurityTokenRequestParameters.AdditionalRequestParameters a jogcímtípus-gyűjtemények közvetlen használata helyett adja meg<Claims>. Mivel az importálás elveszíti az attribútumokat, a kötés nem jár megfelelően a WSDL-n keresztül, ezért helytelen az ügyféloldalon.
A javítás az, hogy az importálás után közvetlenül az ügyfélen módosítsa a kötést.