Dela via

Välja en typ av autentiseringsuppgifter

  • Artikel

Autentiseringsuppgifter är de data som Windows Communication Foundation (WCF) använder för att upprätta antingen en påstådd identitet eller funktioner. Ett pass är till exempel en autentiseringsuppgift som en myndighet utfärdar för att bevisa medborgarskap i ett land eller en region. I WCF kan autentiseringsuppgifter ta många former, till exempel användarnamnstoken och X.509-certifikat. I det här avsnittet beskrivs autentiseringsuppgifter, hur de används i WCF och hur du väljer rätt autentiseringsuppgifter för ditt program.

I många länder och regioner är ett körkort ett exempel på en autentiseringsuppgift. En licens innehåller data som representerar en persons identitet och funktioner. Den innehåller bevis på innehav i form av innehavarens bild. Licensen utfärdas av en betrodd myndighet, vanligtvis en statlig licensavdelning. Licensen är förseglad och kan innehålla ett hologram som visar att den inte har manipulerats eller förfalskats.

Att presentera en autentiseringsuppgift innebär att presentera både data och bevis på innehav av data. WCF stöder en mängd olika typer av autentiseringsuppgifter på både transport- och meddelandesäkerhetsnivå. Överväg till exempel två typer av autentiseringsuppgifter som stöds i WCF: användarnamn och (X.509) certifikatautentiseringsuppgifter.

För användarnamnets autentiseringsuppgifter representerar användarnamnet den begärda identiteten och lösenordet ger bevis på innehav. Den betrodda utfärdaren är i det här fallet det system som verifierar användarnamnet och lösenordet.

Med en X.509-certifikatautentiseringsuppgift kan ämnesnamnet, alternativt ämnesnamn eller specifika fält i certifikatet användas som identitetsanspråk, medan andra fält, till exempel fälten Valid From och Valid To , anger certifikatets giltighet.

Transport av typer av autentiseringsuppgifter

I följande tabell visas möjliga typer av klientautentiseringsuppgifter som kan användas av en bindning i transportsäkerhetsläge. När du skapar en tjänst anger du ClientCredentialType egenskapen till ett av dessa värden för att ange vilken typ av autentiseringsuppgifter som klienten måste ange för att kommunicera med din tjänst. Du kan ange typerna i antingen kod- eller konfigurationsfiler.

Inställning Beskrivning
None Anger att klienten inte behöver presentera några autentiseringsuppgifter. Detta översätts till en anonym klient.
Grundläggande Anger grundläggande autentisering för klienten. Mer information finns i RFC2617 – HTTP-autentisering: Grundläggande och sammanfattad autentisering.
Digest Anger sammanfattad autentisering för klienten. Mer information finns i RFC2617 – HTTP-autentisering: Grundläggande och sammanfattad autentisering.
Ntlm Anger NT LAN Manager-autentisering (NTLM). Detta används när du inte kan använda Kerberos-autentisering av någon anledning. Du kan också inaktivera dess användning som reserv genom att ställa in AllowNtlm egenskapen på false, vilket gör att WCF gör det bästa för att utlösa ett undantag om NTLM används. Observera att inställningen för den här egenskapen false kanske inte hindrar NTLM-autentiseringsuppgifter från att skickas via kabeln.
Windows Anger Windows-autentisering. Om du bara vill ange Kerberos-protokollet på en Windows-domän anger du AllowNtlm egenskapen till false (standardvärdet är true).
Certifikat Utför klientautentisering med hjälp av ett X.509-certifikat.
Lösenord Användaren måste ange ett användarnamn och lösenord. Verifiera användarnamnet/lösenordsparet med Windows-autentisering eller en annan anpassad lösning.

Typer av meddelandeklientautentiseringsuppgifter

Följande tabell visar möjliga typer av autentiseringsuppgifter som du kan använda när du skapar ett program som använder meddelandesäkerhet. Du kan använda dessa värden i antingen kod- eller konfigurationsfiler.

Inställning Beskrivning
None Anger att klienten inte behöver presentera någon autentiseringsuppgift. Detta översätts till en anonym klient.
Windows Tillåter att SOAP-meddelandeutbyten sker under säkerhetskontexten som upprättas med en Windows-autentiseringsuppgift.
Username Tillåter att tjänsten kräver att klienten autentiseras med en autentiseringsuppgift för användarnamn. Observera att WCF inte tillåter några kryptografiska åtgärder med användarnamn, till exempel att generera en signatur eller kryptera data. WCF säkerställer att transporten skyddas när autentiseringsuppgifterna för användarnamn används.
Certifikat Tillåter att tjänsten kräver att klienten autentiseras med hjälp av ett X.509-certifikat.
Utfärdad token En anpassad tokentyp som konfigurerats enligt en säkerhetsprincip. Standardtokentypen är SAML (Security Assertions Markup Language). Token utfärdas av en säker tokentjänst. Mer information finns i Federation och Utfärdade token.

Förhandlingsmodell för tjänstautentiseringsuppgifter

Förhandling är processen för att upprätta förtroende mellan en klient och en tjänst genom att utbyta autentiseringsuppgifter. Processen utförs iterativt mellan klienten och tjänsten för att endast avslöja den information som krävs för nästa steg i förhandlingsprocessen. I praktiken är slutresultatet leveransen av en tjänsts autentiseringsuppgifter till klienten som ska användas i efterföljande åtgärder.

Med ett undantag förhandlar de systembaserade bindningarna i WCF om tjänstens autentiseringsuppgifter automatiskt när du använder säkerhet på meddelandenivå. (Undantaget är BasicHttpBinding, som inte aktiverar säkerhet som standard.) Information om hur du inaktiverar det här beteendet finns i NegotiateServiceCredential egenskaperna och NegotiateServiceCredential .

Kommentar

När SSL-säkerhet används med .NET Framework 3.5 och senare använder en WCF-klient både mellanliggande certifikat i sitt certifikatarkiv och mellanliggande certifikat som togs emot under SSL-förhandlingen för att utföra certifikatkedjevalidering på tjänstens certifikat. .NET Framework 3.0 använder endast mellanliggande certifikat som är installerade i det lokala certifikatarkivet.

Out-of-Band-förhandling

Om automatisk förhandling är inaktiverad måste tjänstens autentiseringsuppgifter etableras på klienten innan meddelanden skickas till tjänsten. Detta kallas även för en out-of-band-etablering . Om den angivna autentiseringstypen till exempel är ett certifikat och automatisk förhandling är inaktiverad måste klienten kontakta tjänstägaren för att ta emot och installera certifikatet på den dator som kör klientprogrammet. Detta kan till exempel göras när du strikt vill kontrollera vilka klienter som kan komma åt en tjänst i ett affärs-till-företag-scenario. Denna out-of-band-förhandling kan göras via e-post och X.509-certifikatet lagras i Windows-certifikatarkivet med hjälp av ett verktyg som snapin-modulen Microsoft Management Console (MMC).

Kommentar

Egenskapen ClientCredentials används för att tillhandahålla tjänsten med ett certifikat som uppnåddes genom out-of-band-förhandling. Detta är nödvändigt när du använder BasicHttpBinding klassen eftersom bindningen inte tillåter automatiserade förhandlingar. Egenskapen används också i ett icke-korrelerat dubbelsidigt scenario. Det här är ett scenario där en server skickar ett meddelande till klienten utan att klienten behöver skicka en begäran till servern först. Eftersom servern inte har någon begäran från klienten måste den använda klientens certifikat för att kryptera meddelandet till klienten.

Ange värden för autentiseringsuppgifter

När du har valt ett säkerhetsläge måste du ange de faktiska autentiseringsuppgifterna. Om autentiseringstypen till exempel är inställd på "certifikat" måste du associera en specifik autentiseringsuppgift (till exempel ett specifikt X.509-certifikat) med tjänsten eller klienten.

Beroende på om du programmerar en tjänst eller en klient skiljer sig metoden för att ange värdet för autentiseringsuppgifter något.

Ange autentiseringsuppgifter för tjänsten

Om du använder transportläge och använder HTTP som transport måste du antingen använda Internet Information Services (IIS) eller konfigurera porten med ett certifikat. Mer information finns i Översikt över transportsäkerhet och HTTP-transportsäkerhet.

Om du vill etablera en tjänst med autentiseringsuppgifter i kod skapar du en instans av klassen och anger lämpliga autentiseringsuppgifter med hjälp av ServiceHostServiceCredentials klassen, som nås via Credentials egenskapen.

Ange ett certifikat

Om du vill etablera en tjänst med ett X.509-certifikat som ska användas för att autentisera tjänsten till klienter använder du SetCertificate -metoden för X509CertificateRecipientServiceCredential klassen.

Om du vill etablera en tjänst med ett klientcertifikat använder du SetCertificate -metoden för X509CertificateInitiatorServiceCredential klassen.

Ange Windows-autentiseringsuppgifter

Om klienten anger ett giltigt användarnamn och lösenord används den autentiseringsuppgiften för att autentisera klienten. Annars används den aktuella inloggade användarens autentiseringsuppgifter.

Ange klientautentiseringsuppgifter

I WCF använder klientprogram en WCF-klient för att ansluta till tjänster. Varje klient härleds från ClientBase<TChannel> klassen och ClientCredentials egenskapen på klienten tillåter specifikation av olika värden för klientautentiseringsuppgifter.

Ange ett certifikat

Om du vill etablera en tjänst med ett X.509-certifikat som används för att autentisera klienten till en tjänst använder du SetCertificate -metoden för X509CertificateInitiatorClientCredential klassen.

Hur klientautentiseringsuppgifter används för att autentisera en klient till tjänsten

Information om klientautentiseringsuppgifter som krävs för att kommunicera med en tjänst tillhandahålls med antingen ClientCredentials egenskapen eller Credentials egenskapen. Säkerhetskanalen använder den här informationen för att autentisera klienten till tjänsten. Autentiseringen utförs via ett av två lägen:

  • Klientens autentiseringsuppgifter används en gång innan det första meddelandet skickas, med hjälp av WCF-klientinstansen för att upprätta en säkerhetskontext. Alla programmeddelanden skyddas sedan via säkerhetskontexten.

  • Klientautentiseringsuppgifterna används för att autentisera varje programmeddelande som skickas till tjänsten. I det här fallet upprättas ingen kontext mellan klienten och tjänsten.

Det går inte att ändra etablerade identiteter

När den första metoden används associeras den etablerade kontexten permanent med klientidentiteten. När säkerhetskontexten har upprättats går det alltså inte att ändra identiteten som är associerad med klienten.

Viktigt!

Det finns en situation att vara medveten om när identiteten inte kan växlas (dvs. när säkerhetskontexten är på, standardbeteendet). Om du skapar en tjänst som kommunicerar med en andra tjänst kan inte den identitet som används för att öppna WCF-klienten till den andra tjänsten ändras. Detta blir ett problem om flera klienter tillåts använda den första tjänsten och tjänsten personifierar klienterna vid åtkomst till den andra tjänsten. Om tjänsten återanvänder samma klient för alla anropare görs alla anrop till den andra tjänsten under identiteten för den första anroparen som användes för att öppna klienten till den andra tjänsten. Med andra ord använder tjänsten identiteten för den första klienten för alla sina klienter för att kommunicera med den andra tjänsten. Detta kan leda till utökade privilegier. Om detta inte är det önskade beteendet för din tjänst måste du spåra varje anropare och skapa en ny klient till den andra tjänsten för varje distinkt anropare och se till att tjänsten endast använder rätt klient för rätt anropare för att kommunicera med den andra tjänsten.

Mer information om autentiseringsuppgifter och säkra sessioner finns i Säkerhetsöverväganden för säkra sessioner.

Se även