Scenarier som inte stöds
Av olika skäl stöder Windows Communication Foundation (WCF) inte vissa specifika säkerhetsscenarier. Windows XP Home Edition implementerar till exempel inte SSPI- eller Kerberos-autentiseringsprotokollen och därför har WCF inte stöd för att köra en tjänst med Windows-autentisering på den plattformen. Andra autentiseringsmekanismer, till exempel användarnamn/lösenord och HTTP/HTTPS-integrerad autentisering, stöds när du kör WCF under Windows XP Home Edition.
Scenarier för personifiering
Personifierad identitet kanske inte flödar när klienter gör asynkrona anrop
När en WCF-klient gör asynkrona anrop till en WCF-tjänst med Windows-autentisering under personifiering kan autentisering ske med klientprocessens identitet i stället för den personifierade identiteten.
Windows XP och säker cookie för kontexttoken aktiverad
WCF stöder inte personifiering och en InvalidOperationException utlöses när följande villkor finns:
Operativsystemet är Windows XP.
Autentiseringsläget resulterar i en Windows-identitet.
Egenskapen Impersonation för är inställd på OperationBehaviorAttributeRequired.
En tillståndsbaserad säkerhetskontexttoken (SCT) skapas (som standard är skapandet inaktiverat).
Tillståndsbaserad SCT kan bara skapas med en anpassad bindning. Mer information finns i Så här skapar du en säkerhetskontexttoken för en säker session.) I kod aktiveras token genom att skapa ett säkerhetsbindningselement (antingen SymmetricSecurityBindingElement eller AsymmetricSecurityBindingElement) med hjälp av SecurityBindingElement.CreateSspiNegotiationBindingElement(Boolean) metoden eller SecurityBindingElement.CreateSecureConversationBindingElement(SecurityBindingElement, Boolean) och ange parametern requireCancellation till false. Parametern refererar till cachelagring av SCT. Om du anger värdet till false aktiveras den tillståndsbaserade SCT-funktionen.
I konfigurationen kan du också aktivera token genom att skapa ett <>customBinding, sedan lägga till ett <>securityelement och ange authenticationMode attributet SecureConversation och requireSecurityContextCancellation attributet till .true
Kommentar
Ovanstående krav är specifika. Till exempel skapar ett bindningselement CreateKerberosBindingElement som resulterar i en Windows-identitet, men som inte upprättar en SCT. Därför kan du använda det med alternativet Required i Windows XP.
Möjlig ASP.NET konflikt
WCF och ASP.NET kan både aktivera eller inaktivera personifiering. När ASP.NET är värd för ett WCF-program kan det finnas en konflikt mellan konfigurationsinställningarna för WCF och ASP.NET. I händelse av konflikt har WCF-inställningen företräde, såvida inte Impersonation egenskapen är inställd på NotAllowed, i vilket fall inställningen ASP.NET personifiering har företräde.
Sammansättningsbelastningar kan misslyckas under personifiering
Om den personifierade kontexten inte har åtkomstbehörighet för att läsa in en sammansättning och om det är första gången den gemensamma språkkörningen (CLR) försöker läsa in sammansättningen för den AppDomain cachelagrar AppDomain cacheminnet felet. Efterföljande försök att läsa in sammansättningen (eller sammansättningarna) misslyckas, även efter att personifieringen har återställts, och även om den återställda kontexten har åtkomstbehörighet att läsa in sammansättningen. Det beror på att CLR inte försöker läsa in igen när användarkontexten har ändrats. Du måste starta om programdomänen för att återställa från felet.
Kommentar
Standardvärdet för AllowedImpersonationLevel egenskapen för WindowsClientCredential klassen är Identification. I de flesta fall har en personifieringskontext på identifieringsnivå ingen behörighet att läsa in ytterligare sammansättningar. Det här är standardvärdet, så det här är ett mycket vanligt villkor att känna till. Personifiering på identifieringsnivå sker också när personifieringsprocessen inte har behörigheten SeImpersonate . Mer information finns i Delegering och personifiering.
Delegering kräver förhandling om autentiseringsuppgifter
Om du vill använda Kerberos-autentiseringsprotokollet med delegering måste du implementera Kerberos-protokollet med förhandling om autentiseringsuppgifter (kallas ibland multi-leg eller Kerberos i flera steg). Om du implementerar Kerberos-autentisering utan förhandling med autentiseringsuppgifter (kallas ibland one-shot eller single-leg Kerberos) genereras ett undantag. Mer information om hur du implementerar förhandlingar om autentiseringsuppgifter finns i Felsöka Windows-autentiseringsfel.
Kryptografi
SHA-256 stöds endast för symmetriska nyckelanvändningar
WCF stöder en mängd olika algoritmer för skapande av kryptering och signatursammandrag som du kan ange med hjälp av algoritmsviten i bindningarna som tillhandahålls av systemet. För förbättrad säkerhet har WCF stöd för SHA 2-algoritmer (Secure Hash Algorithm), särskilt SHA-256, för att skapa signatursammandragshashar. Den här versionen har endast stöd för SHA-256 för symmetriska nyckelanvändningar, till exempel Kerberos-nycklar, och där ett X.509-certifikat inte används för att signera meddelandet. WCF stöder inte RSA-signaturer (används i X.509-certifikat) med sha-256-hash på grund av den aktuella bristen på stöd för RSA-SHA256 i WinFX.
FIPS-kompatibla SHA-256-hashar stöds inte
WCF stöder inte SHA-256 FIPS-kompatibla hashar, så algoritmsviter som använder SHA-256 stöds inte av WCF på system där fips-kompatibla algoritmer krävs.
FIPS-kompatibla algoritmer kan misslyckas om registret redigeras
Du kan aktivera och inaktivera FIPS-kompatibla algoritmer (Federal Information Processing Standards) med hjälp av snapin-modulen Local Security Inställningar Microsoft Management Console (MMC). Du kan också komma åt inställningen i registret. Observera dock att WCF inte har stöd för att använda registret för att återställa inställningen. Om värdet är inställt på något annat än 1 eller 0 kan inkonsekventa resultat uppstå mellan CLR och operativsystemet.
FIPS-kompatibel AES-krypteringsbegränsning
FIPS-kompatibel AES-kryptering fungerar inte i duplex-återanrop under personifiering på identifieringsnivå.
CNG/KSP-certifikat
Kryptografi-API: Nästa generation (CNG) är den långsiktiga ersättningen för CryptoAPI. Det här API:et är tillgängligt i ohanterad kod i Windows Vista, Windows Server 2008 och senare Windows-versioner.
.NET Framework 4.6.1 och tidigare versioner stöder inte dessa certifikat eftersom de använder äldre CryptoAPI för att hantera CNG/KSP-certifikat. Användningen av dessa certifikat med .NET Framework 4.6.1 och tidigare versioner orsakar ett undantag.
Det finns två möjliga sätt att se om ett certifikat använder KSP:
Gör en
p/invokeavCertGetCertificateContextPropertyoch inspekteradwProvTypeden returneradeCertGetCertificateContextProperty.certutilAnvänd kommandot från kommandoraden för att fråga certifikat. Mer information finns i Certutil-uppgifter för felsökning av certifikat.
Meddelandesäkerheten misslyckas om det krävs ASP.NET personifiering och ASP.NET kompatibilitet
WCF stöder inte följande kombination av inställningar eftersom de kan förhindra att klientautentisering sker:
ASP.NET Personifiering är aktiverat. Detta görs i filen Web.config genom att ange
impersonate-attributet för elementet <identity> tilltrue.ASP.NET kompatibilitetsläge aktiveras genom att ange
aspNetCompatibilityEnabledattributet< för serviceHostingEnvironment> tilltrue.Säkerhet i meddelandeläge används.
Arbetssättet är att inaktivera ASP.NET kompatibilitetsläge. Om ASP.NET kompatibilitetsläge krävs inaktiverar du funktionen ASP.NET personifiering och använder personifiering som tillhandahålls av WCF i stället. Mer information finns i Delegering och personifiering.
IPv6-literaladressfel
Säkerhetsbegäranden misslyckas när klienten och tjänsten finns på samma dator och IPv6-literaladresser används för tjänsten.
Literal IPv6-adresser fungerar om tjänsten och klienten finns på olika datorer.
WSDL-hämtningsfel med federerat förtroende
WCF kräver exakt ett WSDL-dokument för varje nod i den federerade förtroendekedjan. Var noga med att inte konfigurera en loop när du anger slutpunkter. Ett sätt att skapa loopar är att använda en WSDL-nedladdning av federerade förtroendekedjor med två eller flera länkar i samma WSDL-dokument. Ett vanligt scenario som kan skapa det här problemet är en federerad tjänst där säkerhetstokenservern och tjänsten finns i samma ServiceHost.
Ett exempel på den här situationen är en tjänst med följande tre slutpunktsadresser:
http://localhost/CalculatorService/service(tjänsten)http://localhost/CalculatorService/issue_ticket(STS)http://localhost/CalculatorService/mex(metadataslutpunkten)
Detta utlöser ett undantag.
Du kan få det här scenariot att fungera genom att placera issue_ticket slutpunkten någon annanstans.
WSDL-importattribut kan gå förlorade
WCF tappar bort attributen för ett <wst:Claims> element i en RST mall när en WSDL-import utförs. Detta inträffar under en WSDL-import om du anger <Claims> direkt i eller IssuedSecurityTokenRequestParameters.AdditionalRequestParameters i WSFederationHttpBinding.Security.Message.TokenRequestParameters stället för att använda anspråkstypsamlingarna direkt. Eftersom importen förlorar attributen skickas inte bindningen korrekt via WSDL och är därför felaktig på klientsidan.
Korrigeringen är att ändra bindningen direkt på klienten efter importen.