Úvod do autentifikácie SPNEGO / Kerberos na jar

1. Prehľad

V tomto tutoriáli pochopíme základy autentifikačného protokolu Kerberos. Pokryjeme tiež potrebu protokolu SPNEGO v súvislosti s protokolom Kerberos.

Na záver uvidíme, ako využiť rozšírenie Spring Security Kerberos na vytvorenie aplikácií povolených pre protokol Kerberos pomocou protokolu SPNEGO.

Predtým, ako budeme pokračovať, stojí za zmienku, že tento tutoriál predstaví mnoho nových výrazov pre tých, ktorí v tejto oblasti nie sú iniciovaní. Preto strávime nejaký čas vopred, aby sme zakryli pozemok.

2. Porozumenie protokolu Kerberos

Kerberos je protokol sieťovej autentifikácie vyvinutý na Massachusetts Institute of Technology (MIT) začiatkom osemdesiatych rokov. Ako si možno uvedomujete, je to pomerne staré a obstálo v skúške času. Windows Server vo veľkej miere podporuje Kerberos ako mechanizmus autentifikácie a urobil z neho dokonca predvolenú možnosť autentifikácie.

Technicky Kerberos je autentifikačný protokol založený na lístkoch ktorý umožňuje uzlom v počítačovej sieti navzájom sa identifikovať.

2.1. Jednoduché použitie pre protokol Kerberos

Vytvorme hypotetickú situáciu, aby sme to demonštrovali.

Predpokladajme, že používateľ prostredníctvom svojho poštového klienta na svojom počítači musí sťahovať svoje e-maily z poštového servera na inom počítači v tej istej sieti. Tu je zjavná potreba autentifikácie. Poštový klient a poštový server musia byť schopní navzájom sa identifikovať a dôverovať si v bezpečnú komunikáciu.

Ako nám tu môže Kerberos pomôcť? Spoločnosť Kerberos predstavuje tretiu stranu s názvom Key Distribution Center (KDC), ktorá má vzájomnú dôveru s každým uzlom v sieti. Pozrime sa, ako to môže v našom prípade fungovať:

2.2. Kľúčové aspekty protokolu Kerberos

Aj keď to môže znieť ezotericky, je to celkom jednoduché a kreatívne pri zabezpečovaní komunikácie cez nezabezpečenú sieť. Niektoré z tu uvedených problémov sú v dobe TLS všade samozrejmosťou!

Aj keď tu nie je možná podrobná diskusia o protokole Kerberos, prejdime si niektoré dôležité aspekty:

  • Predpokladá sa, že tu existuje dôvera medzi uzlami (klientom a serverom) a KDC v tej istej sfére
  • Heslo sa nikdy nevymieňa v sieti
  • Dôvera medzi klientom a serverom je implikovaná na základe skutočnosti, že môžu dešifrovať správy pomocou kľúča zdieľaného iba s KDC
  • Dôvera medzi klientom a serverom je vzájomná
  • Klient môže do opakovaného použitia ukladať lístky do opakovaného použitia až do vypršania platnosti, čím poskytuje skúsenosť s jednotným prihlásením
  • Správy aplikácie Authenticator sú založené na časovej pečiatke, a preto sú dobré iba na jednorazové použitie
  • Všetky tri strany tu musia mať relatívne synchronizovaný čas

Aj keď to len poškriabe povrch tohto krásneho autentifikačného protokolu, je dostatočné na to, aby sme začali s naším tutoriálom.

3. Pochopenie SPNEGO

SPNEGO je skratka pre Simple and Protected GSS-API Negotiation Mechanism. Celkom meno! Najprv sa pozrime, čo znamená GSS-API. Generické bezpečnostné aplikačné programové rozhranie (GSS-API) nie je ničím iným ako štandardom IETF pre komunikáciu medzi klientom a serverom bezpečným a agendickým spôsobom.

SPNEGO je súčasťou GSS-API pre klienta a server pri rokovaniach o výbere bezpečnostného mechanizmu používať napríklad Kerberos alebo NTLM.

4. Prečo potrebujeme SPNEGO S Kerberosom?

Ako sme videli v predchádzajúcej časti, Kerberos je čistý sieťový autentifikačný protokol fungujúci predovšetkým v transportnej vrstve (TCP / UDP). Aj keď je to dobré pre veľa prípadov použitia, nespĺňa to požiadavky na moderný web. Ak máme aplikáciu, ktorá pracuje na vyššej abstrakcii, napríklad HTTP, nie je možné použiť protokol Kerberos priamo.

Tu nám prichádza na pomoc SPNEGO. V prípade webovej aplikácie komunikácia primárne prebieha medzi webovým prehliadačom, ako je Chrome, a webovým serverom, ako je Tomcat, ktorý hostuje webovú aplikáciu prostredníctvom protokolu HTTP. Ak je to povolené, môžu vyjednávať Kerberos ako bezpečnostný mechanizmus prostredníctvom SPNEGO a vymieňať si lístky ako tokeny SPNEGO cez HTTP.

Ako to teda zmení náš skôr spomínaný scenár? Nahraďme nášho jednoduchého poštového klienta webovým prehliadačom a poštový server webovou aplikáciou:

V porovnaní s našim predchádzajúcim diagramom sa teda v tomto veľa nezmenilo, až na to, že komunikácia medzi klientom a serverom sa teraz deje explicitne cez HTTP. Pochopme to lepšie:

  • Klientský počítač sa autentizuje proti KDC a ukladá do medzipamäte TGT
  • Webový prehľadávač na klientskom počítači je nakonfigurovaný na používanie SPNEGO a Kerberos
  • Webová aplikácia je tiež nakonfigurovaná tak, aby podporovala protokoly SPNEGO a Kerberos
  • Webová aplikácia vrhá výzvu „Vyjednávať“ na webový prehliadač, ktorý sa pokúša získať prístup k chránenému prostriedku
  • Servisný lístok je zabalený ako token SPNEGO a vymieňa sa ako hlavička HTTP

5. Požiadavky

Predtým, ako budeme môcť pokračovať vo vývoji webovej aplikácie, ktorá podporuje režim autentifikácie pomocou protokolu Kerberos, musíme zhromaždiť základné nastavenie. Poďme si rýchlo prejsť týmito úlohami.

5.1. Nastavenie KDC

Nastavenie prostredia Kerberos na produkčné použitie je nad rámec tohto tutoriálu. To, bohužiaľ, nie je triviálna a krehká úloha. Existuje niekoľko možností, ako získať implementáciu protokolu Kerberos, a to ako open source, tak aj komerčnú verziu:

  • MIT sprístupňuje implementáciu protokolu Kerberos v5 pre viaceré operačné systémy
  • Apache Kerby je rozšírenie servera Apache Directory, ktoré poskytuje väzbu Java Kerberos
  • Windows Server od spoločnosti Microsoft podporuje server Kerberos v5 natívne zálohovaný službou Active Directory
  • Heimdel má implementáciu Kerberos v5

Skutočné nastavenie KDC a súvisiacej infraštruktúry závisí od poskytovateľa a malo by sa riadiť z ich príslušnej dokumentácie. Apache Kerby je však možné spustiť vo vnútri kontajnera Docker, vďaka čomu je platformovo neutrálny.

5.2. Nastavenie používateľov v KDC

Musíme nastaviť dvoch používateľov - alebo, ako sa im hovorí, riaditeľov - v KDC. Na tento účel môžeme použiť nástroj príkazového riadku „kadmin“. Predpokladajme, že sme v databáze KDC vytvorili sféru s názvom „baeldung.com“ a prihlásili sme sa do „kadmin“ s používateľom, ktorý má oprávnenie správcu.

Vytvoríme nášho prvého používateľa, ktorého chceme overiť pomocou webového prehliadača, pomocou:

$ kadmin: addprinc -randkey kchandrakant -pw heslo Principál "[chránený e-mailom]" bol vytvorený.

Budeme tiež musieť zaregistrovať našu webovú aplikáciu v KDC:

$ kadmin: addprinc -randkey HTTP / [chránené e-mailom] -pw heslo Bol vytvorený principál „HTTP / [chránený e-mailom]“.

Všimnite si tu konvenciu pomenovania príkazcu, ktorá sa musí zhodovať s doménou, na ktorú je aplikácia prístupná z webového prehliadača. Sieť Prehliadač sa pomocou tejto konvencie automaticky pokúsi vytvoriť názov hlavnej služby (SPN) keď sa im zobrazí výzva „Vyjednávať“.

Potrebujeme to tiež exportovať ako súbor tabuľky kľúčov, aby sme ju sprístupnili webovej aplikácii:

$ kadmin: ktadd -k baeldung.keytab HTTP / [chránené e-mailom]

Toto by nám malo poskytnúť súbor s názvom „baeldung.keytab“.

5.3. Konfigurácia prehľadávača

Musíme povoliť webový prehliadač, ktorý používame na prístup k chránenému prostriedku vo webovej aplikácii pre autentifikačnú schému „Vyjednávať“. Väčšina moderných webových prehliadačov, ako je Chrome, našťastie podporuje ako predvolenú schému overenia totožnosti „Negotiate“.

Ďalej môžeme prehľadávač nakonfigurovať tak, aby poskytoval „integrované overenie“. V tomto režime, keď sa mu zobrazí výzva „Vyjednávať“, sa prehliadač pokúsi využiť poverenia uložené v pamäti v hostiteľskom počítači, ktorý už bol prihlásený do principálu KDC. Tento režim tu však nebudeme používať, aby boli veci explicitné.

5.4. Konfigurácia domény

Je pochopiteľné, že na testovanie našej webovej aplikácie nemusíme mať skutočné domény. Bohužiaľ však s autentifikáciou pomocou protokolu Kerberos nemôžeme použiť localhost alebo 127.0.0.1 ani inú IP adresu. Existuje však jednoduché riešenie, ktoré spočíva v nastavení položiek v súbore „hosts“, ako napríklad:

demo.kerberos.bealdung.com 127.0.0.1

6. Jar na našu záchranu!

Nakoniec, keď už máme základné objasnené, je čas vyskúšať teóriu. Nebude však ťažkopádne vytvárať webovú aplikáciu podporujúcu SPNEGO a Kerberos? Nie, ak použijeme Spring. Jar má rozšírenie Kerberos ako súčasť zabezpečenia Spring, ktoré podporuje protokol SPNEGO s protokolom Kerberos plynulo.

Takmer všetko, čo musíme urobiť, sú iba konfigurácie v Spring Security, ktoré umožnia SPNEGO s Kerberos. Použijeme tu konfigurácie v štýle Java, ale konfiguráciu XML je možné nastaviť rovnako ľahko. Môžeme predĺžiť WebSecurityConfigurerAdapter triedy nakonfigurovať všetko, čo potrebujeme.

6.1. Maven závislosti

Prvá vec, ktorú musíme nastaviť, sú závislosti:

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

Tieto závislosti sú k dispozícii na stiahnutie z Maven Central.

6.2. Konfigurácie SPNEGO

Po prvé, SPNEGO je integrovaný do Spring Security ako a Filtrovať v HTTPSecurity:

@Override protected void configure (HttpSecurity http) vyvolá výnimku {http.authorizeRequests () .anyRequest () .authenticated () .and () .addFilterBefore (spnegoAuthenticationProcessingFilter (authenticationManagerBean ()), BasicAuthenticationFilter.class) }

Toto zobrazuje iba časť potrebnú na konfiguráciu SPNEGO Filtrovať a nie je úplná HTTPSecurity konfigurácia, ktorá by mala byť nakonfigurovaná podľa bezpečnostných požiadaviek aplikácie.

Ďalej musíme poskytnúť SPNEGO Filtrovať ako Bean:

@Bean public SpnegoAuthenticationProcessingFilter spnegoAuthenticationProcessingFilter (AuthenticationManager authenticationManager) {SpnegoAuthenticationProcessingFilter filter = nový SpnegoAuthenticationProcessingFilter (); filter.setAuthenticationManager (authenticationManager); spätný filter; }

6.3. Konfigurácie protokolu Kerberos

Okrem toho môžeme nakonfigurovať protokol Kerberos pridaním AuthenticationProvider do AuthenticationManagerBuilder na jar bezpečnosť:

@Override protected void configure (AuthenticationManagerBuilder auth) hodí výnimku {auth .authenticationProvider (kerberosAuthenticationProvider ()) .authenticationProvider (kerberosServiceAuthenticationProvider ()); }

Prvá vec, ktorú musíme poskytnúť, je Poskytovateľ KerberosAuthenticationProvider ako Bean. Toto je implementácia AuthenticationProvider, a tu sme nastavili SunJaasKerberosClient ako KerberosClient:

@Bean public KerberosAuthenticationProvider kerberosAuthenticationProvider () {poskytovateľ KerberosAuthenticationProvider = nový KerberosAuthenticationProvider (); Klient SunJaasKerberosClient = nový SunJaasKerberosClient (); provider.setKerberosClient (klient); provider.setUserDetailsService (userDetailsService ()); poskytovateľ návratu; }

Ďalej musíme tiež poskytnúť a KerberosServiceAuthenticationProvider ako Bean. Toto je trieda, ktorá validuje lístky na službu Kerberos alebo tokeny SPNEGO:

@Bean public KerberosServiceAuthenticationProvider kerberosServiceAuthenticationProvider () {KerberosServiceAuthenticationProvider provider = nový KerberosServiceAuthenticationProvider (); provider.setTicketValidator (sunJaasKerberosTicketValidator ()); provider.setUserDetailsService (userDetailsService ()); poskytovateľ návratu; }

Nakoniec musíme poskytnúť a SunJaasKerberosTicketValidator ako Bean. Toto je implementácia KerberosTicketValidator a používa prihlasovací modul SUN JAAS:

@Bean public SunJaasKerberosTicketValidator sunJaasKerberosTicketValidator () {SunJaasKerberosTicketValidator ticketValidator = nový SunJaasKerberosTicketValidator (); ticketValidator.setServicePrincipal ("HTTP / [chránený e-mailom]"); ticketValidator.setKeyTabLocation (nový FileSystemResource ("baeldung.keytab")); spiatočný lístokValidátor; }

6.4. Detaily používateľa

Videli sme odkazy na a UserDetailsService v našom AuthenticationProvider skôr, tak prečo to potrebujeme? Ako sme sa už oboznámili s protokolom Kerberos, je to čisto autentifikačný mechanizmus založený na lístkoch.

Aj keď je schopný identifikovať používateľa, neposkytuje ďalšie podrobnosti týkajúce sa používateľa, napríklad jeho autorizácie. Potrebujeme platný UserDetailsService poskytované našim AuthenticationProvider na vyplnenie tejto medzery.

6.5. Spustenie aplikácie

To je vlastne to, čo potrebujeme na nastavenie webovej aplikácie s povoleným Spring Security pre SPNEGO s Kerberos. Keď spustíme webovú aplikáciu a otvoríme ktorúkoľvek stránku v nej uvedenú, webový prehliadač by mal vyzvať na zadanie používateľského mena a hesla, pripraviť token SPNEGO so službou Ticket a odoslať ju do aplikácie.

Aplikácia by mala byť schopná spracovať ho pomocou poverení v súbore keytab a reagovať s úspešnou autentifikáciou.

Ako sme však videli skôr, nastavenie funkčného prostredia Kerberos je komplikované a dosť krehké. Ak veci nefungujú podľa očakávaní, stojí za to skontrolovať všetky kroky znova. Jednoduchá chyba, napríklad nesúlad názvu domény, môže viesť k zlyhaniu chybových správ, ktoré nie sú nijako zvlášť užitočné.

7. Praktické použitie SPNEGO a Kerberos

Teraz, keď sme videli, ako funguje autentifikácia pomocou protokolu Kerberos a ako môžeme používať protokol SPNEGO s protokolom Kerberos vo webových aplikáciách, môžeme si položiť otázku, či je to potrebné. Aj keď to má úplný zmysel používať ako mechanizmus jednotného prihlásenia v rámci podnikovej siete, prečo by sme to mali používať vo webových aplikáciách?

No, po prvé, aj po toľkých rokoch sa Kerberos stále veľmi aktívne používa v rámci podnikových aplikácií, najmä aplikácií založených na systéme Windows. Ak má organizácia niekoľko interných a externých webových aplikácií, má to zmysel rozšíriť rovnakú infraštruktúru SSO tak, aby pokryla všetky. To výrazne uľahčuje správcom a používateľom organizácie bezproblémové používanie rôznych aplikácií.

8. Záver

Ak to zhrnieme, v tomto tutoriáli sme pochopili základy autentifikačného protokolu Kerberos. Diskutovali sme tiež o SPNEGO ako súčasti GSS-API a o tom, ako ho môžeme použiť na uľahčenie autentifikácie na základe protokolu Kerberos vo webovej aplikácii cez HTTP. Ďalej sme sa pokúsili vytvoriť malú webovú aplikáciu využívajúcu integrovanú podporu Spring Security pre SPNEGO s protokolom Kerberos.

Tento tutoriál poskytuje iba rýchly prehľad o výkonnom a časom overenom mechanizme autentifikácie. K dispozícii je množstvo informácií, vďaka ktorým sa môžeme dozvedieť viac a možno ešte viac oceniť!

Ako vždy, kód nájdete na GitHub.


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