Inleiding tot SPNEGO / Kerberos-verificatie in het voorjaar

1. Overzicht

In deze zelfstudie zullen we de basisprincipes van het Kerberos-verificatieprotocol begrijpen. We behandelen ook de behoefte aan SPNEGO in verband met Kerberos.

Ten slotte zullen we zien hoe we de Spring Security Kerberos-extensie kunnen gebruiken om applicaties te maken die zijn ingeschakeld voor Kerberos met SPNEGO.

Voordat we verder gaan, is het de moeite waard om op te merken dat deze tutorial veel nieuwe termen zal introduceren voor niet-ingewijden op dit gebied. Daarom zullen we wat tijd vooraan doorbrengen om het terrein te bedekken.

2. Kerberos begrijpen

Kerberos is een netwerkverificatieprotocol ontwikkeld aan het Massachusetts Institute of Technology (MIT) in de vroege jaren tachtig. Zoals u wellicht beseft, is dit relatief oud en heeft het de tand des tijds doorstaan. Windows Server ondersteunt op grote schaal Kerberos als een authenticatiemechanisme en heeft het zelfs tot de standaard authenticatie-optie gemaakt.

Technisch gezien, Kerberos is een op tickets gebaseerd verificatieprotocol waarmee knooppunten in een computernetwerk zich bij elkaar kunnen identificeren.

2.1. Eenvoudig gebruiksscenario voor Kerberos

Laten we een hypothetische situatie opstellen om dit aan te tonen.

Stel dat een gebruiker, via zijn e-mailclient op zijn computer, zijn e-mails moet ophalen van een mailserver op een andere machine op hetzelfde netwerk. Er is hier een duidelijke behoefte aan authenticatie. De e-mailclient en de e-mailserver moeten elkaar kunnen identificeren en vertrouwen om veilig te kunnen communiceren.

Hoe kan Kerberos ons hierbij helpen? Kerberos introduceert een derde partij genaamd Key Distribution Center (KDC), die een wederzijds vertrouwen heeft met elk knooppunt in het netwerk. Laten we eens kijken hoe dit in ons geval kan werken:

2.2. Belangrijkste aspecten van het Kerberos-protocol

Hoewel dit misschien esoterisch klinkt, is dit vrij eenvoudig en creatief bij het beveiligen van communicatie via een onbeveiligd netwerk. Sommige van de hier gepresenteerde problemen worden overal in het tijdperk van TLS als vanzelfsprekend beschouwd!

Hoewel een gedetailleerde bespreking van het Kerberos-protocol hier niet mogelijk is, laten we enkele opvallende aspecten doornemen:

  • Vertrouwen tussen knooppunten (client en server) en KDC wordt hier verondersteld te bestaan ​​in hetzelfde rijk
  • Wachtwoord wordt nooit via het netwerk uitgewisseld
  • Vertrouwen tussen de client en de server is gebaseerd op het feit dat ze berichten kunnen decoderen met een sleutel die alleen wordt gedeeld met de KDC
  • Het vertrouwen tussen de klant en de server is wederzijds
  • De client kan tickets in de cache opslaan voor herhaald gebruik tot de vervaldatum, waardoor eenmalige aanmelding wordt geboden
  • Authenticator-berichten zijn gebaseerd op het tijdstempel en zijn dus alleen geschikt voor eenmalig gebruik
  • Alle drie de partijen hier moeten een relatief gesynchroniseerde tijd hebben

Hoewel dit slechts het oppervlak van dit prachtige authenticatieprotocol krast, is het voldoende om ons op weg te helpen met onze tutorial.

3. Inzicht in SPNEGO

SPNEGO staat voor Simple and Protected GSS-API Negotiation Mechanism. Een hele naam! Laten we eerst kijken waar GSS-API voor staat. De Generic Security Service Application Program Interface (GSS-API) is niets anders dan een IETF-standaard voor client en server om op een veilige en leverancieronafhankelijke manier te communiceren.

SPNEGO maakt deel uit van de GSS-API voor client en server om te onderhandelen over de keuze van het beveiligingsmechanisme om bijvoorbeeld Kerberos of NTLM te gebruiken.

4. Waarom hebben we nodig SPNEGO Met Kerberos?

Zoals we in de vorige sectie hebben gezien, is Kerberos een puur netwerkauthenticatieprotocol dat voornamelijk in de transportlaag (TCP / UDP) werkt. Hoewel dit in veel gevallen goed is, voldoet dit niet aan de vereisten voor het moderne internet. Als we een applicatie hebben die op een hogere abstractie werkt, zoals HTTP, is het niet mogelijk om Kerberos rechtstreeks te gebruiken.

Dit is waar SPNEGO ons te hulp schiet. In het geval van een webapplicatie vindt de communicatie voornamelijk plaats tussen een webbrowser zoals Chrome en een webserver zoals Tomcat die de webapplicatie host via HTTP. Indien ingeschakeld, kunnen ze onderhandel Kerberos als een beveiligingsmechanisme via SPNEGO en wissel tickets uit als SPNEGO-tokens via HTTP.

Dus hoe verandert dit ons eerder genoemde scenario? Laten we onze eenvoudige e-mailclient vervangen door een webbrowser en mailserver met een webtoepassing:

Hier is dus niet veel veranderd in vergelijking met ons vorige diagram, behalve dat de communicatie tussen client en server nu expliciet via HTTP verloopt. Laten we dit beter begrijpen:

  • De clientcomputer verifieert zich tegen de KDC en slaat de TGT in de cache op
  • De webbrowser op de clientcomputer is geconfigureerd om SPNEGO en Kerberos te gebruiken
  • De webapplicatie is ook geconfigureerd om SPNEGO en Kerberos te ondersteunen
  • Webtoepassing werpt een "onderhandelen" -uitdaging op voor de webbrowser die probeert toegang te krijgen tot een beschermde bron
  • Serviceticket wordt verpakt als SPNEGO-token en uitgewisseld als HTTP-header

5. Vereisten

Voordat we door kunnen gaan met het ontwikkelen van een webtoepassing die de Kerberos-verificatiemodus ondersteunt, moeten we enkele basisinstellingen verzamelen. Laten we deze taken snel doornemen.

5.1. KDC instellen

Het opzetten van een Kerberos-omgeving voor productiegebruik valt buiten het bestek van deze tutorial. Dit is helaas geen triviale taak en ook nog eens kwetsbaar. Er zijn verschillende opties beschikbaar om een ​​implementatie van Kerberos te krijgen, zowel open source als commerciële versies:

  • MIT maakt de implementatie van Kerberos v5 beschikbaar voor meerdere besturingssystemen
  • Apache Kerby is een uitbreiding op Apache Directory, die een Java Kerberos-binding biedt
  • Windows Server van Microsoft ondersteunt Kerberos v5 native ondersteund door Active Directory
  • Heimdel heeft een implementatie van Kerberos v5

De feitelijke opzet van KDC en gerelateerde infrastructuur is afhankelijk van de provider en moet worden gevolgd uit hun respectievelijke documentatie. Apache Kerby kan echter worden uitgevoerd in een Docker-container, waardoor deze platformneutraal is.

5.2. Gebruikers instellen in KDC

We moeten twee gebruikers - of, zoals ze het noemen, opdrachtgevers - instellen in KDC. We kunnen hiervoor het opdrachtregelprogramma "kadmin" gebruiken. Laten we aannemen dat we een rijk met de naam "baeldung.com" hebben gemaakt in de KDC-database en zijn ingelogd bij "kadmin" met een gebruiker met beheerdersrechten.

We maken onze eerste gebruiker aan, die we willen authenticeren via een webbrowser, met:

$ kadmin: addprinc -randkey kchandrakant -pw wachtwoord Principal "[email protected]" aangemaakt.

We zullen ook onze webapplicatie moeten registreren bij het KDC:

$ kadmin: addprinc -randkey HTTP / [e-mail beschermd] -pw wachtwoord Principal "HTTP / [e-mail beschermd]" gemaakt.

Let op de conventie voor het benoemen van de principal hier, aangezien deze moet overeenkomen met het domein waarop de applicatie toegankelijk is vanuit de webbrowser. Het web browser probeert automatisch een Service Principal Name (SPN) te maken met deze conventie wanneer gepresenteerd met een "onderhandelen" uitdaging.

We moeten dit ook exporteren als een keytab-bestand om het beschikbaar te maken voor de webapplicatie:

$ kadmin: ktadd -k baeldung.keytab HTTP / [email protected]

Dit zou ons een bestand met de naam "baeldung.keytab" moeten opleveren.

5.3. Browserconfiguratie

We moeten de webbrowser die we gebruiken inschakelen om toegang te krijgen tot een beschermde bron op de webapplicatie voor het "Onderhandelen" authenticatieschema. Gelukkig ondersteunen de meeste moderne webbrowsers, zoals Chrome, 'onderhandelen' standaard als authenticatieschema.

Bovendien kunnen we de browser configureren om "geïntegreerde authenticatie" te bieden. In deze modus, wanneer de "Onderhandelen" -uitdaging wordt gepresenteerd, probeert de browser gebruik te maken van de in de cache opgeslagen aanmeldingsgegevens op de hostcomputer, die al is aangemeld bij een KDC-principal. We zullen deze modus hier echter niet gebruiken om dingen expliciet te houden.

5.4. Domeinconfiguratie

Het is begrijpelijk dat we mogelijk geen echte domeinen hebben om onze webapplicatie te testen. Maar helaas kunnen we localhost of 127.0.0.1 of een ander IP-adres met Kerberos-authenticatie niet gebruiken. Hier is echter een eenvoudige oplossing voor, namelijk het instellen van vermeldingen in het "hosts" -bestand, zoals:

demo.kerberos.bealdung.com 127.0.0.1

6. Spring om ons te redden!

Eindelijk, aangezien we de basis duidelijk hebben, is het tijd om de theorie te testen. Maar zou het niet omslachtig zijn om een ​​webtoepassing te maken die SPNEGO en Kerberos ondersteunt? Niet als we de lente gebruiken. Spring heeft een Kerberos-extensie als onderdeel van Spring Security die SPNEGO met Kerberos ondersteunt naadloos.

Bijna alles wat we hoeven te doen zijn configuraties in Spring Security om SPNEGO met Kerberos mogelijk te maken. We gebruiken hier configuraties in Java-stijl, maar een XML-configuratie kan net zo gemakkelijk worden ingesteld. We kunnen de WebSecurityConfigurerAdapter class om alles te configureren wat we nodig hebben.

6.1. Afhankelijkheden van Maven

Het eerste dat we moeten instellen, zijn de afhankelijkheden:

 org.springframework.security.kerberos spring-security-kerberos-web $ {kerberos.extension.version} org.springframework.security.kerberos spring-security-kerberos-client $ {kerberos.extension.version} 

Deze afhankelijkheden kunnen worden gedownload vanaf Maven Central.

6.2. SPNEGO-configuraties

Ten eerste is SPNEGO geïntegreerd in Spring Security als een Filter in HTTPS-beveiliging:

@Override protected void configure (HttpSecurity http) genereert uitzondering {http.authorizeRequests () .anyRequest () .authenticated () .and () .addFilterBefore (spnegoAuthenticationProcessingFilter (authenticationManagerBean ()), BasicAuthenticationFilter.class); }

Dit toont alleen het gedeelte dat nodig is om SPNEGO te configureren Filter en is niet compleet HTTPS-beveiliging configuratie, die moet worden geconfigureerd volgens de beveiligingsvereisten van de applicatie.

Vervolgens moeten we de SPNEGO opgeven Filter net zo Boon:

@Bean openbaar SpnegoAuthenticationProcessingFilter spnegoAuthenticationProcessingFilter (AuthenticationManager authenticationManager) {SpnegoAuthenticationProcessingFilter filter = nieuw SpnegoAuthenticationProcessingFilter (); filter.setAuthenticationManager (authenticationManager); retourfilter; }

6.3. Kerberos-configuraties

Bovendien kunnen we Kerberos configureren door AuthenticationProvider naar AuthenticationManagerBuilder in Spring Security:

@Override beschermde void configure (AuthenticationManagerBuilder auth) genereert Uitzondering {auth .authenticationProvider (kerberosAuthenticationProvider ()) .authenticationProvider (kerberosServiceAuthenticationProvider ()); }

Het eerste dat we moeten bieden, is een KerberosAuthenticationProvider als een Boon. Dit is een implementatie van AuthenticationProvider, en dit is waar we zitten SunJaasKerberosClient als een KerberosClient:

@Bean openbare KerberosAuthenticationProvider kerberosAuthenticationProvider () {KerberosAuthenticationProvider provider = nieuwe KerberosAuthenticationProvider (); SunJaasKerberosClient client = nieuwe SunJaasKerberosClient (); provider.setKerberosClient (klant); provider.setUserDetailsService (userDetailsService ()); terugkeerprovider; }

Vervolgens moeten we ook een KerberosServiceAuthenticationProvider als een Boon. Dit is de klasse die Kerberos-servicetickets of SPNEGO-tokens valideert:

@Bean openbare KerberosServiceAuthenticationProvider kerberosServiceAuthenticationProvider () {KerberosServiceAuthenticationProvider provider = nieuwe KerberosServiceAuthenticationProvider (); provider.setTicketValidator (sunJaasKerberosTicketValidator ()); provider.setUserDetailsService (userDetailsService ()); terugkeerprovider; }

Ten slotte moeten we een SunJaasKerberosTicketValidator als een Boon. Dit is een implementatie van KerberosTicketValidator en gebruikt SUN JAAS Login Module:

@Bean openbaar SunJaasKerberosTicketValidator sunJaasKerberosTicketValidator () {SunJaasKerberosTicketValidator ticketValidator = nieuwe SunJaasKerberosTicketValidator (); ticketValidator.setServicePrincipal ("HTTP / [e-mail beveiligd]"); ticketValidator.setKeyTabLocation (nieuw FileSystemResource ("baeldung.keytab")); retourticketValidator; }

6.4. gebruikersdetails

We hebben verwijzingen gezien naar een UserDetailsService in onze AuthenticationProvider eerder, dus waarom hebben we het nodig? Zoals we Kerberos hebben leren kennen, is het puur een authenticatiemechanisme dat gebaseerd is op tickets.

Dus hoewel het de gebruiker kan identificeren, biedt het geen andere details met betrekking tot de gebruiker, zoals hun autorisaties. We hebben een geldige nodig UserDetailsService verstrekt aan onze AuthenticationProvider om deze leemte op te vullen.

6.5. De applicatie uitvoeren

Dit is zo ongeveer wat we nodig hebben om een ​​webapplicatie op te zetten met Spring Security ingeschakeld voor SPNEGO met Kerberos. Wanneer we de webapplicatie opstarten en een pagina openen, moet de webbrowser om gebruikersnaam en wachtwoord vragen, een SPNEGO-token met Service Ticket voorbereiden en naar de applicatie sturen.

De toepassing moet het kunnen verwerken met behulp van de inloggegevens in het keytab-bestand en reageren met succesvolle authenticatie.

Zoals we eerder zagen, is het opzetten van een werkende Kerberos-omgeving echter ingewikkeld en vrij broos. Als dingen niet werken zoals verwacht, is het de moeite waard om alle stappen opnieuw te controleren. Een simpele fout, zoals een verkeerde combinatie van de domeinnaam, kan leiden tot het mislukken van foutmeldingen die niet bijzonder nuttig zijn.

7. Praktisch gebruik van SPNEGO en Kerberos

Nu we hebben gezien hoe Kerberos-authenticatie werkt en hoe we SPNEGO met Kerberos in webapplicaties kunnen gebruiken, twijfelen we misschien aan de noodzaak ervan. Hoewel dit volkomen logisch is om het als een SSO-mechanisme binnen een bedrijfsnetwerk te gebruiken, waarom zouden we dit dan in webapplicaties gebruiken?

Ten eerste wordt Kerberos zelfs na zoveel jaren nog steeds zeer actief gebruikt binnen bedrijfstoepassingen, met name op Windows gebaseerde toepassingen. Als een organisatie meerdere interne en externe webapplicaties heeft, is dat logisch breid dezelfde SSO-infrastructuur uit om ze allemaal te dekken. Dit maakt het veel gemakkelijker voor beheerders en gebruikers van een organisatie om een ​​naadloze ervaring te hebben door middel van ongelijksoortige applicaties.

8. Conclusie

Samenvattend, in deze zelfstudie hebben we de basisprincipes van het Kerberos-verificatieprotocol begrepen. We hebben ook gesproken over SPNEGO als onderdeel van GSS-API en hoe we het kunnen gebruiken om op Kerberos gebaseerde authenticatie in een webapplicatie via HTTP te vergemakkelijken. Verder hebben we geprobeerd een kleine webapplicatie te bouwen die gebruikmaakt van de ingebouwde ondersteuning van Spring Security voor SPNEGO met Kerberos.

Deze tutorial biedt slechts een korte voorproefje van een krachtig en beproefd authenticatiemechanisme. Er is een behoorlijke schat aan informatie beschikbaar voor ons om meer te leren en mogelijk nog meer te waarderen!

Zoals altijd is de code te vinden op GitHub.


$config[zx-auto] not found$config[zx-overlay] not found