Dela via

Skydda tjänster

  • Artikel

Säkerheten för en WCF-tjänst (Windows Communication Foundation) består av två primära krav: överföringssäkerhet och auktorisering. (Ett tredje krav, granskning av säkerhetshändelser, beskrivs i Granskning.) I korthet omfattar överföringssäkerhet autentisering (verifiera identiteten för både tjänsten och klienten), konfidentialitet (meddelandekryptering) och integritet (digital signering för att identifiera manipulering). Auktorisering är kontrollen av åtkomst till resurser, till exempel så att endast privilegierade användare kan läsa en fil. Med hjälp av funktionerna i WCF implementeras de två primära kraven enkelt.

Med undantag för BasicHttpBinding klassen (eller <basicHttpBinding-elementet> i konfigurationen) aktiveras överföringssäkerhet som standard för alla fördefinierade bindningar. Avsnitten i det här avsnittet beskriver två grundläggande scenarier: implementering av överföringssäkerhet och auktorisering på en intranättjänst som finns på Internet Information Services (IIS) och implementering av överföringssäkerhet och auktorisering på en tjänst som finns på IIS.

Grundläggande säkerhet

Säkerhet förlitar sig på autentiseringsuppgifter. En autentiseringsuppgift bevisar att en entitet är den som den påstår sig vara. (En entitet kan vara en person, en programvaruprocess, ett företag eller något som kan auktoriseras.) Till exempel gör en klient för en tjänst ett anspråk påidentitet, och autentiseringsuppgifterna bevisar det anspråket på något sätt. I ett typiskt scenario sker ett utbyte av autentiseringsuppgifter. Först gör en tjänst anspråk på sin identitet och bevisar den för klienten med en autentiseringsuppgift. Klienten gör däremot ett anspråk på identitet och presenterar en autentiseringsuppgift för tjänsten. Om båda parter litar på den andres autentiseringsuppgifter kan en säker kontext upprättas där alla meddelanden utbyts i konfidentialitet och alla meddelanden signeras för att skydda deras integritet. När tjänsten har upprättat klientens identitet kan den sedan matcha anspråken i autentiseringsuppgifterna med en roll eller ett medlemskap i en grupp. I båda fallen ger tjänsten klienten behörighet att utföra en begränsad uppsättning åtgärder baserat på rollen eller gruppbehörigheterna med hjälp av rollen eller gruppen.

Windows-säkerhet mekanismer

Om både klienten och tjänstdatorn finns på en Windows-domän som kräver att båda loggar in på nätverket, tillhandahålls autentiseringsuppgifterna av Windows-infrastrukturen. I så fall upprättas autentiseringsuppgifterna när en datoranvändare loggar in på nätverket. Varje användare och varje dator i nätverket måste verifieras som tillhörande den betrodda uppsättningen användare och datorer. I ett Windows-system kallas alla sådana användare och datorer även för säkerhetsobjekt.

På en Windows-domän som backas upp av en Kerberos-kontrollant använder Kerberos-kontrollanten ett schema baserat på att bevilja biljetter till varje säkerhetsobjekt. Biljetterna som kontrollanten beviljar är betrodda av andra biljettbeviljare i systemet. När en entitet försöker utföra en åtgärd eller komma åt en resurs (till exempel en fil eller katalog på en dator) granskas biljetten för dess giltighet och om den godkänns beviljas huvudkontot en annan biljett för åtgärden. Den här metoden för att bevilja biljetter är effektivare än alternativet att försöka verifiera huvudkontot för varje åtgärd.

En äldre, mindre säker mekanism som används på Windows-domäner är NT LAN Manager (NTLM). I fall där Kerberos inte kan användas (vanligtvis utanför en Windows-domän, till exempel i en arbetsgrupp), kan NTLM användas som ett alternativ. NTLM är också tillgängligt som ett säkerhetsalternativ för IIS.

I ett Windows-system fungerar auktoriseringen genom att tilldela varje dator och användare till en uppsättning roller och grupper. Till exempel måste varje Windows-dator konfigureras och styras av en person (eller grupp av personer) i rollen som administratör. En annan roll är användarens, som har en mycket mer begränsad uppsättning behörigheter. Utöver rollen tilldelas användare till grupper. Med en grupp kan flera användare utföra samma roll. I praktiken administreras därför en Windows-dator genom att tilldela användare till grupper. Till exempel kan flera användare tilldelas till gruppen med användare på en dator, och en mycket mer begränsad uppsättning användare kan tilldelas till gruppen med administratörer. På en lokal dator kan en administratör också skapa nya grupper och tilldela andra användare (eller till och med andra grupper) till gruppen.

På en dator som kör Windows kan alla mappar i en katalog skyddas. Det innebär att du kan välja en mapp och styra vem som kan komma åt filerna och om de kan kopiera filen eller inte, eller (i det mest privilegierade fallet) ändra en fil, ta bort en fil eller lägga till filer i mappen. Detta kallas åtkomstkontroll och mekanismen för den kallas åtkomstkontrollistan (ACL). När du skapar ACL kan du tilldela åtkomstbehörigheter till valfri grupp eller grupp samt enskilda medlemmar i en domän.

WCF-infrastrukturen är utformad för att använda dessa Windows-säkerhetsmekanismer. Om du skapar en tjänst som distribueras på ett intranät och vars klienter är begränsade till medlemmar i Windows-domänen är säkerheten därför enkel att implementera. Endast giltiga användare kan logga in på domänen. När användarna har loggat in gör Kerberos-kontrollanten det möjligt för varje användare att upprätta säkra kontexter med andra datorer eller program. På en lokal dator kan grupper enkelt skapas, och när du skyddar specifika mappar kan dessa grupper användas för att tilldela åtkomstbehörigheter på datorn.

Implementera Windows-säkerhet på intranättjänster

Om du vill skydda ett program som endast körs på en Windows-domän kan du använda standardsäkerhetsinställningarna för antingen bindningen WSHttpBindingNetTcpBinding eller . Som standard kan alla i samma Windows-domän komma åt WCF-tjänster. Eftersom dessa användare har loggat in på nätverket är de betrodda. Meddelandena mellan en tjänst och en klient krypteras för konfidentialitet och signeras för integritet. Mer information om hur du skapar en tjänst som använder Windows-säkerhet finns i Så här skyddar du en tjänst med Windows-autentiseringsuppgifter.

Auktorisering med klassen PrincipalPermissionAttribute

Om du behöver begränsa åtkomsten till resurser på en dator är det enklaste sättet att använda PrincipalPermissionAttribute klassen. Med det här attributet kan du begränsa anropet av tjänståtgärder genom att kräva att användaren finns i en angiven Windows-grupp eller roll, eller att vara en specifik användare. Mer information finns i Så här: Begränsa åtkomst med klassen PrincipalPermissionAttribute.

Personifiering

Personifiering är en annan mekanism som du kan använda för att styra åtkomsten till resurser. Som standard körs en tjänst som hanteras av IIS under identiteten för ASPNET-kontot. ASPNET-kontot kan bara komma åt de resurser som det har behörighet för. Det är dock möjligt att ange ACL för en mapp för att undanta ASPNET-tjänstkontot, men tillåta att vissa andra identiteter får åtkomst till mappen. Frågan blir sedan hur dessa användare ska få åtkomst till mappen om ASPNET-kontot inte tillåts göra det. Svaret är att använda personifiering, där tjänsten tillåts använda klientens autentiseringsuppgifter för att få åtkomst till en viss resurs. Ett annat exempel är när du kommer åt en SQL Server-databas som endast vissa användare har behörighet till. Mer information om hur du använder personifiering finns i Så här: Personifiera en klient på en tjänst och delegering och personifiering.

Säkerhet på Internet

Säkerheten på Internet består av samma krav som säkerhet på ett intranät. En tjänst måste presentera sina autentiseringsuppgifter för att bevisa sin äkthet och klienterna måste bevisa sin identitet för tjänsten. När en klients identitet har bevisats kan tjänsten styra hur mycket åtkomst klienten har till resurser. Men på grund av internets heterogena karaktär skiljer sig de autentiseringsuppgifter som presenteras från de som används i en Windows-domän. Medan en Kerberos-kontrollant hanterar autentisering av användare på en domän med biljetter för autentiseringsuppgifter, förlitar sig tjänster och klienter på något av flera olika sätt att presentera autentiseringsuppgifter. Målet med det här avsnittet är dock att presentera en gemensam metod som gör att du kan skapa en WCF-tjänst som är tillgänglig på Internet.

Använda IIS och ASP.NET

Kraven på Internetsäkerhet och mekanismerna för att lösa dessa problem är inte nya. IIS är Microsofts webbserver för Internet och har många säkerhetsfunktioner som hanterar dessa problem. Dessutom innehåller ASP.NET säkerhetsfunktioner som WCF-tjänster kan använda. Om du vill dra nytta av dessa säkerhetsfunktioner är du värd för en WCF-tjänst på IIS.

Använda ASP.NET medlemskap och rollprovidrar

ASP.NET innehåller ett medlemskap och en rollprovider. Providern är en databas med användarnamn/lösenordspar för autentisering av anropare som också gör att du kan ange varje anroparens åtkomstbehörighet. Med WCF kan du enkelt använda en befintlig medlemskaps- och rollprovider via konfiguration. Ett exempelprogram som visar detta finns i exemplet medlemskap och rollprovider .

Autentiseringsuppgifter som används av IIS

Till skillnad från en Windows-domän som backas upp av en Kerberos-kontrollant är Internet en miljö utan en enda kontrollant för att hantera de miljontals användare som loggar in när som helst. I stället är autentiseringsuppgifterna på Internet oftast i form av X.509-certifikat (även kallade Secure Sockets Layer eller SSL-certifikat). Dessa certifikat utfärdas vanligtvis av en certifikatutfärdare, som kan vara ett tredjepartsföretag som går i god för certifikatets äkthet och den person som det har utfärdats till. Om du vill exponera tjänsten på Internet måste du också ange ett sådant betrott certifikat för att autentisera tjänsten.

Frågan uppstår just nu, hur får du ett sådant certifikat? En metod är att gå till en tredjepartscertifikatutfärdare, till exempel Authenticode eller VeriSign, när du är redo att distribuera din tjänst och köpa ett certifikat för din tjänst. Men om du är i utvecklingsfasen med WCF och ännu inte är redo att åta dig att köpa ett certifikat finns det verktyg och tekniker för att skapa X.509-certifikat som du kan använda för att simulera en produktionsdistribution. Mer information finns i Arbeta med certifikat.

Säkerhetslägen

Programmering av WCF-säkerhet medför några viktiga beslutspunkter. Ett av de mest grundläggande är valet av säkerhetsläge. De två viktigaste säkerhetslägena är transportläge och meddelandeläge.

Ett tredje läge, som kombinerar semantiken för båda huvudlägena, är transport med meddelandeautentiseringsuppgifter.

Säkerhetsläget avgör hur meddelanden skyddas och varje val har fördelar och nackdelar enligt beskrivningen nedan. Mer information om hur du ställer in säkerhetsläget finns i Så här ställer du in säkerhetsläget.

Transportläge

Det finns flera lager mellan nätverket och programmet. En av dessa är transportlagret *,* som hanterar överföringen av meddelanden mellan slutpunkter. För närvarande krävs det bara att du förstår att WCF använder flera transportprotokoll, som var och en kan skydda överföringen av meddelanden. (Mer information om transporter finns i Transporter.)

Ett vanligt protokoll är HTTP. en annan är TCP. Vart och ett av dessa protokoll kan skydda överföring av meddelanden med en mekanism (eller mekanismer) som är specifik för protokollet. HTTP-protokollet skyddas till exempel med hjälp av SSL via HTTP, ofta förkortat "HTTPS". När du väljer transportläget för säkerhet väljer du därför att använda mekanismen enligt protokollet. Om du till exempel väljer WSHttpBinding klassen och anger dess säkerhetsläge till Transport väljer du SSL över HTTP (HTTPS) som säkerhetsmekanism. Fördelen med transportläget är att det är effektivare än meddelandeläget eftersom säkerheten är integrerad på en jämförelsevis låg nivå. Vid användning av transportläge måste säkerhetsmekanismen implementeras enligt specifikationen för transporten, och därför kan meddelanden endast flöda säkert från punkt till punkt över transporten.

Meddelandeläge

Meddelandeläget ger däremot säkerhet genom att inkludera säkerhetsdata som en del av varje meddelande. Med hjälp av XML- och SOAP-säkerhetshuvuden ingår de autentiseringsuppgifter och andra data som behövs för att säkerställa meddelandets integritet och konfidentialitet i varje meddelande. Varje meddelande innehåller säkerhetsdata, så det resulterar i en avgift på prestanda eftersom varje meddelande måste bearbetas individuellt. (När transportlagret är skyddat flödar alla meddelanden fritt i transportläge.) Meddelandesäkerheten har dock en fördel jämfört med transportsäkerheten: den är mer flexibel. Det vill:s säkerhetskrav bestäms inte av transporten. Du kan använda valfri typ av klientautentiseringsuppgifter för att skydda meddelandet. (I transportläge avgör transportprotokollet vilken typ av klientautentiseringsuppgifter du kan använda.)

Transport med autentiseringsuppgifter för meddelanden

Det tredje läget kombinerar det bästa av både transport- och meddelandesäkerhet. I det här läget används transportsäkerhet för att effektivt säkerställa sekretess och integritet för varje meddelande. Samtidigt innehåller varje meddelande dess autentiseringsuppgifter, vilket gör att meddelandet kan autentiseras. Med autentisering kan auktorisering också implementeras. Genom att autentisera en avsändare kan åtkomst till resurser beviljas (eller nekas) enligt avsändarens identitet.

Ange klientens typ av autentiseringsuppgifter och autentiseringsuppgiftsvärde

När du har valt ett säkerhetsläge kanske du också vill ange en typ av klientautentiseringsuppgifter. Typen av klientautentiseringsuppgifter anger vilken typ en klient måste använda för att autentisera sig till servern.

Alla scenarier kräver dock inte en typ av klientautentiseringsuppgifter. Med hjälp av SSL via HTTP (HTTPS) autentiserar sig en tjänst till klienten. Som en del av den här autentiseringen skickas tjänstens certifikat till klienten i en process som kallas förhandling. Den SSL-skyddade transporten säkerställer att alla meddelanden är konfidentiella.

Om du skapar en tjänst som kräver att klienten autentiseras beror valet av klientautentiseringstyp på vilken transport och vilket läge som valts. Om du till exempel använder HTTP-transporten och väljer transportläge kan du välja mellan flera alternativ, till exempel Basic, Digest och andra. (Mer information om dessa typer av autentiseringsuppgifter finns i Förstå HTTP-autentisering.)

Om du skapar en tjänst på en Windows-domän som endast är tillgänglig för andra användare av nätverket är den enklaste att använda windows-klientens autentiseringstyp. Du kan dock också behöva tillhandahålla en tjänst med ett certifikat. Det här visas i Så här anger du värden för klientautentiseringsuppgifter.

Värden för autentiseringsuppgifter

Ett värde för autentiseringsuppgifter är den faktiska autentiseringsuppgift som tjänsten använder. När du har angett en typ av autentiseringsuppgifter kan du också behöva konfigurera tjänsten med de faktiska autentiseringsuppgifterna. Om du har valt Windows (och tjänsten kommer att köras på en Windows-domän) anger du inte något verkligt värde för autentiseringsuppgifter.

Identitet

I WCF har termen identitet olika betydelser för servern och klienten. I korthet tilldelas en identitet till säkerhetskontexten efter autentisering när en tjänst körs. Om du vill visa den faktiska identiteten WindowsIdentity kontrollerar du klassens ServiceSecurityContext egenskaper och PrimaryIdentity . Mer information finns i Så här: Granska säkerhetskontexten.

På klienten används däremot identiteten för att verifiera tjänsten. Vid designtillfället kan en klientutvecklare ange identitetselementet ><till ett värde som hämtats från tjänsten. Vid körning kontrollerar klienten värdet för elementet mot tjänstens faktiska identitet. Om kontrollen misslyckas avslutar klienten kommunikationen. Värdet kan vara ett UPN (User Principal Name) om tjänsten körs under en viss användares identitet eller ett tjänsthuvudnamn (SPN) om tjänsten körs under ett datorkonto. Mer information finns i Tjänstidentitet och autentisering. Autentiseringsuppgifterna kan också vara ett certifikat eller ett fält som finns på ett certifikat som identifierar certifikatet.

Skyddsnivåer

Egenskapen ProtectionLevel förekommer i flera attributklasser (till exempel klasserna ServiceContractAttributeOperationContractAttribute och ). Skyddsnivån är ett värde som anger om de meddelanden (eller meddelandedelar) som stöder en tjänst signeras, signeras och krypteras eller skickas utan signaturer eller kryptering. Mer information om egenskapen finns i Förstå skyddsnivå och för programmeringsexempel, se Så här: Ange egenskapen ProtectionLevel. Mer information om hur du utformar ett tjänstkontrakt med kontexten ProtectionLevel finns i Designa tjänstkontrakt.

Se även