Services beveiligen
Beveiliging van een WCF-service (Windows Communication Foundation) bestaat uit twee primaire vereisten: overdracht van beveiliging en autorisatie. (Een derde vereiste, controle van beveiligingsevenementen, wordt beschreven in Controle.) Kortom, overdrachtsbeveiliging omvat verificatie (verifiëren van de identiteit van zowel de service als de client), vertrouwelijkheid (berichtversleuteling) en integriteit (digitale ondertekening om manipulatie te detecteren). Autorisatie is het beheer van de toegang tot resources, bijvoorbeeld, zodat alleen bevoegde gebruikers een bestand kunnen lezen. Met behulp van functies van WCF zijn de twee primaire vereisten eenvoudig geïmplementeerd.
Met uitzondering van de BasicHttpBinding klasse (of het <basicHttpBinding-element> in de configuratie), is overdrachtbeveiliging standaard ingeschakeld voor alle vooraf gedefinieerde bindingen. De onderwerpen in deze sectie hebben betrekking op twee basisscenario's: het implementeren van overdrachtbeveiliging en autorisatie op een intranetservice die wordt gehost op Internet Information Services (IIS) en het implementeren van overdrachtbeveiliging en autorisatie voor een service die wordt gehost op IIS.
Basisbeginselen van beveiliging
Beveiliging is afhankelijk van referenties. Een referentie bewijst dat een entiteit is wie het beweert te zijn. (Een entiteit kan een persoon, een softwareproces, een bedrijf of iets zijn dat kan worden geautoriseerd.) Een client van een service maakt bijvoorbeeld een claim van identiteit en de referentie bewijst die claim op een of andere manier. In een typisch scenario vindt een uitwisseling van referenties plaats. Ten eerste maakt een service een claim van zijn identiteit en bewijst het aan de client met een referentie. Omgekeerd maakt de client een claim van identiteit en geeft een referentie aan de service. Als beide partijen de referenties van de andere partij vertrouwen, kan er een veilige context worden vastgesteld waarin alle berichten worden uitgewisseld in vertrouwelijkheid en alle berichten zijn ondertekend om hun integriteit te beschermen. Nadat de service de identiteit van de client heeft vastgesteld, kan deze vervolgens overeenkomen met de claims in de referentie aan een rol of lidmaatschap van een groep. In beide gevallen, met behulp van de rol of de groep waartoe de client behoort, geeft de service de client toestemming om een beperkte set bewerkingen uit te voeren op basis van de rol- of groepsbevoegdheden.
mechanismen voor Windows-beveiliging
Als de client en de servicecomputer beide zich in een Windows-domein bevinden waarvoor beide moeten worden aangemeld bij het netwerk, worden de referenties geleverd door de Windows-infrastructuur. In dat geval worden de referenties tot stand gebracht wanneer een computergebruiker zich aanmeldt bij het netwerk. Elke gebruiker en elke computer in het netwerk moeten worden gevalideerd als behorend tot de vertrouwde set gebruikers en computers. Op een Windows-systeem wordt elke gebruiker en computer ook wel een beveiligingsprincipaal genoemd.
In een Windows-domein dat wordt ondersteund door een Kerberos-controller , gebruikt de Kerberos-controller een schema op basis van het verlenen van tickets aan elke beveiligingsprincipal. De tickets die de controller verleent, worden vertrouwd door andere ticket granters in het systeem. Wanneer een entiteit een bewerking probeert uit te voeren of toegang probeert te krijgen tot een resource (zoals een bestand of map op een computer), wordt het ticket gecontroleerd op de geldigheid ervan en, als deze wordt doorgegeven, krijgt de principal een ander ticket voor de bewerking. Deze methode voor het verlenen van tickets is efficiënter dan het alternatief voor het valideren van de principal voor elke bewerking.
Een ouder, minder veilig mechanisme dat wordt gebruikt in Windows-domeinen is NT LAN Manager (NTLM). In gevallen waarin Kerberos niet kan worden gebruikt (meestal buiten een Windows-domein, zoals in een werkgroep), kan NTLM als alternatief worden gebruikt. NTLM is ook beschikbaar als beveiligingsoptie voor IIS.
Op een Windows-systeem werkt autorisatie door elke computer en gebruiker toe te wijzen aan een set rollen en groepen. Elke Windows-computer moet bijvoorbeeld worden ingesteld en beheerd door een persoon (of groep personen) in de rol van de beheerder. Een andere rol is die van de gebruiker, die een veel beperktere set machtigingen heeft. Naast de rol worden gebruikers toegewezen aan groepen. Met een groep kunnen meerdere gebruikers in dezelfde rol worden uitgevoerd. In de praktijk wordt daarom een Windows-computer beheerd door gebruikers toe te wijzen aan groepen. Er kunnen bijvoorbeeld meerdere gebruikers worden toegewezen aan de groep gebruikers van een computer en een veel beperktere set gebruikers kunnen worden toegewezen aan de groep beheerders. Op een lokale computer kan een beheerder ook nieuwe groepen maken en andere gebruikers (of zelfs andere groepen) toewijzen aan de groep.
Op een computer met Windows kan elke map in een map worden beveiligd. Dat wil gezegd, u kunt een map selecteren en bepalen wie toegang heeft tot de bestanden en of ze het bestand wel of niet kunnen kopiëren, of (in het meest bevoegde geval) een bestand wijzigen, een bestand verwijderen of bestanden toevoegen aan de map. Dit wordt toegangsbeheer genoemd en het mechanisme hiervoor wordt de ACL (Access Control List) genoemd. Wanneer u de ACL maakt, kunt u toegangsbevoegdheden toewijzen aan elke groep of groep, evenals afzonderlijke leden van een domein.
De WCF-infrastructuur is ontworpen voor het gebruik van deze Windows-beveiligingsmechanismen. Als u daarom een service maakt die is geïmplementeerd op een intranet en waarvan de clients zijn beperkt tot leden van het Windows-domein, wordt de beveiliging eenvoudig geïmplementeerd. Alleen geldige gebruikers kunnen zich aanmelden bij het domein. Nadat gebruikers zijn aangemeld, stelt de Kerberos-controller elke gebruiker in staat om beveiligde contexten tot stand te brengen met een andere computer of toepassing. Op een lokale computer kunnen groepen eenvoudig worden gemaakt en wanneer u specifieke mappen beveiligt, kunnen deze groepen worden gebruikt om toegangsbevoegdheden op de computer toe te wijzen.
Windows-beveiliging implementeren op intranetservices
Als u een toepassing wilt beveiligen die uitsluitend op een Windows-domein wordt uitgevoerd, kunt u de standaardbeveiligingsinstellingen van de WSHttpBinding of de NetTcpBinding binding gebruiken. Standaard heeft iedereen in hetzelfde Windows-domein toegang tot WCF-services. Omdat deze gebruikers zich hebben aangemeld bij het netwerk, worden ze vertrouwd. De berichten tussen een service en een client worden versleuteld voor vertrouwelijkheid en ondertekend voor integriteit. Zie How to: Secure a Service with Windows Credentials (Een service beveiligen met Windows-referenties) voor meer informatie over het maken van een service die gebruikmaakt van Windows-beveiliging.
Autorisatie met behulp van de klasse PrincipalPermissionAttribute
Als u de toegang van resources op een computer wilt beperken, kunt u de PrincipalPermissionAttribute klasse het eenvoudigst gebruiken. Met dit kenmerk kunt u de aanroep van servicebewerkingen beperken door te eisen dat de gebruiker zich in een opgegeven Windows-groep of -rol bevindt of als een specifieke gebruiker. Zie How to: Restrict Access with the PrincipalPermissionAttribute Class voor meer informatie.
Imitatie
Imitatie is een ander mechanisme dat u kunt gebruiken om de toegang tot resources te beheren. Standaard wordt een service die wordt gehost door IIS uitgevoerd onder de identiteit van het ASPNET-account. Het ASPNET-account heeft alleen toegang tot de resources waarvoor het is gemachtigd. Het is echter mogelijk om de ACL in te stellen voor een map om het ASPNET-serviceaccount uit te sluiten, maar om bepaalde andere identiteiten toegang te geven tot de map. De vraag wordt vervolgens hoe deze gebruikers toegang kunnen krijgen tot de map als het ASPNET-account dit niet mag doen. Het antwoord is het gebruik van imitatie, waarbij de service de referenties van de client mag gebruiken voor toegang tot een bepaalde resource. Een ander voorbeeld is bij het openen van een SQL Server-database waartoe alleen bepaalde gebruikers zijn gemachtigd. Zie Instructies voor het imiteren van een client op een service en delegatie en imitatie voor meer informatie over het gebruik van imitatie.
Beveiliging op internet
Beveiliging op internet bestaat uit dezelfde vereisten als beveiliging op een intranet. Een service moet zijn referenties presenteren om de echtheid ervan te bewijzen en clients moeten hun identiteit aan de service bewijzen. Zodra de identiteit van een client is bewezen, kan de service bepalen hoeveel toegang de client heeft tot resources. Vanwege de heterogene aard van internet verschillen de weergegeven referenties echter van de referenties die worden gebruikt in een Windows-domein. Terwijl een Kerberos-controller de verificatie van gebruikers op een domein met tickets voor referenties afhandelt, zijn internet, services en clients afhankelijk van een van de verschillende manieren om referenties te presenteren. Het doel van dit onderwerp is echter om een algemene benadering te presenteren waarmee u een WCF-service kunt maken die toegankelijk is op internet.
IIS en ASP.NET gebruiken
De vereisten voor internetbeveiliging en de mechanismen om deze problemen op te lossen, zijn niet nieuw. IIS is de webserver van Microsoft voor internet en heeft veel beveiligingsfuncties die deze problemen oplossen; Daarnaast bevat ASP.NET beveiligingsfuncties die WCF-services kunnen gebruiken. Als u wilt profiteren van deze beveiligingsfuncties, host u een WCF-service op IIS.
ASP.NET-lidmaatschaps- en rolproviders gebruiken
ASP.NET bevat een lidmaatschaps- en rolprovider. De provider is een database met gebruikersnaam-/wachtwoordparen voor het verifiëren van bellers waarmee u ook de toegangsbevoegdheden van elke beller kunt opgeven. Met WCF kunt u eenvoudig een bestaande lidmaatschaps- en rolprovider gebruiken via configuratie. Zie het voorbeeld van lidmaatschaps - en rolprovider voor een voorbeeldtoepassing die dit laat zien.
Referenties die worden gebruikt door IIS
In tegenstelling tot een Windows-domein dat wordt ondersteund door een Kerberos-controller, is internet een omgeving zonder één controller voor het beheren van de miljoenen gebruikers die zich op elk gewenst moment aanmelden. In plaats daarvan zijn referenties op internet het vaakst in de vorm van X.509-certificaten (ook wel bekend als Secure Sockets Layer- of SSL-certificaten). Deze certificaten worden doorgaans uitgegeven door een certificeringsinstantie, die een bedrijf van derden kan zijn dat voor de echtheid van het certificaat en de persoon aan wie het certificaat is uitgegeven. Als u uw service beschikbaar wilt maken op internet, moet u ook een dergelijk vertrouwd certificaat opgeven om uw service te verifiëren.
Hoe krijgt u een dergelijk certificaat? Een benadering is om naar een externe certificeringsinstantie te gaan, zoals Authenticode of VeriSign, wanneer u klaar bent om uw service te implementeren en een certificaat voor uw service aan te schaffen. Als u zich echter in de ontwikkelingsfase bevindt met WCF en nog niet klaar bent om een certificaat aan te schaffen, bestaan er hulpprogramma's en technieken voor het maken van X.509-certificaten die u kunt gebruiken om een productie-implementatie te simuleren. Zie Werken met certificaten voor meer informatie.
Beveiligingsmodi
Het programmeren van WCF-beveiliging omvat enkele kritieke beslissingspunten. Een van de meest eenvoudige is de keuze van de beveiligingsmodus. De twee belangrijkste beveiligingsmodi zijn transportmodus en berichtmodus.
Een derde modus, die de semantiek van beide primaire modi combineert, is transport met berichtreferentiemodus.
De beveiligingsmodus bepaalt hoe berichten worden beveiligd en elke keuze heeft voor- en nadelen, zoals hieronder wordt uitgelegd. Zie Instructies voor het instellen van de beveiligingsmodus voor meer informatie over het instellen van de beveiligingsmodus : De beveiligingsmodus instellen.
Transportmodus
Er zijn verschillende lagen tussen het netwerk en de toepassing. Een van deze is de transportlaag *,* waarmee de overdracht van berichten tussen eindpunten wordt beheerd. Voor dit doel is alleen vereist dat u begrijpt dat WCF gebruikmaakt van verschillende transportprotocollen, die elk de overdracht van berichten kunnen beveiligen. (Zie voor meer informatie over transporten Transporten.)
Een veelgebruikt protocol is HTTP; een ander is TCP. Elk van deze protocollen kan berichtoverdracht beveiligen door een mechanisme (of mechanismen) die specifiek zijn voor het protocol. Het HTTP-protocol wordt bijvoorbeeld beveiligd met SSL via HTTP, meestal afgekort als 'HTTPS'. Wanneer u dus de transportmodus voor beveiliging selecteert, kiest u ervoor om het mechanisme te gebruiken zoals bepaald door het protocol. Als u bijvoorbeeld de WSHttpBinding klasse selecteert en de beveiligingsmodus instelt op Transport, selecteert u SSL via HTTP (HTTPS) als beveiligingsmechanisme. Het voordeel van de transportmodus is dat het efficiënter is dan de berichtmodus, omdat beveiliging op een relatief laag niveau is geïntegreerd. Wanneer u de transportmodus gebruikt, moet het beveiligingsmechanisme worden geïmplementeerd volgens de specificatie voor het transport en kunnen berichten dus alleen veilig stromen van punt-naar-punt over het transport.
Berichtmodus
De berichtenmodus biedt daarentegen beveiliging door de beveiligingsgegevens op te volgen als onderdeel van elk bericht. Met behulp van XML- en SOAP-beveiligingsheaders worden de referenties en andere gegevens die nodig zijn om de integriteit en vertrouwelijkheid van het bericht te waarborgen, bij elk bericht opgenomen. Elk bericht bevat beveiligingsgegevens, zodat dit resulteert in een tol voor de prestaties, omdat elk bericht afzonderlijk moet worden verwerkt. (Zodra de transportlaag is beveiligd, stromen alle berichten vrij.) Berichtbeveiliging heeft echter één voordeel ten opzichte van transportbeveiliging: het is flexibeler. Dat wil zeggen dat de beveiligingsvereisten niet worden bepaald door het transport. U kunt elk type clientreferentie gebruiken om het bericht te beveiligen. (In de transportmodus bepaalt het transportprotocol het type clientreferentie dat u kunt gebruiken.)
Transport met berichtreferenties
De derde modus combineert het beste van zowel transport- als berichtbeveiliging. In deze modus wordt transportbeveiliging gebruikt om de vertrouwelijkheid en integriteit van elk bericht efficiënt te waarborgen. Tegelijkertijd bevat elk bericht de referentiegegevens, waardoor het bericht kan worden geverifieerd. Met verificatie kan autorisatie ook worden geïmplementeerd. Door een afzender te verifiëren, kan toegang tot resources worden verleend (of geweigerd) op basis van de identiteit van de afzender.
Het clientreferentietype en de referentiewaarde opgeven
Nadat u een beveiligingsmodus hebt geselecteerd, kunt u ook een clientreferentietype opgeven. Het clientreferentietype geeft aan welk type een client moet gebruiken om zichzelf te verifiëren bij de server.
Voor niet alle scenario's is echter een clientreferentietype vereist. Met SSL via HTTP (HTTPS) wordt een service geverifieerd bij de client. Als onderdeel van deze verificatie wordt het certificaat van de service naar de client verzonden in een proces dat onderhandeling wordt genoemd. Het met SSL beveiligde transport zorgt ervoor dat alle berichten vertrouwelijk zijn.
Als u een service maakt waarvoor de client moet worden geverifieerd, is uw keuze voor een clientreferentietype afhankelijk van het geselecteerde transport en de modus. Als u bijvoorbeeld het HTTP-transport gebruikt en de transportmodus kiest, hebt u verschillende opties, zoals Basic, Digest en andere. (Zie voor meer informatie over deze referentietypen Informatie over HTTP-verificatie.)
Als u een service maakt in een Windows-domein dat alleen beschikbaar is voor andere gebruikers van het netwerk, is het eenvoudigste te gebruiken het referentietype van de Windows-client. Mogelijk moet u echter ook een service met een certificaat opgeven. Dit wordt weergegeven in Procedure: Clientreferentiewaarden opgeven.
Referentiewaarden
Een referentiewaarde is de werkelijke referentie die de service gebruikt. Nadat u een referentietype hebt opgegeven, moet u mogelijk ook uw service configureren met de werkelijke referenties. Als u Windows hebt geselecteerd (en de service wordt uitgevoerd op een Windows-domein), geeft u geen werkelijke referentiewaarde op.
Identiteit
In WCF heeft de term identiteit verschillende betekenissen voor de server en de client. Kortom, bij het uitvoeren van een service, wordt een identiteit na verificatie toegewezen aan de beveiligingscontext. Als u de werkelijke identiteit wilt bekijken, controleert u de WindowsIdentity en PrimaryIdentity eigenschappen van de ServiceSecurityContext klasse. Zie Procedures voor meer informatie : De beveiligingscontext onderzoeken.
Daarentegen wordt op de client identiteit gebruikt om de service te valideren. Tijdens het ontwerpen kan een clientontwikkelaar het <identiteitselement> instellen op een waarde die is verkregen van de service. Tijdens runtime controleert de client de waarde van het element op basis van de werkelijke identiteit van de service. Als de controle mislukt, beëindigt de client de communicatie. De waarde kan een USER Principal Name (UPN) zijn als de service wordt uitgevoerd onder de identiteit van een bepaalde gebruiker of een SPN (Service Principal Name) als de service wordt uitgevoerd onder een computeraccount. Zie Service-identiteit en -verificatie voor meer informatie. De referentie kan ook een certificaat zijn of een veld in een certificaat dat het certificaat identificeert.
Beveiligingsniveaus
De ProtectionLevel
eigenschap vindt plaats op verschillende kenmerkklassen (zoals de ServiceContractAttribute en de OperationContractAttribute klassen). Het beveiligingsniveau is een waarde die aangeeft of de berichten (of berichtonderdelen) die ondersteuning bieden voor een service, worden ondertekend, ondertekend en versleuteld of zonder handtekeningen of versleuteling worden verzonden. Zie Understanding Protection Level en voor programmeervoorbeelden voor meer informatie over de eigenschap: De eigenschap ProtectionLevel instellen. Zie Servicecontracten ontwerpen voor meer informatie over het ontwerpen van een servicecontract met de ProtectionLevel
context.
Zie ook
- System.ServiceModel
- ServiceCredentials
- ServiceContractAttribute
- OperationContractAttribute
- Service-identiteit en -verificatie
- Informatie over beveiligingsniveau
- Delegatie en imitatie
- Servicecontracten ontwerpen
- Beveiliging
- Beveiligingsoverzicht
- Procedure: De eigenschap ProtectionLevel instellen
- Procedure: Een service beveiligen met Windows-referenties
- Procedure: De beveiligingsmodus instellen
- Procedure: Geef het clientreferentietype op
- Procedure: Toegang beperken met de klasse PrincipalPermissionAttribute
- Procedure: Een client op een service imiteren
- Procedure: De beveiligingscontext onderzoeken