Informatie over HTTP-verificatie
Verificatie is het proces voor het identificeren van wie de client is, meestal om te bepalen of de client in aanmerking komt voor toegang tot een resource. Het HTTP-protocol ondersteunt verificatie als een manier om toegang tot een beveiligde resource te onderhandelen.
De eerste aanvraag van een client is doorgaans een anonieme aanvraag, die geen verificatiegegevens bevat. HTTP-server-apps kunnen de anonieme aanvraag weigeren terwijl wordt aangegeven dat verificatie is vereist. De server-app verzendt WWW-Authentication-headers om de ondersteunde verificatieschema's aan te geven. In dit artikel worden verschillende verificatieschema's voor HTTP beschreven en worden de ondersteuning ervan in WCF (Windows Communication Foundation) besproken.
HTTP-verificatieschema's
De server kan meerdere verificatieschema's opgeven waaruit de client kan kiezen. In de volgende tabel worden enkele van de verificatieschema's beschreven die vaak worden gevonden in Windows-toepassingen:
| Verificatieschema | Beschrijving |
|---|---|
| Anoniem | Een anonieme aanvraag bevat geen verificatiegegevens. Anoniem is gelijk aan het verlenen van iedereen toegang tot de resource. |
| Basis | Met basisverificatie wordt een met Base64 gecodeerde tekenreeks met een gebruikersnaam en wachtwoord voor de client verzonden. Base64 is geen vorm van versleuteling en moet worden beschouwd als het verzenden van de gebruikersnaam en het wachtwoord in duidelijke tekst. Als een resource moet worden beveiligd, kunt u het gebruik van een ander verificatieschema dan basisverificatie overwegen. |
| Digest | Digest-verificatie is een challenge-response-schema dat is bedoeld om basisverificatie te vervangen. De server verzendt een tekenreeks met willekeurige gegevens die een nonce worden genoemd naar de client als een uitdaging. De client reageert met een hash die de gebruikersnaam, het wachtwoord en de nonce bevat, onder meer aanvullende informatie. De complexiteit van deze uitwisseling introduceert en de gegevenshashing maakt het moeilijker om de referenties van de gebruiker te stelen en opnieuw te gebruiken met dit verificatieschema. Digest-verificatie vereist het gebruik van Windows-domeinaccounts. De digest-realm is de Windows-domeinnaam. Daarom kunt u geen server gebruiken die wordt uitgevoerd op een besturingssysteem dat geen ondersteuning biedt voor Windows-domeinen, zoals Windows XP Home Edition, met Digest-verificatie. Als de client echter wordt uitgevoerd op een besturingssysteem dat geen Ondersteuning biedt voor Windows-domeinen, moet er expliciet een domeinaccount worden opgegeven tijdens de verificatie. |
| NTLM | NT LAN Manager-verificatie (NTLM) is een challenge-response-schema dat een veiligere variatie van Digest-verificatie is. NTLM gebruikt Windows-referenties om de uitdagingsgegevens te transformeren in plaats van de niet-gecodeerde gebruikersnaam en het wachtwoord. Voor NTLM-verificatie zijn meerdere uitwisselingen tussen de client en de server vereist. De server en eventuele tussenliggende proxy's moeten permanente verbindingen ondersteunen om de verificatie te voltooien. |
| Onderhandelen | Onderhandel automatisch over verificatie tussen het Kerberos-protocol en NTLM-verificatie, afhankelijk van de beschikbaarheid. Het Kerberos-protocol wordt gebruikt als het beschikbaar is; anders wordt NTLM geprobeerd. Kerberos-verificatie verbetert aanzienlijk bij NTLM. Kerberos-verificatie is zowel sneller dan NTLM en maakt het gebruik van wederzijdse verificatie en overdracht van referenties aan externe computers mogelijk. |
| Windows Live ID | De onderliggende Windows HTTP-service bevat verificatie met federatieve protocollen. De standaard HTTP-transporten in WCF bieden echter geen ondersteuning voor het gebruik van federatieve verificatieschema's, zoals Microsoft Windows Live ID. Ondersteuning voor deze functie is momenteel beschikbaar met behulp van berichtbeveiliging. Zie Federatie- en uitgegeven tokens voor meer informatie. |
Een verificatieschema kiezen
Wanneer u de mogelijke verificatieschema's voor een HTTP-server selecteert, moet u rekening houden met het volgende:
Overweeg of de resource moet worden beveiligd. Voor het gebruik van HTTP-verificatie moeten meer gegevens worden verzonden en kan de interoperabiliteit met clients worden beperkt. Anonieme toegang tot resources toestaan die niet hoeven te worden beveiligd.
Als de resource moet worden beveiligd, moet u overwegen welke verificatieschema's het vereiste beveiligingsniveau bieden. Het zwakste standaardverificatieschema dat hier wordt besproken, is basisverificatie. Basisverificatie beveiligt de referenties van de gebruiker niet. Het sterkste standaardverificatieschema is Negotiate authentication, wat resulteert in het Kerberos-protocol.
Een server mag niet aanwezig zijn, bijvoorbeeld in de HEADERs www-authentication), een schema dat niet is voorbereid om te accepteren of die de beveiligde resource niet voldoende beveiligt. Clients kunnen kiezen tussen een van de verificatieschema's die de server presenteert. Sommige clients zijn standaard ingesteld op een zwak verificatieschema of het eerste verificatieschema in de lijst van de server.