streamalism.org

1. Áttekintés

Ebben az oktatóanyagban megismerjük a Kerberos hitelesítési protokoll alapjait. Kitérünk az SPNEGO szükségességére a Kerberos kapcsán is.

Végül meglátjuk, hogyan lehet felhasználni a Spring Security Kerberos kiterjesztést az SPNEGO segítségével a Kerberos számára engedélyezett alkalmazások létrehozásához.

Mielőtt folytatnánk, érdemes megjegyezni, hogy ez a bemutató sok új kifejezést vezet be az e területen ismeretlenek számára. Ezért el fogunk tölteni egy kis időt előre, hogy fedezzük a tereket.

2. Kerberos megértése

A Kerberos egy hálózati hitelesítési protokoll a Massachusettsi Műszaki Intézetben (MIT) fejlesztették ki a nyolcvanas évek elején. Amint rájössz, ez viszonylag régi és kiállta az idő próbáját. A Windows Server széles körben támogatja a Kerberost hitelesítési mechanizmusként, és még az alapértelmezett hitelesítési opcióvá is tette.

Technikailag, A Kerberos jegy alapú hitelesítési protokoll amely lehetővé teszi a számítógépes hálózat csomópontjai számára, hogy azonosítsák önmagukat.

2.1. Kerberos egyszerű használatú tokja

Készítsünk egy hipotetikus helyzetet ennek bemutatására.

Tegyük fel, hogy a felhasználónak a gépén lévő levelező kliensen keresztül az e-mailjeit egy, ugyanazon a hálózaton található másik gépen lévő levelező szerverről kell lekérnie. Itt nyilvánvalóan szükség van a hitelesítésre. A levelező kliensnek és a kiszolgálónak képesnek kell lenniük azonosítani egymást és megbízni abban, hogy biztonságosan kommunikáljanak.

Hogyan segíthet nekünk itt a Kerberos? A Kerberos bemutatja a Key Distribution Center (KDC) nevű harmadik felet, amely kölcsönösen megbízik a hálózat minden csomópontjában. Nézzük meg, hogyan működhet ez a mi esetünkben:

2.2. A Kerberos-protokoll fő szempontjai

Bár ezoterikusnak tűnhet, ez meglehetősen egyszerű és kreatív a biztonságos kommunikáció biztosításában egy nem biztonságos hálózaton keresztül. Az itt bemutatott problémák egy része magától értetődő a TLS korszakában mindenhol!

Bár a Kerberos-protokoll részletes tárgyalása itt nem lehetséges, nézzünk át néhány kiemelkedő szempontot:

• Feltételezzük, hogy a csomópontok (kliens és szerver) és a KDC közötti bizalom itt ugyanazon a tartományon belül létezik
• A jelszót soha nem cserélik a hálózaton keresztül
• A kliens és a kiszolgáló közötti bizalom arra utal, hogy csak a KDC-vel megosztott kulccsal tudják visszafejteni az üzeneteket.
• A kliens és a kiszolgáló közötti bizalom kölcsönös
• Az ügyfél a lejáratig ismételt használatra tárolhatja a jegyeket, egyszeri bejelentkezési élményt biztosítva
• A Hitelesítő üzenetek az időbélyegzőn alapulnak, és így csak egyszer használatosak
• Mindhárom pártnak itt viszonylag szinkronizált idővel kell rendelkeznie

Bár ez csak megkarcolja ennek a gyönyörű hitelesítési protokollnak a felületét, elegendő ahhoz, hogy elindítsuk a bemutatónkat.

3. Az SPNEGO megértése

Az SPNEGO az egyszerű és védett GSS-API tárgyalási mechanizmust jelenti. Elég egy név! Először nézzük meg, mit jelent a GSS-API. A Generic Security Service Application Program Interface (GSS-API) nem más, mint egy IETF szabvány, amellyel az ügyfél és a kiszolgáló biztonságos és szállítói-agnosztikus módon kommunikálhat.

Az SPNEGO a GSS-API része az ügyfél és a kiszolgáló számára, hogy tárgyaljon a biztonsági mechanizmus megválasztásáról például a Kerberos vagy az NTLM használatához.

4. Miért van szükségünk SPNEGO Kerberosszal?

Amint az előző szakaszban láttuk, a Kerberos egy tiszta hálózati hitelesítési protokoll, amely elsősorban a szállítási rétegben (TCP / UDP) működik. Bár ez sok felhasználási esetre jó, ez nem felel meg a modern internet követelményeinek. Ha van olyan alkalmazásunk, amely magasabb absztrakcióval működik, mint például a HTTP, akkor nem lehet közvetlenül használni a Kerberost.

Itt érkezik segítségünkre az SPNEGO. Egy webes alkalmazás esetében a kommunikáció elsősorban egy olyan webböngésző, mint a Chrome, és egy webszerver, például Tomcat között történik, amely a webalkalmazást HTTP-n keresztül tartja. Ha engedélyezve van, akkor megtehetik tárgyaljon a Kerberosról, mint biztonsági mechanizmus az SPNEGO-n keresztül, és jegyeket cseréljen SPNEGO-tokenekként HTTP-n keresztül.

Tehát hogyan változtatja meg ez a korábban említett forgatókönyvünket? Cseréljük le egyszerű levelező kliensünket egy webböngészőre, és a levelező szervert egy webalkalmazásra:

Tehát ebben nem sok változás történt az előző diagramunkhoz képest, kivéve, hogy az ügyfél és a szerver közötti kommunikáció most kifejezetten a HTTP-n keresztül történik. Értsük meg ezt jobban:

• Az ügyfélgép hitelesíti a KDC-t, és gyorsítótárba helyezi a TGT-t
• Az ügyfélgép böngészője az SPNEGO és a Kerberos használatára van beállítva
• A webalkalmazás az SPNEGO és a Kerberos támogatására is konfigurálva van
• A webalkalmazás „tárgyalási” kihívást vet fel a webböngésző számára, aki megpróbál hozzáférni egy védett erőforráshoz
• A Service Ticket SPNEGO tokenként van csomagolva, és HTTP fejlécként kerül kicserélésre

5. Követelmények

Mielőtt tovább tudnánk dolgozni egy Kerberos hitelesítési módot támogató webalkalmazást, össze kell gyűjtenünk néhány alapvető beállítást. Gyorsan végezzük el ezeket a feladatokat.

5.1. A KDC beállítása

A Kerberos-környezet beállítása gyártási célokra meghaladja az oktatóanyag körét. Ez sajnos nem jelentéktelen feladat és törékeny is. Számos lehetőség áll rendelkezésre a Kerberos implementációjának megszerzésére, mind nyílt forráskódú, mind kereskedelmi változatban:

• Az MIT több operációs rendszer számára elérhetővé teszi a Kerberos v5 megvalósítását
• Az Apache Kerby az Apache Directory kiterjesztése, amely Java Kerberos-összerendelést biztosít
• A Microsoft Windows Server támogatja az Active Directory által natív módon támogatott Kerberos v5 verziót
• Heimdel rendelkezik a Kerberos v5 verzióval

A KDC és a kapcsolódó infrastruktúra tényleges felépítése a szolgáltatótól függ, és ezt a megfelelő dokumentációból kell követni. Az Apache Kerby azonban futtatható egy Docker-tárolóban, ami platform-semleges.

5.2. Felhasználók beállítása a KDC-ben

Be kell állítanunk két felhasználót - vagy, ahogy ők hívják, megbízókat - a KDC-be. Erre a célra használhatjuk a „kadmin” parancssori eszközt. Tegyük fel, hogy létrehoztunk egy „baeldung.com” nevű birodalmat a KDC adatbázisban, és adminisztrátori jogosultsággal rendelkező felhasználóval jelentkeztünk be a „kadmin” oldalra.

Első felhasználónkat, akit webböngészőből szeretnénk hitelesíteni, az alábbiakkal hozzuk létre:

$ kadmin: addprinc -randkey kchandrakant -pw jelszó Az "[email protected]" fő létrehozva.

Regisztrálnunk kell webalkalmazásunkat a KDC-nél is:

$ kadmin: addprinc -randkey HTTP / [email protected] -pw jelszó A "HTTP / [email protected]" fő létrehozva.

Vegye figyelembe itt a megbízó megnevezéséről szóló megállapodást, mivel ennek meg kell egyeznie azzal a domainnel, amelyen az alkalmazás elérhető a webböngészőből. A háló a böngésző automatikusan megpróbálja létrehozni a szolgáltatás fő nevét (SPN) ezzel a megállapodással amikor „tárgyalási” kihívással állunk szemben.

Ezt exportálnunk kell kulcstábla fájlként is, hogy elérhető legyen a webalkalmazás számára:

$ kadmin: ktadd -k baeldung.keytab HTTP / [e-mail védett]

Ez megadja nekünk a „baeldung.keytab” nevű fájlt.

5.3. Böngésző konfigurálása

Engedélyeznünk kell azt a webböngészőt, amelyet a webalkalmazás védett erőforrásainak eléréséhez használunk a „Tárgyalás” hitelesítési sémához. Szerencsére a legtöbb modern böngésző, mint például a Chrome, alapértelmezés szerint támogatja a „Tárgyalást” hitelesítési sémaként.

Ezenkívül konfigurálhatjuk a böngészőt az „integrált hitelesítés” biztosítására. Ebben a módban a „Tárgyalás” kihívás elé állításakor a böngésző megpróbálja kihasználni a gyorsítótárazott hitelesítő adatokat a gazdagépen, amelyet már bejelentkeztek egy KDC-főbe. Itt azonban nem használjuk ezt a módot a dolgok egyértelművé tétele érdekében.

5.4. Domain konfigurálása

Érthető, hogy előfordulhat, hogy nincsenek tényleges domainjeink webes alkalmazásunk teszteléséhez. De sajnos nem használhatjuk a localhostot vagy a 127.0.0.1 vagy bármely más IP-címet Kerberos hitelesítéssel. Van azonban egy egyszerű megoldás erre, amely magában foglalja a bejegyzések beállítását a „hosts” fájlban, például:

demo.kerberos.bealdung.com 127.0.0.1

6. Tavasz a megmentésünkhöz!

Végül, amint világosak vagyunk az alapokról, ideje tesztelni az elméletet. De nem lesz nehézkes létrehozni az SPNEGO-t és a Kerberost támogató webalkalmazást? Nem, ha a Tavaszt használjuk. A Spring egy Kerberos kiterjesztéssel rendelkezik a Spring Security részeként, amely támogatja az SPNEGO-t a Kerberos-szal zökkenőmentesen.

Szinte csak annyit kell tennünk, hogy csak a Spring Security konfigurációit engedélyezzük az SPNEGO és a Kerberos számára. Itt Java-stílusú konfigurációkat fogunk használni, de az XML-konfiguráció ugyanolyan egyszerűen beállítható. Meghosszabbíthatjuk a WebSecurityConfigurerAdapter osztály konfigurálhatja mindazt, amire szükségünk van.

6.1. Maven-függőségek

Először a függőségeket kell beállítanunk:

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

Ezek a függőségek letölthetők a Maven Central webhelyről.

6.2. SPNEGO konfigurációk

Először is, az SPNEGO beépül a Spring Security-be, mint a Szűrő ban ben HTTPSbiztonság:

A @Orride védett void configure (HttpSecurity http) dobja a {http.authorizeRequests () .anyRequest () .authenticated () .and () .addFilterBefore (spnegoAuthenticationProcessingFilter (authenticationManagerBean ()), BasicAuthassicationFilter {http.authorizeRequests (). }

Ez csak az SPNEGO konfigurálásához szükséges részt mutatja Szűrő és nem teljes HTTPSbiztonság konfiguráció, amelyet az alkalmazás biztonsági követelményeinek megfelelően kell konfigurálni.

Ezután meg kell adnunk az SPNEGO-t Szűrő mint Bab:

@Bean public SpnegoAuthenticationProcessingFilter spnegoAuthenticationProcessingFilter (AuthenticationManager authenticationManager) {SpnegoAuthenticationProcessingFilter filter = új SpnegoAuthenticationProcessingFilter (); filter.setAuthenticationManager (authenticationManager); visszatérő szűrő; }

6.3. Kerberos konfigurációk

Ezen felül a Kerberost konfigurálhatjuk hozzáadással AuthenticationProvider nak nek AuthenticationManagerBuilder tavaszi biztonságban:

A @Orride védett void configure (AuthenticationManagerBuilder auth) dobja a Exception {auth .authenticationProvider (kerberosAuthenticationProvider ()) .authenticationProvider (kerberosServiceAuthenticationProvider ()); }

Az első dolog, amit meg kell adnunk, a KerberosAuthenticationProvider mint a Bab. Ez a AuthenticationProvider, és itt állítottuk be SunJaasKerberosClient mint a KerberosClient:

@Bean public KerberosAuthenticationProvider kerberosAuthenticationProvider () {KerberosAuthenticationProvider szolgáltató = new KerberosAuthenticationProvider (); SunJaasKerberosClient kliens = new SunJaasKerberosClient (); szolgáltató.setKerberosClient (kliens); szolgáltató.setUserDetailsService (userDetailsService ()); visszatérési szolgáltató; }

Ezután meg kell adnunk a KerberosServiceAuthenticationProvider mint a Bab. Ez az osztály érvényesíti a Kerberos szervizjegyeket vagy az SPNEGO tokeneket:

@Bean public KerberosServiceAuthenticationProvider kerberosServiceAuthenticationProvider () {KerberosServiceAuthenticationProvider szolgáltató = új KerberosServiceAuthenticationProvider (); szolgáltató.setTicketValidator (sunJaasKerberosTicketValidator ()); szolgáltató.setUserDetailsService (userDetailsService ()); visszatérési szolgáltató; }

Végül meg kell adnunk a SunJaasKerberosTicketValidator mint a Bab. Ez a KerberosTicketValidator és használja a SUN JAAS bejelentkezési modult:

@Bean public SunJaasKerberosTicketValidator sunJaasKerberosTicketValidator () {SunJaasKerberosTicketValidator ticketValidator = új SunJaasKerberosTicketValidator (); ticketValidator.setServicePrincipal ("HTTP / [e-mail védett]"); ticketValidator.setKeyTabLocation (új FileSystemResource ("baeldung.keytab")); oda-vissza jegyValidator; }

6.4. Felhasználói adatok

Láttunk utalásokat a UserDetailsService miénkben AuthenticationProvider korábban, akkor miért van szükségünk rá? Nos, amint megismertük a Kerberost, tisztán hitelesítési mechanizmus, amely jegyalapú.

Tehát, bár képes azonosítani a felhasználót, nem ad meg a felhasználóval kapcsolatos egyéb részleteket, például az engedélyeket. Szükségünk van egy érvényes UserDetailsService biztosított a mi AuthenticationProvider hogy pótolja ezt a hiányt.

6.5. Az alkalmazás futtatása

Nagyjából ez az, amire szükségünk van egy webalkalmazás felállításához, a Spring Security engedélyezve van az SPNEGO és a Kerberos között. Amikor elindítjuk a webalkalmazást, és elérjük annak bármely oldalát, a webböngészőnek meg kell kérnie a felhasználónevet és a jelszót, elő kell készítenie az SPNEGO tokent a Service Ticket szolgáltatással, és el kell küldenie az alkalmazásnak.

Az alkalmazásnak képesnek kell lennie a kulcstáblázatban szereplő hitelesítő adatok használatára, és sikeres hitelesítéssel kell válaszolnia.

Mint azonban korábban láttuk, a működő Kerberos-környezet beállítása bonyolult és meglehetősen törékeny. Ha a dolgok nem a várt módon működnek, érdemes újra ellenőrizni az összes lépést. Egy olyan egyszerű hiba, mint a tartománynév eltérése, hibához vezethet a különösebben nem hasznos hibaüzeneteknél.

7. Az SPNEGO és a Kerberos gyakorlati alkalmazása

Most, hogy láttuk, hogyan működik a Kerberos hitelesítés, és hogyan tudjuk használni az SPNEGO-t a Kerberos-szal webes alkalmazásokban, megkérdőjelezhetjük annak szükségességét. Bár ez teljesen logikus SSO-mechanizmusként használni egy vállalati hálózaton belül, miért használnánk ezt webes alkalmazásokban?

Nos, egy ideig, még ennyi év után is, a Kerberost továbbra is nagyon aktívan használják a vállalati alkalmazásokon belül, különösen a Windows-alapú alkalmazásokon. Ha egy szervezetnek több belső és külső webalkalmazása van, akkor ennek van értelme kiterjessze ugyanazt az egyszeri bejelentkezési infrastruktúrát, hogy lefedje őket. Ez sokkal könnyebbé teszi a rendszergazdák és a felhasználók felhasználói számára a zökkenőmentes élményt az eltérő alkalmazások révén.

8. Következtetés

Összefoglalva: ebben az oktatóanyagban megértettük a Kerberos hitelesítési protokoll alapjait. Megbeszéltük az SPNEGO-t is a GSS-API részeként, és arról, hogyan használhatjuk a Kerberos-alapú hitelesítés megkönnyítésére egy webes alkalmazásban HTTP-n keresztül. Ezenkívül megpróbáltunk létrehozni egy kis webalkalmazást, amely kihasználja a Spring Security beépített SPNEGO támogatását a Kerberos-szal.

Ez az oktatóanyag csak egy gyors és bepillantást nyújt az erős és idővel bevált hitelesítési mechanizmusokból. Rengeteg információ áll rendelkezésünkre, hogy többet tanulhassunk és esetleg még többet értékeljünk!

Mint mindig, a kód megtalálható a GitHubon.