streamalism.org

1. Pregled

U ovom uputstvu razumjet ćemo osnove protokola provjere autentičnosti Kerberos. Također ćemo pokriti potrebu za SPNEGO-om u vezi s Kerberosom.

Napokon, vidjet ćemo kako iskoristiti proširenje Spring Security Kerberos za stvaranje aplikacija omogućenih za Kerberos pomoću SPNEGO-a.

Prije nego što nastavimo, vrijedno je napomenuti da će ovaj vodič predstaviti mnogo novih pojmova za one koji nisu upućeni u ovo područje. Stoga ćemo provesti neko vrijeme ispred kako bismo pokrili teren.

2. Razumijevanje Kerberosa

Kerberos je mrežni protokol za provjeru autentičnosti razvijen na Massachusetts Institute of Technology (MIT) početkom osamdesetih. Kao što možda shvaćate, ovo je relativno staro i izdržalo je test vremena. Windows Server široko podržava Kerberos kao mehanizam provjere autentičnosti, pa ga je čak postavio i kao zadanu opciju provjere autentičnosti.

Tehnički, Kerberos je protokol provjere autentičnosti temeljen na ulaznicama koji omogućuje čvorovima u računalnoj mreži da se međusobno identificiraju.

2.1. Jednostavan slučaj za Kerberos

Izradimo hipotetsku situaciju da to dokažemo.

Pretpostavimo da korisnik putem svog klijenta pošte na svom računalu mora povući svoju e-poštu s poštanskog poslužitelja na drugom računalu na istoj mreži. Ovdje je očita potreba za autentifikacijom. Klijent pošte i poslužitelj pošte moraju biti sposobni prepoznati se i vjerovati jedni drugima kako bi mogli sigurno komunicirati.

Kako nam Kerberos može ovdje pomoći? Kerberos predstavlja treću stranu pod nazivom Ključni distribucijski centar (KDC), koji ima obostrano povjerenje sa svakim čvorom u mreži. Pogledajmo kako ovo može funkcionirati u našem slučaju:

2.2. Ključni aspekti Kerberos protokola

Iako ovo može zvučati ezoterično, ovo je prilično jednostavno i kreativno u osiguranju komunikacije putem nezaštićene mreže. Neki od ovdje predstavljenih problema sasvim su zdravo za gotovo u eri TLS-a svugdje!

Iako detaljna rasprava o Kerberos protokolu ovdje nije moguća, prođimo kroz neke istaknute aspekte:

• Pretpostavlja se da ovdje postoji povjerenje između čvorova (klijenta i poslužitelja) i KDC-a na istom području
• Lozinka se nikada ne razmjenjuje preko mreže
• Povjerenje između klijenta i poslužitelja podrazumijeva se na temelju činjenice da oni mogu dešifrirati poruke pomoću ključa koji se dijeli samo s KDC
• Povjerenje između klijenta i poslužitelja je obostrano
• Klijent može predmemorirati karte za ponovljenu upotrebu do isteka, pružajući jednokratno iskustvo prijave
• Poruke autentifikatora temelje se na vremenskoj oznaci i stoga su dobre samo za jednokratnu upotrebu
• Sve tri strane ovdje moraju imati relativno sinkronizirano vrijeme

Iako ovo samo ogrebe površinu ovog prekrasnog protokola provjere autentičnosti, dovoljno je da nas pokrenete s našim tutorialom.

3. Razumijevanje SPNEGO-a

SPNEGO je skraćenica od Jednostavni i zaštićeni mehanizam pregovaranja GSS-API. Sasvim ime! Pogledajmo prvo što znači GSS-API. Sučelje aplikacijskog programa generičke sigurnosne usluge (GSS-API) nije ništa drugo nego IETF standard za klijenta i poslužitelja da komuniciraju na siguran i agnatički način dobavljača.

SPNEGO je dio GSS-API-a za klijenta i poslužitelja za pregovaranje o izboru sigurnosnog mehanizma koristiti, na primjer, Kerberos ili NTLM.

4. Zašto trebamo SPNEGO S Kerberosom?

Kao što smo vidjeli u prethodnom odjeljku, Kerberos je čisti protokol mrežne provjere autentičnosti koji djeluje prvenstveno u transportnom sloju (TCP / UDP). Iako je ovo dobro za mnoge slučajeve uporabe, to ne ispunjava zahtjeve za modernim webom. Ako imamo aplikaciju koja djeluje na višoj apstrakciji, poput HTTP-a, nije moguće izravno koristiti Kerberos.

Tu nam SPNEGO dolazi u pomoć. U slučaju web-aplikacije, komunikacija se prvenstveno događa između web-preglednika poput Chromea i web-poslužitelja poput Tomcata koji web-aplikaciju hostira putem HTTP-a. Ako je omogućeno, mogu pregovarajte o Kerberosu kao sigurnosnom mehanizmu putem SPNEGO-a i razmjenjujte karte kao SPNEGO tokene preko HTTP-a.

Pa, kako to mijenja naš prethodno spomenuti scenarij? Zamijenimo naš jednostavni klijent pošte web preglednikom, a poslužitelj pošte web aplikacijom:

Dakle, u ovome se nije puno promijenilo u usporedbi s našim prethodnim dijagramom, osim što se komunikacija između klijenta i poslužitelja sada izričito odvija preko HTTP-a. Shvatimo ovo bolje:

• Klijentski stroj provjerava autentičnost protiv KDC-a i predmemorira TGT
• Web preglednik na klijentskom stroju konfiguriran je za upotrebu SPNEGO-a i Kerberosa
• Web aplikacija je također konfigurirana da podržava SPNEGO i Kerberos
• Web aplikacija baca izazov "Pregovaraj" web pregledniku koji pokušava pristupiti zaštićenom resursu
• Ulaznica za usluge omotana je kao SPNEGO token i razmijenjena kao HTTP zaglavlje

5. Zahtjevi

Prije nego što nastavimo s razvojem web aplikacije koja podržava Kerberos način provjere autentičnosti, moramo prikupiti neke osnovne postavke. Krenimo brzo kroz ove zadatke.

5.1. Postavljanje KDC-a

Postavljanje Kerberos okruženja za proizvodnu upotrebu izvan je dosega ovog vodiča. Ovo nažalost nije trivijalni zadatak, a također je krhak. Dostupno je nekoliko opcija za implementaciju Kerberosa, i otvorenog koda i komercijalne verzije:

• MIT čini implementaciju Kerberos v5 dostupnom za više operativnih sustava
• Apache Kerby je proširenje Apache direktorija, koje pruža vezivanje Java Kerberos
• Windows Server iz Microsofta podržava Kerberos v5 koji izvorno podržava Active Directory
• Heimdel ima implementaciju Kerberos v5

Stvarno postavljanje KDC-a i povezane infrastrukture ovisi o davatelju usluga i trebalo bi ga slijediti iz njihove odgovarajuće dokumentacije. Međutim, Apache Kerby se može pokrenuti unutar Docker spremnika, što ga čini neutralnim za platformu.

5.2. Postavljanje korisnika u KDC

Moramo postaviti dva korisnika - ili, kako oni to nazivaju, ravnatelje - u KDC. U tu svrhu možemo koristiti alat za naredbenu liniju "kadmin". Pretpostavimo da smo stvorili područje pod nazivom "baeldung.com" u KDC bazi podataka i prijavili se u "kadmin" s korisnikom koji ima administratorske privilegije.

Stvorit ćemo prvog korisnika za kojeg želimo provjeriti autentičnost iz web preglednika sa sljedećim:

$ kadmin: addprinc -randkey kchandrakant -pw lozinka Glavni "[zaštićen e-poštom]" stvoren.

Također ćemo morati registrirati našu web aplikaciju kod KDC-a:

$ kadmin: addprinc -randkey HTTP / [e-pošta zaštićena] -pw lozinka Glavni "HTTP / [zaštićen e-poštom]" stvoren.

Ovdje imajte na umu imenovanje principala jer se to mora podudarati s domenom na kojoj je aplikacija dostupna iz web preglednika. Web preglednik automatski pokušava stvoriti naziv glavnog korisnika usluge (SPN) s ovom konvencijom kada se suoči s izazovom „Pregovaraj“.

Ovo također moramo izvesti kao datoteku s tipkovnicom da bi bila dostupna web aplikaciji:

$ kadmin: ktadd -k baeldung.keytab HTTP / [e-pošta zaštićena]

To bi nam trebalo dati datoteku pod nazivom "baeldung.keytab".

5.3. Konfiguracija preglednika

Moramo omogućiti web preglednik koji koristimo za pristup zaštićenom resursu u web aplikaciji za shemu provjere autentičnosti "Pregovaranje". Srećom, većina modernih web preglednika, poput Chromea, prema zadanim postavkama podržava "Pregovaranje" kao shemu provjere autentičnosti.

Osim toga, preglednik možemo konfigurirati tako da pruža "Integriranu autentifikaciju". U ovom načinu rada, kada mu se predoči izazov “Negotiate”, preglednik pokušava iskoristiti predmemorirane vjerodajnice u glavnom računalu, koje je već prijavljeno u KDC nalogodavca. Međutim, ovdje nećemo koristiti ovaj način da bi stvari bile eksplicitne.

5.4. Konfiguracija domene

Razumljivo je da možda nemamo stvarne domene za testiranje naše web aplikacije. Ali nažalost, ne možemo koristiti localhost ili 127.0.0.1 ili bilo koju drugu IP adresu s Kerberos autentifikacijom. Međutim, postoji jednostavno rješenje, koje uključuje postavljanje unosa u datoteku "hosts", poput:

demo.kerberos.bealdung.com 127.0.0.1

6. Proljeće u naše spašavanje!

Napokon, kako smo jasno postavili osnove, vrijeme je da testiramo teoriju. Ali, neće li biti nezgodno stvoriti web aplikaciju koja podržava SPNEGO i Kerberos? Ne ako koristimo proljeće. Spring ima proširenje Kerberos kao dio Spring Securitya koji podržava SPNEGO s Kerberosom neprimjetno.

Gotovo sve što moramo učiniti su samo konfiguracije u Spring Security da omoguće SPNEGO s Kerberosom. Ovdje ćemo koristiti konfiguracije u stilu Java, ali XML konfiguraciju moguće je postaviti tako jednostavno. Možemo produžiti WebSecurityConfigurerAdapter klase za konfiguriranje svega što trebamo.

6.1. Ovisnosti Mavena

Prvo što moramo postaviti su ovisnosti:

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

Te su ovisnosti dostupne za preuzimanje s Maven Central.

6.2. SPNEGO konfiguracije

Prvo, SPNEGO je integriran u Spring Security kao filtar u HTTPSigurnost:

Konfiguracija praznine @Override zaštićena (HttpSecurity http) baca izuzetak {http.authorizeRequests () .anyRequest () .authenticated () .and () .addFilterBefore (spnegoAuthenticationProcessingFilter (authenticationManagerBean ()), BasicAuthentclant.Flayerterter. }

Ovo prikazuje samo dio potreban za konfiguriranje SPNEGO-a filtar a nije cjelovit HTTPSigurnost konfiguraciju, koja bi se trebala konfigurirati prema sigurnosnim zahtjevima aplikacije.

Dalje, moramo pružiti SPNEGO filtar kao Grah:

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

6.3. Kerberos konfiguracije

Uz to, Kerberos možemo konfigurirati dodavanjem AutentificationProvider do AuthenticationManagerBuilder u proljetnoj sigurnosti:

@Override zaštićena void konfiguracija (AuthenticationManagerBuilder auth) baca iznimku {auth .authenticationProvider (kerberosAuthenticationProvider ()) .authenticationProvider (kerberosServiceAuthenticationProvider ()); }

Prvo što moramo pružiti je KerberosAuthenticationProvider kao Grah. Ovo je provedba AutentificationProvider, i ovdje smo postavili SunJaasKerberosClient kao KerberosClient:

@Bean public KerberosAuthenticationProvider kerberosAuthenticationProvider () {KerberosAuthenticationProvider provider = novi KerberosAuthenticationProvider (); SunJaasKerberosClient klijent = novi SunJaasKerberosClient (); provider.setKerberosClient (klijent); provider.setUserDetailsService (userDetailsService ()); povratnik; }

Dalje, također moramo navesti a KerberosServiceAuthenticationProvider kao Grah. Ovo je klasa koja provjerava Kerberos karte za usluge ili SPNEGO žetone:

@Bean public KerberosServiceAuthenticationProvider kerberosServiceAuthenticationProvider () {KerberosServiceAuthenticationProvider provider = novi KerberosServiceAuthenticationProvider (); provider.setTicketValidator (sunJaasKerberosTicketValidator ()); provider.setUserDetailsService (userDetailsService ()); povratnik; }

Na kraju, trebamo dati a SunJaasKerberosTicketValidator kao Grah. Ovo je provedba KerberosTicketValidator i koristi SUN JAAS modul za prijavu:

@Bean public SunJaasKerberosTicketValidator sunJaasKerberosTicketValidator () {SunJaasKerberosTicketValidator ticketValidator = new SunJaasKerberosTicketValidator (); ticketValidator.setServicePrincipal ("HTTP / [e-pošta zaštićena]"); ticketValidator.setKeyTabLocation (novi FileSystemResource ("baeldung.keytab")); povratna kartaValidator; }

6.4. Podaci o korisniku

Vidjeli smo reference na UserDetailsService u našem AutentificationProvider ranije, pa zašto nam to treba? Pa, kako smo upoznali Kerberos, to je isključivo mehanizam provjere autentičnosti koji se temelji na ulaznicama.

Dakle, iako je u stanju identificirati korisnika, ne pruža druge pojedinosti povezane s korisnikom, poput njegovih autorizacija. Treba nam valjana UserDetailsService pod uvjetom da naša AutentificationProvider da popuni ovu prazninu.

6.5. Pokretanje aplikacije

To je uglavnom ono što nam treba za postavljanje web aplikacije s omogućenom Spring Security za SPNEGO s Kerberosom. Kada pokrenemo web aplikaciju i pristupimo bilo kojoj stranici u njoj, web preglednik treba zatražiti korisničko ime i lozinku, pripremiti SPNEGO žeton s Service Ticketom i poslati ga aplikaciji.

Aplikacija bi ga trebala moći obraditi pomoću vjerodajnica u datoteci keytab i odgovoriti uspješnom autentifikacijom.

Međutim, kao što smo vidjeli ranije, postavljanje radnog okruženja Kerberos složeno je i prilično krhko. Ako stvari ne rade kako se očekivalo, vrijedi ponovno provjeriti sve korake. Jednostavna pogreška poput neusklađenosti u nazivu domene može dovesti do neuspjeha s porukama o pogreškama koje nisu posebno korisne.

7. Praktična uporaba SPNEGO-a i Kerberosa

Sad kad smo vidjeli kako radi provjera autentičnosti Kerberos i kako možemo koristiti SPNEGO s Kerberosom u web aplikacijama, možda ćemo dovesti u pitanje potrebu za njom. Iako je potpuno logično koristiti ga kao SSO mehanizam unutar poslovne mreže, zašto bismo to trebali koristiti u web aplikacijama?

Pa, čak se i nakon toliko godina Kerberos i dalje vrlo aktivno koristi unutar poslovnih aplikacija, posebno aplikacija temeljenih na sustavu Windows. Ako organizacija ima nekoliko internih i vanjskih web aplikacija, ima smisla proširiti istu SSO infrastrukturu da ih sve pokrije. To administratorima i korisnicima organizacije znatno olakšava besprijekorno iskustvo putem različitih aplikacija.

8. Zaključak

Da rezimiramo, u ovom uputstvu razumjeli smo osnove protokola provjere autentičnosti Kerberos. Također smo razgovarali o SPNEGO-u kao dijelu GSS-API-ja i kako ga možemo koristiti za olakšavanje provjere autentičnosti na temelju Kerberos-a u web aplikaciji putem HTTP-a. Nadalje, pokušali smo izraditi malu web aplikaciju koja koristi ugrađenu podršku Spring Securitya za SPNEGO s Kerberosom.

Ovaj vodič samo pruža brzi pogled snažnog i vremenski provjerenog mehanizma provjere autentičnosti. Dostupno nam je mnoštvo informacija kako bismo naučili više i možda još više cijenili!

Kao i uvijek, kod se može pronaći na GitHub-u.