streamalism.org

1. Pregled

U ovom ćemo se članku usredotočiti na glavne slučajeve upotrebe za autentifikaciju certifikata X.509 - provjera identiteta vršnjaka u komunikaciji kada se koristi HTTPS (HTTP preko SSL) protokola.

Jednostavno rečeno - dok je uspostavljena sigurna veza, klijent provjerava poslužitelj prema svojoj potvrdi (koju izdaje pouzdano tijelo za izdavanje certifikata).

No, osim toga, X.509 u Spring Security-u može se koristiti provjeriti identitet klijenta od strane poslužitelja tijekom povezivanja. Ovo se zove "Međusobna provjera autentičnosti", a pogledat ćemo kako se to radi i ovdje.

Napokon ćemo se dotaknuti kada ima smisla koristiti ovu vrstu provjere autentičnosti.

Da bismo demonstrirali provjeru poslužitelja, stvorit ćemo jednostavnu web aplikaciju i instalirati prilagođeno tijelo za izdavanje certifikata u preglednik.

Štoviše, za međusobna provjera autentičnosti, stvorit ćemo certifikat klijenta i izmijeniti naš poslužitelj tako da dopušta samo provjerene klijente.

Preporučuje se slijediti uputstva korak po korak i sami stvoriti certifikate, kao i skladište ključeva i povjerenje, prema uputama predstavljenim u sljedećim odjeljcima. Međutim, sve datoteke spremne za upotrebu mogu se naći u našem GitHub spremištu.

2. Samopotpisani korijenski CA

Da bismo mogli potpisati naše certifikate na strani poslužitelja i klijenta, prvo moramo stvoriti vlastiti samopotpisani korijenski CA certifikat. Ovuda ponašat ćemo se kao vlastiti izdavatelj certifikata.

U tu svrhu koristit ćemo knjižnicu openssl, pa je moramo instalirati prije sljedećeg koraka.

Stvorimo sada CA certifikat:

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

Kada izvršimo gornju naredbu, trebamo unijeti lozinku za naš privatni ključ. U svrhu ovog vodiča koristimo promijeni to kao lozinka.

Dodatno, trebamo unijeti podatke koji tvore takozvano ugledno ime. Ovdje pružamo samo CN (zajednički naziv) - Baeldung.com - a ostale dijelove ostavljamo prazne.

3. Trgovina ključeva

Fakultativni zahtjev: Za upotrebu kriptografski jakih ključeva zajedno sa značajkama šifriranja i dešifriranja trebat će nam "Datoteke s politikom nadležnosti za neograničenu snagu Java Cryptography Extension (JCE)”Instaliran u našem JVM-u.

Oni se mogu preuzeti na primjer iz Oraclea (slijedite upute za instalaciju uključene u preuzimanje). Neke distribucije Linuxa također pružaju instalacijski paket putem svojih upravitelja paketa.

Pohrana ključeva je spremište koje će naša aplikacija Spring Boot koristiti za čuvanje privatnog ključa i certifikata našeg poslužitelja. Drugim riječima, naša će aplikacija koristiti pohranu ključeva za posluživanje certifikata klijentima tijekom SSL rukovanja.

U ovom uputstvu koristimo Java Key-Store (JKS) format i alat za naredbene retke keytool.

3.1. Potvrda na strani poslužitelja

Da bismo implementirali autentifikaciju X.509 na strani poslužitelja u našoj aplikaciji Spring Boot, mi prvo treba stvoriti certifikat na strani poslužitelja.

Počnimo s izradom takozvanog zahtjeva za potpisivanje certifikata (CSR):

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

Slično tome, što se tiče CA certifikata, moramo navesti lozinku za privatni ključ. Uz to, iskoristimo lokalnihost kao zajednički naziv (CN).

Prije nego nastavimo, moramo stvoriti konfiguracijsku datoteku - localhost.ext. Pohranit će neke dodatne parametre potrebne tijekom potpisivanja certifikata.

AuthorityKeyIdentifier = keyid, izdavatelj basicConstraints = CA: FALSE subjectAltName = @alt_names [alt_names] DNS.1 = localhost

Datoteka spremna za upotrebu također je dostupna ovdje.

Sad je vrijeme da potpisati zahtjev s našim rootCA.crt certifikat i njegov privatni ključ:

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

Napominjemo da moramo navesti istu lozinku koju smo koristili prilikom izrade CA certifikata.

U ovoj fazi, napokon smo spremni za upotrebu localhost.crt potvrda koju potpisuje naše vlastito tijelo za izdavanje certifikata.

Za ispis detalja certifikata u čitljivom obliku možemo upotrijebiti sljedeću naredbu:

openssl x509 -in localhost.crt -tekst

3.2. Uvoz u trgovinu ključeva

U ovom ćemo odjeljku vidjeti kako uvezite potpisani certifikat i odgovarajući privatni ključ u pohrana ključeva.jks datoteka.

Koristit ćemo arhivu PKCS 12 za pakiranje privatnog ključa našeg poslužitelja zajedno s potpisanim certifikatom. Zatim ćemo ga uvesti u novostvoreno pohrana ključeva.jks.

Sljedeću naredbu možemo koristiti za stvaranje a .p12 datoteka:

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

Dakle, sada imamo localhost.key i localhost.crt upakovane u singl localhost.p12 datoteka.

Upotrijebimo sada keytool za stvoriti pohrana ključeva.jks spremište i uvezite localhost.p12 datoteka s jednom naredbom:

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

U ovoj fazi imamo sve na raspolaganju za dio provjere autentičnosti poslužitelja. Nastavimo s konfiguracijom aplikacije Spring Boot.

4. Primjer prijave

Naš SSL osigurani poslužiteljski projekt sastoji se od a @SpringBootApplication označena klasa aplikacije (koja je vrsta @Konfiguracija), an primjena.svojstva konfiguracijsku datoteku i vrlo jednostavan front-end u MVC stilu.

Sve što aplikacija mora učiniti je predstaviti HTML stranicu s "Pozdrav {Korisnik}!" poruka. Na ovaj način možemo pregledati potvrdu poslužitelja u pregledniku kako bismo bili sigurni da je veza provjerena i osigurana.

4.1. Ovisnosti Mavena

Prvo kreiramo novi Maven projekt s uključena tri paketa Spring Boot Starter:

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

Za referencu: snopove možemo pronaći na Maven Central (zaštita, mreža, timijanov list).

4.2. Primjena za proljetno pokretanje

Kao sljedeći korak kreiramo glavnu klasu aplikacije i korisničkog kontrolora:

@SpringBootApplication javna klasa X509AuthenticationServer {javna statička void glavna (String [] args) {SpringApplication.run (X509AuthenticationServer.class, args); }} @Controller javna klasa UserController {@RequestMapping (value = "/ user") javni niz korisnika (model modela, glavni nalogodavac) {UserDetails currentUser = (UserDetails) ((Authentication) principal) .getPrincipal (); model.addAttribute ("korisničko ime", currentUser.getUsername ()); vratiti "korisnik"; }}

Sada aplikaciji kažemo gdje pronaći naš pohrana ključeva.jks i kako mu pristupiti. SSL smo postavili na "omogućen" status i promijenili standardni ulaz za slušanje u označavaju sigurnu vezu.

Uz to konfiguriramo neke pojedinosti o korisniku za pristup našem poslužitelju putem osnovne provjere autentičnosti:

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 = Admin spring.security.user.password = admin

Ovo će biti HTML predložak koji se nalazi na resursi / predlošci mapa:

   X.509 Demo za provjeru autentičnosti 
Zdravo !

4.3. Instalacija korijenskog CA-a

Prije nego što završimo ovaj odjeljak i pogledamo stranicu, trebamo instalirati svoje generirano tijelo za izdavanje korijenskih certifikata kao pouzdan certifikat u preglednik.

Uzorna instalacija našeg tijela za izdavanje certifikata za Mozilla Firefox bi izgledalo ovako:

1. Tip o: preferencijama u adresnoj traci
2. Otvorena Napredno -> Potvrde -> Pregled potvrda -> Ovlaštenja
3. Kliknite na Uvoz
4. Pronađite Vodiči za Baeldung mapa i njezina podmapa opruga-sigurnost-x509 / pohrana ključeva
5. Odaberite rootCA.crt datoteku i kliknite u redu
6. Odaberite “Vjerujte ovom CA da identificira web stranice ” i kliknite u redu

Bilješka: Ako ne želite dodati naše tijelo za ovjere na popis pouzdane vlasti, kasnije ćete imati mogućnost izraditi iznimka i pokazati web stranicu čvrstom, čak i kad se spominje kao nesigurna. Ali tada ćete u adresnoj traci vidjeti simbol "žutog uskličnika", koji označava nesigurnu vezu!

Poslije ćemo prijeći na spring-security-x509-basic-auth modul i pokrenite:

mvn spring-boot: trčanje

Napokon smo pogodili // localhost: 8443 / korisnik, unesite naše vjerodajnice iz primjena.svojstva i trebao bi vidjeti a "Zdravo administratore!" poruka. Sada možemo provjeriti status veze klikom na simbol "zelena brava" u adresnoj traci, a to bi trebala biti sigurna veza.

5. Uzajamna provjera autentičnosti

U prethodnom smo odjeljku predstavili kako implementirati najčešće shemu provjere autentičnosti SSL - provjeru autentičnosti na strani poslužitelja. To znači da se samo poslužitelj autentificirao za klijente.

U ovom odjeljku, opisat ćemo kako dodati drugi dio provjere autentičnosti - provjeru autentičnosti na strani klijenta. Na taj način samo klijenti s važećim certifikatima potpisanim od strane tijela kojem naš poslužitelj vjeruje mogu pristupiti našem zaštićenom web mjestu.

No prije nego što nastavimo, pogledajmo koje su prednosti i nedostaci upotrebe međusobne SSL provjere autentičnosti.

Pros:

• Privatni ključ X.509 klijentski certifikat jači je od bilo koje korisnički definirane lozinke. Ali to se mora čuvati u tajnosti!
• Uz potvrdu, identitet klijenta dobro je poznat i jednostavan za provjeru.
• Nema više zaboravljenih lozinki!

Protiv:

• Moramo stvoriti certifikat za svakog novog klijenta.
• Potvrda klijenta mora biti instalirana u klijentskoj aplikaciji. Zapravo: Provjera autentičnosti klijenta X.509 ovisi o uređaju, što onemogućava upotrebu ove vrste provjere autentičnosti na javnim mjestima, na primjer u internetskoj kavani.
• Mora postojati mehanizam za opoziv ugroženih certifikata klijenta.
• Moramo čuvati certifikate klijenata. To lako može postati skupo.

5.1. Truststore

Trustsore je na neki način suprotno od pohrane ključeva. Ima certifikate vanjskih entiteta kojima vjerujemo.

U našem je slučaju dovoljno zadržati korijenski CA certifikat u trgovini povjerenja.

Pogledajmo kako stvoriti truststore.jks datoteku i uvezite datoteku rootCA.crt pomoću alata za ključeve:

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

Napomena, moramo navesti lozinku za novostvoreno trusstore.jks. Evo, opet smo koristili promijeni to pristupna fraza.

To je to, uvezli smo vlastiti CA certifikat i truststore je spreman za upotrebu.

5.2. Proljetna sigurnosna konfiguracija

Da bismo nastavili, mijenjamo svoj X509AuthenticationServer produžiti od WebSecurityConfigurerAdapter i nadjačati jedan od ponuđenih načina konfiguriranja. Ovdje konfiguriramo x.509 mehanizam za raščlanjivanje Uobičajeni naziv (CN) polje certifikata za izdvajanje korisničkih imena.

S ovim izdvojenim korisničkim imenima, Spring Security traži osigurano UserDetailsService za podudarne korisnike. Dakle, mi također implementiramo ovo sučelje usluge koje sadrži jednog demo korisnika.

Savjet: U proizvodnim okruženjima, ovo UserDetailsService može učitati svoje korisnike, na primjer iz JDBC izvora podataka.

Morate primijetiti da svoj razred označavamo @EnableWebSecurity i @EnableGlobalMethodSecurity s omogućenom pre / post-autorizacijom.

Pomoću potonjeg možemo komentirati svoje resurse @PreAuthorize i @PostAuthorize za preciznu kontrolu pristupa:

@SpringBootApplication @EnableWebSecurity @EnableGlobalMethodSecurity (prePostEnabled = istina) public class X509AuthenticationServer proteže WebSecurityConfigurerAdapter {... @Override zaštićena void konfigurirati (HttpSecurity http) baca Iznimka $) ") .userDetailsService (userDetailsService ()); @Bean javni UserDetailsService userDetailsService () {return new UserDetailsService () {@Override public UserDetails loadUserByUsername (String username) {if (username.equals ("Bob")) {return new User (username, "", AuthorityUtils .commaSeparatedStringToAuthorityList ("ROLE_USER"))}} new UsernameNotFoundException ("Korisnik nije pronađen!");}};}}

Kao što je prethodno rečeno, sada smo u mogućnosti koristiti Kontrola pristupa zasnovana na izrazu u našem kontroloru. Preciznije, naše bilješke o autorizaciji poštuju se zbog @EnableGlobalMethodSecurity bilješka u našem @Konfiguracija:

@Controller javna klasa UserController {@PreAuthorize ("hasAuthority ('ROLE_USER')") @RequestMapping (value = "/ user") javni niz korisnika (model modela, glavni nalogodavac) {...}}

Pregled svih mogućih mogućnosti autorizacije nalazi se u službena dokumentacija.

Kao posljednji korak izmjene, aplikaciji moramo reći gdje je naš trgovina povjerenjem nalazi se i to Provjera autentičnosti SSL klijenta potrebno je (server.ssl.client-auth = potreba).

Dakle, u svoje smo stavili sljedeće primjena.svojstva:

server.ssl.trust-store = store / truststore.jks server.ssl.trust-store-password = $ {PASSWORD} server.ssl.client-auth = need

Sada, ako pokrenemo aplikaciju i usmerimo naš preglednik na // localhost: 8443 / korisnik, postajemo informirani da se vršnjak ne može provjeriti te odbija otvoriti našu web stranicu.

5.3. Potvrda na strani klijenta

Sada je vrijeme za izradu certifikata na strani klijenta. Koraci koje trebamo poduzeti približno su isti kao i za certifikat na strani poslužitelja koji smo već kreirali.

Prvo, moramo stvoriti zahtjev za potpisivanje certifikata:

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

Morat ćemo navesti podatke koji će biti ugrađeni u certifikat. Za ovu vježbu, unesite samo zajedničko ime (CN) - Bob. Važno je jer ovaj unos koristimo tijekom autorizacije, a naša aplikacija za uzorak prepoznaje samo Boba.

Dalje, moramo potpisati zahtjev s našim CA:

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

Posljednji korak koji moramo poduzeti jest spakiranje potpisane potvrde i privatnog ključa u PKCS datoteku:

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

Konačno, spremni smo instalirati certifikat klijenta u preglednik.

Opet ćemo koristiti Firefox:

1. Tip o: preferencijama u adresnoj traci
2. Otvorena Napredno -> Pregled certifikata -> Vaši certifikati
3. Kliknite na Uvoz
4. Pronađite Vodiči za Baeldung mapa i njezina podmapa opruga-sigurnost-x509 / trgovina
5. Odaberite clientBob.p12 datoteku i kliknite u redu
6. Unesite lozinku za svoj certifikat i kliknite u redu

Sada, kada osvježimo našu web stranicu, od nas će se zatražiti da odaberemo certifikat klijenta kojeg želimo koristiti:

Ako vidimo poruku dobrodošlice poput "Zdravo Bobe!", to znači da sve funkcionira prema očekivanjima!

6. Uzajamna provjera autentičnosti s XML-om

Dodavanje provjere identiteta klijenta X.509 u http sigurnosna konfiguracija u XML je također moguće:

 ...         ... 

Da bismo konfigurirali temeljni Tomcat, moramo staviti svoj pohrana ključeva i naše trgovina povjerenjem u svoje konf mapu i uredite poslužitelj.xml:

Savjet: S clientAuth postavljen "Želim", SSL je i dalje omogućen, čak i ako klijent ne dostavi valjani certifikat. Ali u ovom slučaju, moramo koristiti drugi mehanizam provjere autentičnosti, na primjer, obrazac za prijavu, da bismo pristupili osiguranim resursima.

7. Zaključak

Ukratko, naučili smo kako stvoriti samopotpisani CA certifikat i kako ga koristiti za potpisivanje drugih certifikata.

Uz to, stvorili smo i certifikate na strani poslužitelja i klijenta. Zatim smo predstavili kako ih uvesti u skladište ključeva i skladište pouzdanosti.

Nadalje, sada biste to trebali moći spakirajte certifikat zajedno sa svojim privatnim ključem u format PKCS12.

Također smo razgovarali o tome kada ima smisla koristiti provjeru identiteta klijenta Spring Security X.509, pa je na vama da odlučite hoćete li ga primijeniti u svoju web aplikaciju ili ne.

Da biste završili, pronađite izvorni kod ovog članka na Githubu.