X.509 Hitelesítés a tavaszi biztonságban

1. Áttekintés

Ebben a cikkben az X.509 tanúsítvány hitelesítésének főbb eseteire fogunk összpontosítani - a kommunikációs társ identitásának ellenőrzése amikor a HTTPS (HTTP over SSL) protokollt használja.

Egyszerűen fogalmazva - amíg létrejön egy biztonságos kapcsolat, az ügyfél igazolja a szervert a tanúsítványának megfelelően (amelyet egy megbízható tanúsító hatóság ad ki).

De ezen túl az X.509 a Spring Security-ben is használható ellenőrizze az ügyfél személyazonosságát a szerver csatlakozás közben. Ezt úgy hívják „Kölcsönös hitelesítés”, és megnézzük itt is, hogy ez hogyan történik.

Végül érintjük amikor van értelme használni ezt a fajta hitelesítést.

A szerverellenőrzés bemutatásához létrehozunk egy egyszerű webalkalmazást, és egy egyéni tanúsító hatóságot telepítünk egy böngészőbe.

Sőt, azért kölcsönös hitelesítés, létrehozunk egy ügyféltanúsítványt és módosítjuk a szerverünket, hogy csak ellenőrzött ügyfeleket engedélyezzünk.

Nagyon ajánlott, hogy kövesse az oktatóanyagot lépésről lépésre, és saját maga hozza létre a tanúsítványokat, valamint a kulcstárat és a truststore-ot a következő szakaszokban bemutatott utasításoknak megfelelően. Azonban az összes használatra kész fájl megtalálható a GitHub adattárunkban.

2. Saját aláírású gyökér CA

A kiszolgálói és kliens oldali tanúsítványaink aláírásához először létre kell hoznunk saját, saját aláírású gyökér CA tanúsítványt. Ily módon a saját tanúsító hatóságunkként fogunk eljárni.

Erre a célra az openssl könyvtárat fogjuk használni, ezért a következő lépés végrehajtása előtt telepítenünk kell.

Most hozzuk létre a CA tanúsítványt:

openssl req -x509 -sha256 -days 3650 -newkey rsa: 4096 -keyout rootCA.key -out rootCA.crt

A fenti parancs végrehajtásakor meg kell adnunk a privát kulcsunk jelszavát. A bemutató céljára a következőket használjuk: változtasd meg jelszóként.

Ezenkívül olyan információkat kell megadnunk, amelyek úgynevezett megkülönböztető nevet alkotnak. Itt csak a CN-t (közönséges név) - Baeldung.com - adjuk meg, a többi részt pedig üresen hagyjuk.

3. Kulcstár

Opcionális követelmény: A kriptográfiailag erős kulcsok, valamint a titkosítási és visszafejtési funkciók használatához szükségünk lesz a “Java kriptográfiai kiterjesztés (JCE) korlátlan erősségű joghatósági házirend-fájlok”Telepítve a JVM-be.

Ezek például letölthetők az Oracle-ről (kövesse a letöltéshez mellékelt telepítési utasításokat). Néhány Linux disztribúció telepíthető csomagot is biztosít a csomagkezelőkön keresztül.

A kulcstár olyan adattár, amelyet a Spring Boot alkalmazásunk a szerverünk magánkulcsának és tanúsítványának tárolására fog használni. Más szavakkal, alkalmazásunk a kulcstárolóval fogja kiszolgálni a tanúsítványt az ügyfelek számára az SSL kézfogás során.

Ebben az oktatóanyagban a Java Key-Store (JKS) formátum és egy kulcseszköz parancssori eszköz.

3.1. Kiszolgálóoldali tanúsítvány

A szerveroldali X.509 hitelesítésnek a Spring Boot alkalmazásban történő megvalósításához először létre kell hozni egy szerveroldali tanúsítványt.

Kezdjük egy úgynevezett tanúsítvány-aláírási kérelem (CSR) létrehozásával:

openssl req -new -newkey rsa: 4096 -keyout localhost.key –out localhost.csr

Hasonlóképpen, mint a CA tanúsítvány esetében, meg kell adnunk a privát kulcs jelszavát. Ezenkívül használjuk helyi kiszolgáló mint közönséges név (CN).

Mielőtt továbblépnénk, létre kell hoznunk egy konfigurációs fájlt - localhost.ext. A tanúsítvány aláírásakor tárol néhány további paramétert.

AuthorityKeyIdentifier = kulcsazonosító, kibocsátó basicConstraints = CA: FALSE subjectAltName = @alt_names [alt_names] DNS.1 = localhost

Használatra kész fájl itt is elérhető.

Itt az ideje írja alá a kérést a mi rootCA.crt tanúsítvány és annak magánkulcsa:

openssl x509 -req -CA rootCA.crt -CAkey rootCA.key -in localhost.csr -out localhost.crt -days 365 -CAcreateserial -extfile localhost.ext

Ne feledje, hogy ugyanazt a jelszót kell megadnunk, amelyet a CA tanúsítvány létrehozásakor használtunk.

Ezen a ponton, végre készen állunk a használatra localhost.crt a saját tanúsító hatóságunk által aláírt tanúsítvány.

A tanúsítvány adatainak ember által olvasható formában történő kinyomtatásához a következő parancsot használhatjuk:

openssl x509 -in localhost.crt -text

3.2. Importálás a kulcstárba

Ebben a szakaszban megtudjuk, hogyan kell importálja az aláírt tanúsítványt és a hozzá tartozó magánkulcsot a kulcstár.jks fájl.

A PKCS 12 archívum segítségével csomagoljuk szerverünk magánkulcsát az aláírt tanúsítvánnyal együtt. Ezután importáljuk az újonnan létrehozottba kulcstár.jks.

A következő paranccsal létrehozhatjuk a .p12 fájl:

openssl pkcs12 -export -out localhost.p12 -name "localhost" -inkey localhost.key -in localhost.crt

Tehát most megvan a localhost.key és a localhost.crt a kislemezbe csomagolva localhost.p12 fájl.

Most használjuk a kulcseszközt hozzon létre egy kulcstár.jks adattárat és importálja a localhost.p12 fájl egyetlen paranccsal:

keytool -importkeystore -srckeystore localhost.p12 -srcstoretype PKCS12 -destkeystore keystore.jks -deststoretype JKS

Ebben a szakaszban minden a helyén van a szerver hitelesítési részhez. Folytassuk a Spring Boot alkalmazás konfigurációjával.

4. Példa alkalmazásra

Az SSL biztonságos szerver projektünk a @SpringBootApplication kommentált alkalmazásosztály (ami egyfajta @ Konfiguráció), an alkalmazás.tulajdonságok konfigurációs fájl és egy nagyon egyszerű MVC stílusú kezelőfelület.

Az alkalmazásnak csak annyit kell tennie, hogy bemutat egy HTML oldalt a-val "Helló {User}!" üzenet. Így ellenőrizhetjük a szerver tanúsítványt egy böngészőben, hogy megbizonyosodhassunk arról, hogy a kapcsolat igazolt és biztonságos.

4.1. Maven-függőségek

Először egy új Maven projektet hozunk létre, amely három Spring Boot Starter csomagot tartalmaz:

 org.springframework.boot spring-boot-starter-security org.springframework.boot spring-boot-starter-web org.springframework.boot spring-boot-starter-thymeleaf 

Referenciaként: a kötegeket megtalálhatjuk a Maven Central-on (biztonsági, webes, thymeleaf).

4.2. Tavaszi csomagtartó alkalmazás

Következő lépésként létrehozzuk a fő alkalmazásosztályt és a felhasználói vezérlőt:

@SpringBootApplication public class X509AuthenticationServer {public static void main (String [] args) {SpringApplication.run (X509AuthenticationServer.class, args); }} @Controller public class UserController {@RequestMapping (value = "/ user") public String user (Model model, Principal principal) {UserDetails currentUser = (UserDetails) ((Authentication) basic) .getPrincipal (); model.addAttribute ("felhasználónév", currentUser.getUsername ()); return "felhasználó"; }}

Most elmondjuk az alkalmazásnak, hogy hol találjuk meg a sajátunkat kulcstár.jks és hogyan lehet elérni. Az SSL-t „engedélyezett” állapotra állítjuk, és a szokásos hallgatási portot megváltoztatjuk jelezzen biztonságos kapcsolatot.

Ezenkívül konfigurálunk néhányat felhasználói adatok szerverünkhöz az alap hitelesítéssel történő eléréshez:

server.ssl.key-store = .. / store / keystore.jks server.ssl.key-store-password = $ {PASSWORD} server.ssl.key-alias = localhost server.ssl.key-password = $ {PASSWORD } server.ssl.enabled = true server.port = 8443 spring.security.user.name = Rendszergazda spring.security.user.password = admin

Ez lesz a HTML sablon, amely a források / sablonok mappa:

   X.509 hitelesítési bemutató 

Helló !

4.3. Root CA telepítés

Mielőtt befejeznénk ezt a részt és megnéznénk a webhelyet, telepítenünk kell a létrehozott gyökértanúsítvány-jogosultságot megbízható tanúsítványként egy böngészőbe.

A. Tanúsító hatóságunk példamutató telepítése Mozilla Firefox a következőképpen nézne ki:

  1. típus körülbelül: preferenciák a címsorban
  2. Nyisd ki Haladó -> Tanúsítványok -> Tanúsítványok megtekintése -> Hatóságok
  3. Kattintson Importálás
  4. Keresse meg a Baeldung oktatóanyagok mappa és annak almappája spring-security-x509 / kulcstár
  5. Válaszd ki a rootCA.crt fájlt, és kattintson a gombra rendben
  6. Választ "Bízzon ebben a CA-ban a webhelyek azonosításában ” és kattintson rendben

Jegyzet: Ha nem akarja hozzáadni a tanúsító hatóság listájára megbízható hatóságok, később lehetősége lesz egy kivétel és keménynek mutassa a weboldalt, még akkor is, ha bizonytalanként említik. De ekkor a címsávban megjelenik egy „sárga felkiáltójel” szimbólum, amely a bizonytalan kapcsolatot jelzi!

Utána navigálunk a spring-security-x509-basic-auth modul és futtassa:

mvn spring-boot: fut

Végül eltaláltuk // localhost: 8443 / user, adja meg felhasználói hitelesítő adatainkat a alkalmazás.tulajdonságok és látnia kell a - Helló Admin! üzenet. Most ellenőrizhetjük a kapcsolat állapotát a címsávban található „zöld zár” szimbólumra kattintva, és biztonságos kapcsolatnak kell lennie.

5. Kölcsönös hitelesítés

Az előző részben bemutattuk a leggyakoribb SSL-hitelesítési séma - a szerveroldali hitelesítés - megvalósítását. Ez azt jelenti, hogy csak egy szerver hitelesítette magát az ügyfelek számára.

Ebben a részben, leírjuk, hogyan adható hozzá a hitelesítés másik része - az ügyféloldali hitelesítés. Így csak azok az ügyfelek férhetnek hozzá biztonságos webhelyünkhöz, akiknek a szerverünkben megbízott hatóság által aláírt érvényes tanúsítványai vannak.

De mielőtt folytatnánk, nézzük meg, milyen előnyei és hátrányai vannak a kölcsönös SSL-hitelesítés használatának.

Előnyök:

  • Egy X.509 magánkulcsa az ügyféltanúsítvány erősebb, mint bármely felhasználó által definiált jelszó. De titokban kell tartani!
  • Tanúsítvánnyal a az ügyfél kiléte jól ismert és könnyen ellenőrizhető.
  • Nincs több elfelejtett jelszó!

Hátrányok:

  • Minden új ügyfél számára létre kell hoznunk egy tanúsítványt.
  • Az ügyfél tanúsítványát telepíteni kell egy ügyfélalkalmazásba. Valójában: Az X.509 ügyfél-hitelesítés eszközfüggő, ami lehetetlenné teszi az ilyen típusú hitelesítés használatát a nyilvános helyiségekben, például egy internetes kávézóban.
  • Léteznie kell egy mechanizmusnak a sérült ügyféltanúsítványok visszavonására.
  • Fenn kell tartanunk az ügyfelek tanúsítványait. Ez könnyen költségessé válhat.

5.1. Truststore

A trustsore valamilyen módon ellentétes a kulcstárral. Tartalmazza a megbízható külső entitások tanúsítványait.

Esetünkben elég, ha a gyökér CA tanúsítványt a truststore-ban tároljuk.

Nézzük meg, hogyan lehet létrehozni egy truststore.jks fájlt, és importálja a rootCA.crt a kulcseszköz használatával:

keytool -import -trustcacerts -noprompt -alias ca -ext san = dns: localhost, ip: 127.0.0.1 -file rootCA.crt -keystore truststore.jks

Megjegyzés: meg kell adnunk az újonnan létrehozott jelszót trusstore.jks. Itt megint a változtasd meg jelszó.

Ennyi, importáltuk saját CA tanúsítványunkat, és a truststore használatra kész.

5.2. Tavaszi biztonsági konfiguráció

A folytatáshoz módosítjuk a sajátunkat X509AuthenticationServer -tól meghosszabbítani WebSecurityConfigurerAdapter és felülírja a megadott konfigurációs módszerek egyikét. Itt konfiguráljuk az x.509 mechanizmust a Közönséges név (KN) a tanúsítvány mezője a felhasználónevek kibontására.

Ezzel a kibontott felhasználónévvel a Spring Security egy feltöltött helyen keres UserDetailsService a felhasználók megfeleltetéséhez. Tehát megvalósítjuk ezt az egy demo felhasználót tartalmazó szolgáltatási felületet is.

Tipp: Termelési környezetekben ez UserDetailsService például a JDBC adatforrásból töltheti be a felhasználóit.

Észre kell vennie, hogy az osztályunkat feljegyezzük @EnableWebSecurity és @EnableGlobalMethodSecurity engedélyezett előzetes / utáni engedélyezéssel.

Ez utóbbival feljegyezhetjük erőforrásainkat @PreAuthorize és @PostAuthorize finomszemcsés beléptető ellenőrzéshez:

@SpringBootApplication @EnableWebSecurity @EnableGlobalMethodSecurity (prePostEnabled = true) X509AuthenticationServer kiterjeszti a WebSecurityConfigurerAdapter {... {return new UserDetailsService () {@Orride public UserDetails loadUserByUsername (String username) {if (username.equals ("Bob")) {return new User (felhasználónév, "", AuthorityUtils .commaSeparatedStringToAuthorityList ("ROLE_USER")); új UsernameNotFoundException ("A felhasználó nem található!");}};}}

Mint korábban említettük, most már képesek vagyunk használni Kifejezés-alapú hozzáférés-vezérlés vezérlőnkben. Pontosabban, az engedélyezési jegyzeteinket a @EnableGlobalMethodSecurity annotáció a mi @ Konfiguráció:

@Controller public class UserController {@PreAuthorize ("hasAuthority ('ROLE_USER')") @RequestMapping (value = "/ user") public String user (Model model, Principal principal) {...}}

Az összes lehetséges engedélyezési lehetőség áttekintése megtalálható a hivatalos dokumentáció.

Utolsó módosítási lépésként meg kell mondanunk az alkalmazásnak, hogy hol vagyonkezelő található és az SSL kliens hitelesítés szükséges (server.ssl.client-auth = szükség).

Tehát a következőket tettük bele alkalmazás.tulajdonságok:

server.ssl.trust-store = store / truststore.jks server.ssl.trust-store-password = $ {JELSZÓ} server.ssl.client-auth = szükség

Most, ha futtatjuk az alkalmazást, és a böngészőnkre mutatunk // localhost: 8443 / user, értesülünk arról, hogy a társ nem ellenőrizhető, és tagadja a weboldalunk megnyitását.

5.3. Ügyféloldali tanúsítvány

Itt az ideje az ügyféloldali tanúsítvány létrehozásának. A szükséges lépések nagyjából megegyeznek a már létrehozott szerveroldali tanúsítvánnyal.

Először létre kell hoznunk egy tanúsítvány-aláírási kérelmet:

openssl req -new -newkey rsa: 4096 -node -keyout clientBob.key –out clientBob.csr

Olyan információkat kell megadnunk, amelyeket beépítenek a tanúsítványba. Ehhez a gyakorlathoz csak a köznevet (CN) írjuk be - Bob. Fontos, mivel ezt a bejegyzést az engedélyezés során használjuk, és csak Bobot ismeri fel a minta alkalmazásunk.

Ezután alá kell írnunk a kérelmet a CA-val:

openssl x509 -req -CA rootCA.crt -CAkey rootCA.key -in clientBob.csr -out clientBob.crt -days 365 -CAcreateserial

Az utolsó lépés, amelyet meg kell tennünk, az az aláírt tanúsítvány és a magánkulcs becsomagolása a PKCS fájlba:

openssl pkcs12 -export -out clientBob.p12 -name "clientBob" -inkey clientBob.key -in clientBob.crt

Végül, készen állunk az ügyféltanúsítvány telepítésére a böngészőbe.

Ismét a Firefoxot fogjuk használni:

  1. típus körülbelül: preferenciák a címsorban
  2. Nyisd ki Haladó -> Tanúsítványok megtekintése -> Az Ön tanúsítványai
  3. Kattintson Importálás
  4. Keresse meg a Baeldung oktatóanyagok mappa és annak almappája spring-security-x509 / bolt
  5. Válaszd ki a clientBob.p12 fájlt, majd kattintson a gombra rendben
  6. Írja be a tanúsítvány jelszavát, majd kattintson a gombra rendben

Most, amikor frissítjük a weboldalunkat, a rendszer arra kéri, hogy válassza ki a használni kívánt ügyféltanúsítványt:

Ha olyan üdvözlő üzenetet látunk, mint - Hello Bob!, ez azt jelenti, hogy minden a várt módon működik!

6. Kölcsönös hitelesítés XML-mel

X.509 kliens hitelesítés hozzáadása egy http biztonsági konfiguráció XML is lehetséges:

 ...         ... 

Az alapul szolgáló Tomcat konfigurálásához fel kell tennünk a sajátunkat kulcstár és a mi vagyonkezelő bele konf mappát, és szerkessze a server.xml:

Tipp: Val vel clientAuth állítva "akar", SSL még mindig engedélyezve van, még akkor is, ha az ügyfél nem ad meg érvényes tanúsítványt. De ebben az esetben egy második hitelesítési mechanizmust kell használnunk, például egy bejelentkezési űrlapot a biztonságos erőforrások eléréséhez.

7. Következtetés

Összefoglalva: megtanultuk hogyan hozhat létre saját aláírással ellátott CA tanúsítványt, és hogyan használhatja más tanúsítványok aláírásához.

Ezenkívül létrehoztunk mind szerveroldali, mind kliensoldali tanúsítványokat. Ezután bemutattuk, hogyan importálhatjuk őket kulcstárba és ennek megfelelően egy megbízható áruházba.

Továbbá most már képesnek kell lennie arra csomagoljon egy tanúsítványt a magánkulcsával együtt a PKCS12 formátumba.

Megbeszéltük azt is, hogy mikor van értelme használni a Spring Security X.509 ügyfél-hitelesítést, ezért Önön múlik, hogy eldönti-e a webalkalmazásba, vagy sem.

És összefoglalva, keresse meg a cikk forráskódját a Githubon.


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