streamalism.org

1. Oversikt

I denne opplæringen vil vi forstå det grunnleggende i Kerberos-godkjenningsprotokollen. Vi vil også dekke behovet for SPNEGO i forbindelse med Kerberos.

Til slutt vil vi se hvordan du kan bruke Spring Security Kerberos-utvidelsen til å lage applikasjoner aktivert for Kerberos med SPNEGO.

Før vi fortsetter, er det verdt å merke seg at denne opplæringen vil introdusere mange nye vilkår for de uinnvidde i dette området. Derfor vil vi bruke litt tid på forhånd for å dekke eiendommen.

2. Forstå Kerberos

Kerberos er en nettverksgodkjenningsprotokoll utviklet ved Massachusetts Institute of Technology (MIT) tidlig på åttitallet. Som du kanskje skjønner, er dette relativt gammelt og har stått tidstesten. Windows Server støtter vidt Kerberos som en autentiseringsmekanisme, og har til og med gjort det til standardgodkjenningsalternativet.

Teknisk sett, Kerberos er en billettbasert autentiseringsprotokoll som lar noder i et datanettverk identifisere seg for hverandre.

2.1. Enkel brukstilfelle for Kerberos

La oss tegne en hypotetisk situasjon for å demonstrere dette.

Anta at en bruker, gjennom sin e-postklient på maskinen sin, trenger å hente e-postene sine fra en e-postserver på en annen maskin i samme nettverk. Det er et åpenbart behov for autentisering her. E-postklienten og e-postserveren må kunne identifisere og stole på hverandre for at de skal kunne kommunisere sikkert.

Hvordan kan Kerberos hjelpe oss her? Kerberos introduserer en tredjepart kalt Key Distribution Center (KDC), som har en gjensidig tillit til hver node i nettverket. La oss se hvordan dette kan fungere i vårt tilfelle:

2.2. Nøkkelaspekter av Kerberos-protokollen

Selv om dette kan høres esoterisk ut, er dette ganske enkelt og kreativt for å sikre kommunikasjon over et usikret nettverk. Noen av problemene som presenteres her er ganske tatt for gitt i TLS-tiden overalt!

Mens en detaljert diskusjon av Kerberos-protokollen ikke er mulig her, la oss gå gjennom noen viktige aspekter:

• Tillit mellom noder (klient og server) og KDC antas å eksistere her over samme rike
• Passord byttes aldri ut over nettverket
• Tillit mellom klienten og serveren er underforstått basert på det faktum at de kan dekryptere meldinger med en nøkkel som bare er delt med KDC
• Tillit mellom klienten og serveren er gjensidig
• Klienten kan cache billetter for gjentatt bruk til utløpet, og gir en enkelt påloggingsopplevelse
• Authenticator-meldinger er basert på tidsstempelet og er derfor bare bra for engangsbruk
• Alle tre partiene her må ha en relativt synkronisert tid

Mens dette bare skraper overflaten av denne vakre autentiseringsprotokollen, er det tilstrekkelig for å få oss i gang med veiledningen vår.

3. Forståelse av SPNEGO

SPNEGO står for Simple and Protected GSS-API Negotiation Mechanism. Ganske et navn! La oss først se hva GSS-API står for. Generic Security Service Application Program Interface (GSS-API) er ingenting annet enn en IETF-standard for klient og server å kommunisere på en sikker og leverandør-agnostisk måte.

SPNEGO er en del av GSS-API for klient og server for å forhandle om valg av sikkerhetsmekanisme å bruke for eksempel Kerberos eller NTLM.

4. Hvorfor trenger vi SPNEGO Med Kerberos?

Som vi så i forrige avsnitt, er Kerberos en ren Network Authentication Protocol som primært opererer i transportlaget (TCP / UDP). Selv om dette er bra for mange brukssaker, faller dette ikke under kravene til det moderne nettet. Hvis vi har et program som opererer på en høyere abstraksjon, som HTTP, er det ikke mulig å bruke Kerberos direkte.

Dette er hvor SPNEGO kommer til vår hjelp. Når det gjelder en webapplikasjon, skjer kommunikasjon primært mellom en nettleser som Chrome og en webserver som Tomcat som er vert for webapplikasjonen over HTTP. Hvis aktivert, kan de forhandle Kerberos som en sikkerhetsmekanisme gjennom SPNEGO og bytt billetter som SPNEGO-tokens over HTTP.

Så hvordan endrer dette vårt scenario som er nevnt tidligere? La oss erstatte vår enkle e-postklient med en nettleser og e-postserver med en webapplikasjon:

Så, ikke mye har endret seg i forhold til vårt forrige diagram, bortsett fra at kommunikasjonen mellom klient og server skjer eksplisitt over HTTP nå. La oss forstå dette bedre:

• Klientmaskinen autentiseres mot KDC og cacher TGT
• Nettleser på klientmaskinen er konfigurert til å bruke SPNEGO og Kerberos
• Nettapplikasjonen er også konfigurert for å støtte SPNEGO og Kerberos
• Nettapplikasjon kaster en "Forhandle" utfordring til nettleseren som prøver å få tilgang til en beskyttet ressurs
• Tjenestebilletten pakkes inn som SPNEGO-token og byttes ut som en HTTP-overskrift

5. Krav

Før vi kan fortsette å utvikle et webapplikasjon som støtter Kerberos-godkjenningsmodus, må vi samle noen grunnleggende oppsett. La oss gå gjennom disse oppgavene raskt.

5.1. Sette opp KDC

Å sette opp et Kerberos-miljø for produksjonsbruk er utenfor omfanget av denne opplæringen. Dette er dessverre ikke en triviell oppgave og skjør også. Det er flere alternativer tilgjengelig for å få en implementering av Kerberos, både åpen kildekode og kommersielle versjoner:

• MIT gjør implementeringen av Kerberos v5 tilgjengelig for flere operativsystemer
• Apache Kerby er en utvidelse til Apache Directory, som gir en Java Kerberos-binding
• Windows Server fra Microsoft støtter Kerberos v5 naturlig støttet av Active Directory
• Heimdel har en implementering av Kerberos v5

Selve oppsettet av KDC og tilhørende infrastruktur er avhengig av leverandøren og bør følges fra deres respektive dokumentasjon. Imidlertid kan Apache Kerby kjøres i en Docker-container, noe som gjør den plattformnøytral.

5.2. Sette opp brukere i KDC

Vi må sette opp to brukere - eller, som de kaller det, rektorer - i KDC. Vi kan bruke kommandolinjeverktøyet “kadmin” til dette formålet. La oss anta at vi har opprettet et rike kalt “baeldung.com” i KDC-databasen og logget på “kadmin” med en bruker som har administratorrettigheter.

Vi oppretter vår første bruker, som vi ønsker å godkjenne fra en nettleser, med:

$ kadmin: addprinc -randkey kchandrakant -pw passord Rektor "[email protected]" opprettet.

Vi må også registrere webapplikasjonen vår hos KDC:

$ kadmin: addprinc -randkey HTTP / [e-postbeskyttet] -pw passord Hoved "HTTP / [e-postbeskyttet]" opprettet.

Legg merke til konvensjonen for å navngi rektor her, da dette må samsvare med domenet som applikasjonen er tilgjengelig på fra nettleseren. Nettet nettleseren prøver automatisk å opprette et Service Principal Name (SPN) med denne konvensjonen når de blir presentert for en "Forhandle" -utfordring.

Vi må også eksportere dette som en tastaturfil for å gjøre den tilgjengelig for webapplikasjonen:

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

Dette skal gi oss en fil som heter “baeldung.keytab”.

5.3. Nettleserkonfigurasjon

Vi må aktivere nettleseren som vi bruker for å få tilgang til en beskyttet ressurs i webapplikasjonen for "Forhandle" -autentiseringsskjemaet. Heldigvis støtter de fleste moderne nettlesere som Chrome "Forhandle" som et autentiseringsskjema som standard.

I tillegg kan vi konfigurere nettleseren til å gi "Integrert autentisering". I denne modusen, når den blir presentert for "Forhandle" -utfordringen, prøver nettleseren å bruke de bufrede legitimasjonene i vertsmaskinen, som allerede er logget inn i en KDC-rektor. Vi bruker imidlertid ikke denne modusen her for å holde ting eksplisitte.

5.4. Domenekonfigurasjon

Det er forståelig at vi kanskje ikke har faktiske domener for å teste webapplikasjonen vår. Men dessverre kan vi ikke bruke localhost eller 127.0.0.1 eller annen IP-adresse med Kerberos-godkjenning. Det er imidlertid en enkel løsning på dette, som innebærer å sette opp oppføringer i "hosts" -filen som:

demo.kerberos.bealdung.com 127.0.0.1

6. Vår til unnsetning!

Til slutt, som det grunnleggende er klart, er det på tide å teste teorien. Men vil det ikke være tungvint å lage en webapplikasjon som støtter SPNEGO og Kerberos? Ikke hvis vi bruker våren. Spring har en Kerberos-utvidelse som en del av Spring Security som støtter SPNEGO med Kerberos sømløst.

Nesten alt vi trenger å gjøre er bare konfigurasjoner i Spring Security for å aktivere SPNEGO med Kerberos. Vi bruker konfigurasjoner i Java-stil her, men en XML-konfigurasjon kan settes opp like enkelt. Vi kan utvide WebSecurityConfigurerAdapter klasse for å konfigurere alt vi trenger.

6.1. Maven avhengigheter

Det første vi må sette opp er avhengighetene:

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

Disse avhengighetene er tilgjengelige for nedlasting fra Maven Central.

6.2. SPNEGO-konfigurasjoner

For det første er SPNEGO integrert i Spring Security som en Filter i HTTPSikkerhet:

@ Override beskyttet tom konfigurering (HttpSecurity http) kaster unntak {http.authorizeRequests () .anyRequest () .authenticated () .and () .addFilterBefore (spnegoAuthenticationProcessingFilter (authenticationManagerBean ()), BasicAuthenticationFilter.cl }

Dette viser bare den delen som kreves for å konfigurere SPNEGO Filter og er ikke en komplett HTTPSikkerhet konfigurasjon, som skal konfigureres i henhold til applikasjonens sikkerhetskrav.

Deretter må vi tilby SPNEGO Filter som Bønne:

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

6.3. Kerberos-konfigurasjoner

I tillegg kan vi konfigurere Kerberos ved å legge til AuthenticationProvider til AuthenticationManagerBuilder i vårsikkerhet:

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

Det første vi må tilby er en KerberosAuthenticationProvider som en Bønne. Dette er en implementering av AuthenticationProvider, og det er her vi setter oss SunJaasKerberosClient som en KerberosClient:

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

Deretter må vi også gi en KerberosServiceAuthenticationProvider som en Bønne. Dette er klassen som validerer Kerberos servicebilletter eller SPNEGO-tokens:

@Bean public KerberosServiceAuthenticationProvider kerberosServiceAuthenticationProvider () {KerberosServiceAuthenticationProvider provider = new KerberosServiceAuthenticationProvider (); provider.setTicketValidator (sunJaasKerberosTicketValidator ()); provider.setUserDetailsService (userDetailsService ()); returleverandør; }

Til slutt må vi gi en SunJaasKerberosTicketValidator som en Bønne. Dette er en implementering av KerberosTicketValidator og bruker SUN JAAS påloggingsmodul:

@Bean public SunJaasKerberosTicketValidator sunJaasKerberosTicketValidator () {SunJaasKerberosTicketValidator ticketValidator = new SunJaasKerberosTicketValidator (); ticketValidator.setServicePrincipal ("HTTP / [e-postbeskyttet]"); ticketValidator.setKeyTabLocation (ny FileSystemResource ("baeldung.keytab")); returbillettValidator; }

6.4. Brukerdetaljer

Vi har sett referanser til a UserDetailsService i vår AuthenticationProvider tidligere, så hvorfor trenger vi det? Som vi har lært Kerberos å kjenne, er det utelukkende en autentiseringsmekanisme som er billettbasert.

Så selv om den er i stand til å identifisere brukeren, gir den ikke andre detaljer relatert til brukeren, som deres autorisasjoner. Vi trenger en gyldig UserDetailsService gitt til vår AuthenticationProvider for å fylle dette hullet.

6.5. Kjører applikasjonen

Dette er stort sett det vi trenger for å sette opp en webapplikasjon med Spring Security aktivert for SPNEGO med Kerberos. Når vi starter opp webapplikasjonen og får tilgang til en hvilken som helst side der, bør nettleseren be om brukernavn og passord, forberede et SPNEGO-token med Service Ticket og sende det til applikasjonen.

Søknaden skal kunne behandle den ved hjelp av legitimasjonen i nøkkelfilen og svare med vellykket autentisering.

Imidlertid, som vi så tidligere, er det komplisert og ganske sprøtt å sette opp et fungerende Kerberos-miljø. Hvis ting ikke fungerer som forventet, er det verdt å sjekke alle trinnene igjen. En enkel feil som manglende samsvar i domenenavnet kan føre til feil med feilmeldinger som ikke er spesielt nyttige.

7. Praktisk bruk av SPNEGO og Kerberos

Nå som vi har sett hvordan Kerberos-autentisering fungerer og hvordan vi kan bruke SPNEGO med Kerberos i webapplikasjoner, kan vi stille spørsmål ved behovet for det. Selv om dette gir full mening å bruke det som en SSO-mekanisme i et bedriftsnettverk, hvorfor skal vi bruke dette i webapplikasjoner?

Vel, for en gang, selv etter så mange år, brukes Kerberos fortsatt veldig aktivt i bedriftsapplikasjoner, spesielt Windows-baserte applikasjoner. Hvis en organisasjon har flere interne og eksterne webapplikasjoner, gir det mening utvide den samme SSO-infrastrukturen for å dekke dem alle. Dette gjør det mye enklere for administratorer og brukere av en organisasjon å ha en sømløs opplevelse gjennom ulike applikasjoner.

8. Konklusjon

For å oppsummere, i denne opplæringen, forsto vi det grunnleggende om Kerberos-godkjenningsprotokoll. Vi diskuterte også SPNEGO som en del av GSS-API og hvordan vi kan bruke den til å legge til rette for Kerberos-basert autentisering i et webapplikasjon via HTTP. Videre prøvde vi å bygge en liten webapplikasjon som utnytter Spring Securitys innebygde støtte for SPNEGO med Kerberos.

Denne opplæringen gir bare en rask sniktitt på en kraftig og tidstestet autentiseringsmekanisme. Det er ganske mye informasjon tilgjengelig for oss å lære mer og muligens sette pris på enda mer!

Som alltid kan koden bli funnet på GitHub.