streamalism.org

1. Oversigt

I denne vejledning forstår vi det grundlæggende i Kerberos-godkendelsesprotokollen. Vi dækker også behovet for SPNEGO i forbindelse med Kerberos.

Endelig vil vi se, hvordan vi bruger Spring Security Kerberos-udvidelsen til at oprette applikationer aktiveret til Kerberos med SPNEGO.

Før vi fortsætter, er det umagen værd at bemærke, at denne vejledning introducerer mange nye vilkår for dem, der ikke er indviede i dette område. Derfor bruger vi lidt tid på forhånd for at dække grundene.

2. Forståelse af Kerberos

Kerberos er en netværksgodkendelsesprotokol udviklet ved Massachusetts Institute of Technology (MIT) i begyndelsen af ​​firserne. Som du måske indser, er dette relativt gammelt og har stået tidens prøve. Windows Server understøtter bredt Kerberos som en godkendelsesmekanisme og har endda gjort det til standardgodkendelsesindstillingen.

Teknisk set, Kerberos er en billetbaseret godkendelsesprotokol der gør det muligt for noder i et computernetværk at identificere sig for hinanden.

2.1. Simple Use Case til Kerberos

Lad os opstille en hypotetisk situation for at demonstrere dette.

Antag at en bruger via sin mailklient på sin maskine har brug for at hente sine e-mails fra en mailserver på en anden maskine på det samme netværk. Der er et åbenlyst behov for godkendelse her. Mailklienten og mailserveren skal kunne identificere og stole på hinanden, så de kan kommunikere sikkert.

Hvordan kan Kerberos hjælpe os her? Kerberos introducerer en tredjepart kaldet Key Distribution Center (KDC), som har en gensidig tillid til hver node i netværket. Lad os se, hvordan dette kan fungere i vores tilfælde:

2.2. Nøgleaspekter af Kerberos-protokollen

Selvom dette måske lyder esoterisk, er dette ret simpelt og kreativt for at sikre kommunikation via et usikret netværk. Nogle af de problemer, der præsenteres her, er ret tages for givet i TLS æra overalt!

Mens en detaljeret diskussion af Kerberos-protokollen ikke er mulig her, lad os gennemgå nogle vigtige aspekter:

• Tillid mellem noder (klient og server) og KDC antages at eksistere her over samme område
• Adgangskode udveksles aldrig over netværket
• Tillid mellem klienten og serveren er underforstået baseret på det faktum, at de kan dekryptere meddelelser med en nøgle, der kun deles med KDC
• Tillid mellem klienten og serveren er gensidig
• Klienten kan cache billetter til gentagen brug indtil udløbet, hvilket giver en enkelt login-oplevelse
• Authenticator-meddelelser er baseret på tidsstemplet og er derfor kun gode til engangsbrug
• Alle tre parter her skal have en relativt synkroniseret tid

Selvom dette bare skraber overfladen af ​​denne smukke godkendelsesprotokol, er det tilstrækkeligt at få os i gang med vores vejledning.

3. Forståelse af SPNEGO

SPNEGO står for Simple and Protected GSS-API Negotiation Mechanism. Helt et navn! Lad os først se, hvad GSS-API står for. Generic Security Service Application Program Interface (GSS-API) er intet andet end en IETF-standard for klient og server til at kommunikere på en sikker og leverandør-agnostisk måde.

SPNEGO er en del af GSS-API til klient og server for at forhandle om valget af sikkerhedsmekanisme at bruge for eksempel Kerberos eller NTLM.

4. Hvorfor har vi brug for det? SPNEGO Med Kerberos?

Som vi så i det foregående afsnit, er Kerberos en ren netværksgodkendelsesprotokol, der primært fungerer i transportlaget (TCP / UDP). Selvom dette er godt for mange brugssager, falder dette ikke under kravene til det moderne web. Hvis vi har en applikation, der fungerer på en højere abstraktion, som HTTP, er det ikke muligt at bruge Kerberos direkte.

Det er her SPNEGO kommer til vores hjælp. I tilfælde af en webapplikation sker der primært kommunikation mellem en webbrowser som Chrome og en webserver som Tomcat, der er vært for webapplikationen via HTTP. Hvis det er aktiveret, kan de forhandle Kerberos som en sikkerhedsmekanisme gennem SPNEGO og udveksle billetter som SPNEGO-tokens over HTTP.

Så hvordan ændrer dette vores tidligere nævnte scenario? Lad os erstatte vores enkle e-mail-klient med en webbrowser og e-mailserver med en webapplikation:

Så der har ikke ændret sig meget i forhold til vores tidligere diagram, bortset fra at kommunikationen mellem klient og server sker eksplicit via HTTP nu. Lad os forstå dette bedre:

• Klientmaskinen godkendes mod KDC og cacher TGT
• Webbrowser på klientmaskinen er konfigureret til at bruge SPNEGO og Kerberos
• Webapplikationen er også konfigureret til at understøtte SPNEGO og Kerberos
• Webapplikation kaster en "Forhandle" udfordring til webbrowseren, der prøver at få adgang til en beskyttet ressource
• Servicebillet pakkes ind som SPNEGO-token og udveksles som en HTTP-header

5. Krav

Før vi kan fortsætte med at udvikle en webapplikation, der understøtter Kerberos-godkendelsestilstand, skal vi samle nogle grundlæggende opsætninger. Lad os gennemgå disse opgaver hurtigt.

5.1. Opsætning af KDC

Opsætning af et Kerberos-miljø til produktionsbrug er uden for omfanget af denne vejledning. Dette er desværre ikke en triviel opgave og også skrøbelig. Der er flere muligheder for at få en implementering af Kerberos, både open source og kommercielle versioner:

• MIT gør implementeringen af ​​Kerberos v5 tilgængelig til flere operativsystemer
• Apache Kerby er en udvidelse til Apache Directory, som giver en Java Kerberos-binding
• Windows Server fra Microsoft understøtter Kerberos v5 oprindeligt bakket op af Active Directory
• Heimdel har en implementering af Kerberos v5

Den faktiske opsætning af KDC og relateret infrastruktur er afhængig af udbyderen og skal følges fra deres respektive dokumentation. Apache Kerby kan dog køres inde i en Docker-container, hvilket gør den platformneutral.

5.2. Opsætning af brugere i KDC

Vi er nødt til at oprette to brugere - eller som de kalder det principper - i KDC. Vi kan bruge kommandolinjeværktøjet “kadmin” til dette formål. Lad os antage, at vi har oprettet et rige kaldet “baeldung.com” i KDC-databasen og logget ind på “kadmin” med en bruger, der har administratorrettigheder.

Vi opretter vores første bruger, som vi ønsker at godkende fra en webbrowser, med:

$ kadmin: addprinc -randkey kchandrakant -pw password Principal "[email protected]" oprettet.

Vi bliver også nødt til at registrere vores webapplikation hos KDC:

$ kadmin: addprinc -keykey HTTP / [email protected] -pw password Principal "HTTP / [email protected]" oprettet.

Bemærk konventionen om navngivning af hovedstolen her, da dette skal matche det domæne, som applikationen er tilgængelig fra webbrowseren. Internettet browser forsøger automatisk at oprette et Service Principal Name (SPN) med denne konvention når de præsenteres for en "Forhandle" udfordring.

Vi skal også eksportere dette som en keytab-fil for at gøre den tilgængelig for webapplikationen:

$ kadmin: ktadd -k baeldung.keytab HTTP / [e-mail-beskyttet]

Dette skulle give os en fil med navnet “baeldung.keytab”.

5.3. Browser konfiguration

Vi er nødt til at aktivere den webbrowser, som vi bruger, for at få adgang til en beskyttet ressource i webapplikationen til godkendelsesskemaet "Forhandle". Heldigvis understøtter de fleste af de moderne webbrowsere som Chrome "Forhandle" som en godkendelsesplan som standard.

Derudover kan vi konfigurere browseren til at levere “Integreret godkendelse”. I denne tilstand forsøger browseren, når den præsenteres for "Forhandle" -udfordringen, at bruge de cachelagrede legitimationsoplysninger i værtsmaskinen, som allerede er logget ind i en KDC-princip. Vi bruger dog ikke denne tilstand her for at holde tingene eksplicitte.

5.4. Domænekonfiguration

Det er forståeligt, at vi muligvis ikke har egentlige domæner til at teste vores webapplikation. Men desværre kan vi ikke bruge localhost eller 127.0.0.1 eller nogen anden IP-adresse med Kerberos-godkendelse. Der er dog en nem løsning på dette, som involverer opsætning af poster i "hosts" -filen som:

demo.kerberos.bealdung.com 127.0.0.1

6. Spring til vores redning!

Endelig, da vi har det grundlæggende klart, er det tid til at teste teorien. Men vil det ikke være besværligt at oprette en webapplikation, der understøtter SPNEGO og Kerberos? Ikke hvis vi bruger foråret. Spring har en Kerberos-udvidelse som en del af Spring Security, der understøtter SPNEGO med Kerberos problemfrit.

Næsten alt hvad vi skal gøre er kun konfigurationer i Spring Security for at aktivere SPNEGO med Kerberos. Vi bruger konfigurationer i Java-stil her, men en XML-konfiguration kan opsættes så let. Vi kan udvide WebSecurityConfigurerAdapter klasse for at konfigurere alt, hvad vi har brug for.

6.1. Maven afhængigheder

Den første ting, vi skal oprette, er afhængighederne:

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

Disse afhængigheder kan downloades fra Maven Central.

6.2. SPNEGO-konfigurationer

For det første er SPNEGO integreret i Spring Security som en Filter i HTTPSikkerhed:

@ Override beskyttet ugyldig konfiguration (HttpSecurity http) kaster undtagelse {http.authorizeRequests () .anyRequest () .authenticated () .and () .addFilterBefore (spnegoAuthenticationProcessingFilter (authenticationManagerBean ()), BasicAuthenticationFilter.cl }

Dette viser kun den del, der kræves for at konfigurere SPNEGO Filter og er ikke en komplet HTTPSikkerhed konfiguration, som skal konfigureres i henhold til applikationens sikkerhedskrav.

Dernæst skal vi levere SPNEGO Filter som Bønne:

@Bean public SpnegoAuthenticationProcessingFilter spnegoAuthenticationProcessingFilter (AuthenticationManager authenticationManager) {SpnegoAuthenticationProcessingFilter filter = new SpnegoAuthenticationProcessingFilter (); filter.setAuthenticationManager (authenticationManager); returfilter; }

6.3. Kerberos-konfigurationer

Derudover kan vi konfigurere Kerberos ved at tilføje AuthenticationProvider til AuthenticationManagerBuilder i forårssikkerhed:

@ Override beskyttet ugyldig konfiguration (AuthenticationManagerBuilder auth) kaster Undtagelse {auth .authenticationProvider (kerberosAuthenticationProvider ()) .authenticationProvider (kerberosServiceAuthenticationProvider ()); }

Den første ting, vi skal levere, er en KerberosAuthenticationProvider som en Bønne. Dette er en implementering af AuthenticationProvider, og det er her vi sætter os SunJaasKerberosClient som en KerberosClient:

@Bean public KerberosAuthenticationProvider kerberosAuthenticationProvider () {KerberosAuthenticationProvider provider = new KerberosAuthenticationProvider (); SunJaasKerberosClient-klient = ny SunJaasKerberosClient (); provider.setKerberosClient (klient); provider.setUserDetailsService (userDetailsService ()); returudbyder }

Dernæst skal vi også give en KerberosServiceAuthenticationProvider som en Bønne. Dette er den klasse, der validerer Kerberos-servicebilletter eller SPNEGO-tokens:

@Bean offentlig KerberosServiceAuthenticationProvider kerberosServiceAuthenticationProvider () {KerberosServiceAuthenticationProvider provider = ny KerberosServiceAuthenticationProvider (); provider.setTicketValidator (sunJaasKerberosTicketValidator ()); provider.setUserDetailsService (userDetailsService ()); returudbyder }

Endelig skal vi give en SunJaasKerberosTicketValidator som en Bønne. Dette er en implementering af KerberosTicketValidator og bruger SUN JAAS Login Module:

@Bean offentlig SunJaasKerberosTicketValidator sunJaasKerberosTicketValidator () {SunJaasKerberosTicketValidator ticketValidator = ny SunJaasKerberosTicketValidator (); ticketValidator.setServicePrincipal ("HTTP / [e-mailbeskyttet]"); ticketValidator.setKeyTabLocation (ny FileSystemResource ("baeldung.keytab")); returbilletValidator; }

6.4. Brugeroplysninger

Vi har set henvisninger til en UserDetailsService i vores AuthenticationProvider tidligere, så hvorfor har vi brug for det? Som vi er kommet til Kerberos at kende, er det rent en godkendelsesmekanisme, der er billetbaseret.

Så selvom det er i stand til at identificere brugeren, giver det ikke andre detaljer relateret til brugeren, som deres autorisationer. Vi har brug for en gyldig UserDetailsService leveres til vores AuthenticationProvider for at udfylde dette hul.

6.5. Kørsel af applikationen

Dette er stort set hvad vi har brug for for at oprette en webapplikation med Spring Security aktiveret til SPNEGO med Kerberos. Når vi starter webapplikationen og får adgang til en hvilken som helst side deri, skal webbrowseren bede om brugernavn og adgangskode, forberede et SPNEGO-token med Service Ticket og sende det til applikationen.

Applikationen skal være i stand til at behandle det ved hjælp af legitimationsoplysningerne i keytab-filen og svare med vellykket godkendelse.

Men som vi så tidligere, er det kompliceret og ret skørt at oprette et fungerende Kerberos-miljø. Hvis tingene ikke fungerer som forventet, er det umagen værd at kontrollere alle trinene igen. En simpel fejl som uoverensstemmelse i domænenavnet kan føre til fejl med fejlmeddelelser, der ikke er særlig nyttige.

7. Praktisk brug af SPNEGO og Kerberos

Nu hvor vi har set, hvordan Kerberos-godkendelse fungerer, og hvordan vi kan bruge SPNEGO med Kerberos i webapplikationer, kan vi sætte spørgsmålstegn ved behovet for det. Mens det giver fuld mening at bruge det som en SSO-mekanisme inden for et virksomhedsnetværk, hvorfor skal vi bruge dette i webapplikationer?

Nå, for en, selv efter så mange år, bruges Kerberos stadig meget aktivt inden for virksomhedsapplikationer, især Windows-baserede applikationer. Hvis en organisation har flere interne og eksterne webapplikationer, giver det mening udvide den samme SSO-infrastruktur til at dække dem alle. Dette gør det meget nemmere for administratorer og brugere af en organisation at have en problemfri oplevelse gennem forskellige applikationer.

8. Konklusion

For at opsummere forstod vi i denne vejledning det grundlæggende i Kerberos-godkendelsesprotokol. Vi diskuterede også SPNEGO som en del af GSS-API, og hvordan vi kan bruge det til at lette Kerberos-baseret autentificering i en webapplikation via HTTP. Desuden forsøgte vi at opbygge en lille webapplikation, der udnytter Spring Securitys indbyggede support til SPNEGO med Kerberos.

Denne vejledning giver bare et hurtigt kig på en kraftig og tidstestet godkendelsesmekanisme. Der er et væld af informationer til rådighed for os at lære mere og muligvis værdsætte endnu mere!

Som altid kan koden findes på GitHub.