streamalism.org

Práve som oznámil nové Naučte sa jar kurz zameraný na základy jari 5 a Spring Boot 2:

1. Prehľad

V tomto tutoriáli porozumieme rozhraniu GSS API (Generic Security Service API) a tomu, ako ho môžeme implementovať v prostredí Java. Uvidíme, ako zabezpečíme sieťovú komunikáciu pomocou GSS API v Jave.

V tomto procese vytvoríme jednoduché komponenty klienta a servera a zabezpečíme ich pomocou GSS API.

2. Čo je GSS API?

Čo je to teda API Generic Security Service API? GSS API poskytuje všeobecný rámec pre aplikácie na použitie rôznych bezpečnostných mechanizmov, ako je Kerberos, NTLM a SPNEGO zapojiteľným spôsobom. Následne pomáha aplikáciám priamo sa oddeliť od bezpečnostných mechanizmov.

Na objasnenie, bezpečnosť tu pokrýva autentifikácia, integrita údajov a dôvernosť.

2.1. Prečo potrebujeme GSS API?

Bezpečnostné mechanizmy ako Kerberos, NTLM a Digest-MD5 sa líšia svojimi schopnosťami a implementáciami. Aplikácia podporujúca jeden z týchto mechanizmov zvyčajne považuje za dosť skľučujúce prejsť na iný.

Toto je kde všeobecný rámec ako GSS API poskytuje aplikáciám abstrakciu. Preto môžu aplikácie využívajúce GSS API vyjednať vhodný bezpečnostný mechanizmus a použiť ho na komunikáciu. To všetko bez toho, aby ste museli implementovať akékoľvek podrobnosti špecifické pre daný mechanizmus.

2.2. Ako to robí? GSS API funguje?

GSS API je mechanizmus založený na tokenoch. Funguje to tak výmena bezpečnostných tokenov medzi rovesníkmi. Táto výmena sa zvyčajne deje v sieti, ale GSS API je voči týmto detailom agnostický.

Tieto tokeny sú generované a spracovávané špecifickými implementáciami GSS API. The syntax a sémantika týchto tokenov sú špecifické pre bezpečnostný mechanizmus dohodnuté medzi rovesníkmi:

Ústredná téma GSS API sa točí okolo bezpečnostného kontextu. Tento kontext môžeme vytvoriť medzi rovesníkmi prostredníctvom výmeny tokenov. My môže byť potrebné viacnásobné výmeny žetónov medzi rovesníkmi vytvoriť kontext.

Po úspešnom zavedení na oboch koncoch môžeme na zabezpečenie bezpečnej výmeny údajov použiť kontext zabezpečenia. To môže zahŕňať kontroly integrity údajov a šifrovanie údajov, v závislosti od základného bezpečnostného mechanizmu.

3. Podpora GSS API v Jave

Java podporuje GSS API ako súčasť balíka „org.ietf.jgss“. Názov balíka sa môže zdať zvláštny. To preto, že Väzby Java pre GSS API sú definované v špecifikácii IETF. Samotná špecifikácia je nezávislá od bezpečnostného mechanizmu.

Jedným z populárnych bezpečnostných mechanizmov pre Java GSS je Kerberos v5.

3.1. Java GSS API

Pokúsme sa pochopiť niektoré základné API, ktoré vytvárajú Java GSS:

• GSSContext zapuzdruje kontext zabezpečenia GSS API a poskytuje služby dostupné v tomto kontexte
• GSSCredential zapuzdruje poverenia GSS API pre entitu, ktorá je nevyhnutná na vytvorenie kontextu bezpečnosti
• GSSName zapuzdruje hlavnú entitu GSS API, ktorá poskytuje abstrakciu pre rôzne menné priestory používané základnými mechanizmami

Okrem vyššie uvedených rozhraní je potrebné pamätať na niekoľko ďalších dôležitých tried:

• GSSManager slúži ako továrenská trieda pre ďalšie dôležité triedy GSS API, ako je GSSName, GSSCredentiala GSSContext
• Oid predstavuje univerzálne identifikátory objektov (OID), čo sú hierarchické identifikátory používané v GSS API na identifikáciu mechanizmov a formátov mien
• MessageProp zabalí vlastnosti, ktoré označujú GSSContext, napríklad Quality of Protection (QoP) a dôvernosť pri výmene údajov
• Viazanie kanálov zapuzdruje voliteľné informácie o viazaní kanálov používané na zvýšenie kvality, s akou sa poskytuje autentifikácia peer entity

3.2. Poskytovateľ zabezpečenia Java GSS

Aj keď Java GSS definuje základný rámec pre implementáciu GSS API v Jave, neposkytuje implementáciu. Java prijíma Poskytovateľ- zásuvné implementácie bezpečnostných služieb na báze vrátane Java GSS.

Môže byť jeden alebo viac takých poskytovatelia zabezpečenia zaregistrovaní v architektúre Java Cryptography Architecture (JCA). Každý poskytovateľ zabezpečenia môže implementovať jednu alebo viac bezpečnostných služieb, ako je Java GSSAPI a bezpečnostné mechanizmy pod ním.

Existuje štandardný poskytovateľ GSS, ktorý sa dodáva s JDK. Existujú však aj ďalší poskytovatelia služieb GSS s rôznymi bezpečnostnými mechanizmami, ktoré môžeme použiť. Jedným z takýchto poskytovateľov je IBM Java GSS. Musíme zaregistrovať takéhoto poskytovateľa zabezpečenia u JCA, aby sme ich mohli používať.

Navyše, ak je to potrebné, my môžeme implementovať nášho vlastného poskytovateľa zabezpečenia s prípadne vlastnými bezpečnostnými mechanizmami. V praxi je to však ťažko potrebné.

4. GSS API prostredníctvom príkladu

Teraz uvidíme Java GSS v akcii prostredníctvom príkladu. Vytvoríme jednoduchú aplikáciu pre klienta a server. Klient sa v GSS častejšie označuje ako iniciátor a server ako akceptor. Na autentifikáciu použijeme Java GSS a Kerberos v5 zospodu.

4.1. GSS kontext pre klienta a server

Na začiatok budeme musieť založiť a GSSContextna serveri aj na strane klienta žiadosti.

Najprv sa pozrime, ako to môžeme urobiť na strane klienta:

Manažér GSSManager = GSSManager.getInstance (); Reťazec serverPrinciple = "HTTP / [chránený e-mailom]"; GSSName serverName = manager.createName (serverPrinciple, null); Oid krb5Oid = nový Oid ("1.2.840.113554.1.2.2"); GSSContext clientContext = manager.createContext (serverName, krb5Oid, (GSSCredential) null, GSSContext.DEFAULT_LIFETIME); clientContext.requestMutualAuth (true); clientContext.requestConf (true); clientContext.requestInteg (true);

Deje sa tu pomerne veľa vecí, poďme ich rozobrať:

• Začneme vytvorením inštancie súboru GSSManager
• Potom použijeme túto inštanciu na vytvorenie GSSContext, prechádzajúc spolu:
  • a GSSName predstavujúci principál servera, pozn konkrétny hlavný názov protokolu Kerberos tu
  • the Oid mechanizmu, ktorý tu treba použiť, je tu Kerberos v5
  • poverovacie listiny iniciátora, nulový tu znamená, že sa použijú predvolené poverenia
  • životnosť v stanovenom kontexte
• Nakoniec pripravíme súvislosti pre vzájomné overovanie, dôvernosť a integritu údajov

Podobne musíme definovať kontext na strane servera:

Manažér GSSManager = GSSManager.getInstance (); GSSContext serverContext = manager.createContext ((GSSCredential) null);

Ako vidíme, je to oveľa jednoduchšie ako v kontexte klienta. Jediný rozdiel je v tom, že potrebujeme poverovacie listiny prijímateľa, ktoré sme použili ako nulový. Ako predtým, nulový znamená, že sa použijú predvolené poverenia.

4.2. GSS API autentifikácia

Aj keď sme vytvorili server a stranu klienta GSSContext, upozorňujeme, že v tejto fáze nie sú usadení.

Na vytvorenie týchto kontextov si musíme vymeniť tokeny špecifické pre zadaný bezpečnostný mechanizmus, ktorým je Kerberos v5:

// Na strane klienta clientToken = clientContext.initSecContext (nový bajt [0], 0, 0); sendToServer (clientToken); // Toto sa má posielať po sieti // Na strane servera serverToken = serverContext.acceptSecContext (clientToken, 0, clientToken.length); sendToClient (serverToken); // Toto sa má posielať po sieti // Späť na strane klienta clientContext.initSecContext (serverToken, 0, serverToken.length);

To nakoniec robí kontext stanovený na oboch koncoch:

assertTrue (serverContext.isEstablished ()); assertTrue (clientContext.isEstablished ());

4.3. Bezpečná komunikácia GSS API

Teraz, keď máme kontext založený na oboch koncoch, môžeme začať odosielať údaje s integritou a dôvernosťou:

// Na bajte na strane klienta [] messageBytes = "Baeldung" .getBytes (); MessageProp clientProp = nový MessageProp (0, true); byte [] clientToken = clientContext.wrap (messageBytes, 0, messageBytes.length, clientProp); sendToClient (serverToken); // Toto sa má posielať po sieti // Na strane servera MessageProp serverProp = nový MessageProp (0, false); byte [] bytes = serverContext.unwrap (clientToken, 0, clientToken.length, serverProp); Reťazcový reťazec = nový Reťazec (bajty); assertEquals ("Baeldung", reťazec);

Deje sa tu niekoľko vecí, poďme si to rozobrať:

• MessageProp používa klient na nastavenie obal a vygenerujte token
• Metóda obal tiež pridáva kryptografický MIC údajov, MIC je dodávaný ako súčasť tokenu
• Tento token sa odošle na server (pravdepodobne prostredníctvom sieťového hovoru)
• Server to využíva MessageProp znova nastaviť rozbaliť metóda a získať dáta späť
• Tiež metóda rozbaliť overuje MIC pre prijaté dáta a zaisťuje integritu dát

Preto sú klient a server schopní vymieňať si dáta s integritou a dôvernosťou.

4.4. Nastavenie protokolu Kerberos pre príklad

Teraz je to mechanizmus GSS Od protokolu Kerberos sa zvyčajne očakáva načítanie poverení z existujúceho Predmet. Trieda Predmet tu je abstrakcia JAAS predstavujúca entitu ako osoba alebo služba. Zvyčajne sa vyplní počas autentifikácie na základe JAAS.

Pre náš príklad však nebudeme priamo používať autentifikáciu založenú na JAAS. Umožníme protokolu Kerberos získať poverenia priamo, v našom prípade pomocou súboru tabuľky kľúčov. Existuje systémový parameter JVM, ktorý umožňuje dosiahnutie tohto cieľa:

-Djavax.security.auth.useSubjectCredsOnly = false

Predvolená implementácia protokolu Kerberos poskytovaná spoločnosťou Sun Microsystem sa však pri poskytovaní autentifikácie spolieha na JAAS.

Môže to znieť v rozpore s tým, o čom sme práve hovorili. Upozorňujeme, že v našej aplikácii môžeme výslovne použiť JAAS, ktorý vyplní súbor Predmet. Alebo nechajte na podkladový mechanizmus, aby sa autentifikoval priamo, kde aj tak používa JAAS. Preto musíme poskytnúť konfiguračný súbor JAAS základnému mechanizmu:

com.sun.security.jgss.initiate {com.sun.security.auth.module.Krb5LoginModule povinné useKeyTab = true keyTab = example.keytab principal = "klient / localhost" storeKey = true; }; com.sun.security.jgss.accept {com.sun.security.auth.module.Krb5LoginModule povinné useKeyTab = true keyTab = example.keytab storeKey = true principál = "HTTP / localhost"; };

Táto konfigurácia je priama, kde sme definovali Kerberos ako požadovaný prihlasovací modul pre iniciátora aj akceptora. Ďalej sme nakonfigurovali použitie príslušných principálov zo súboru tabuľky kariet. Túto konfiguráciu JAAS môžeme odovzdať JVM ako systémový parameter:

-Djava.security.auth.login.config = login.conf

Tu sa predpokladá, že máme prístup k Kerberos KDC. V KDC sme nastavili požadované principály a získali súbor keytab, ktorý môžeme použiť „Example.keytab“.

Ďalej potrebujeme konfiguračný súbor Kerberos smerujúci k správnemu KDC:

[libdefaults] default_realm = EXAMPLE.COM udp_preference_limit = 1 [realms] EXAMPLE.COM = {kdc = localhost: 52135}

Táto jednoduchá konfigurácia definuje KDC bežiace na porte 52135 s predvolenou sférou ako EXAMPLE.COM. Môžeme to odovzdať JVM ako systémový parameter:

-Djava.security.krb5.conf = krb5.conf

4.5. Spustenie príkladu

Aby sme uviedli príklad, musíme využiť artefakty Kerberos popísané v poslednej časti.

Musíme tiež odovzdať požadované parametre JVM:

java -Djava.security.krb5.conf = krb5.conf \ -Djavax.security.auth.useSubjectCredsOnly = false \ -Djava.security.auth.login.config = login.conf \ com.baeldung.jgss.JgssUnitTest

To je dostatočné na to, aby Kerberos vykonal autentifikáciu pomocou prihlasovacích údajov z keytab a GSS na vytvorenie kontextov.

5. GSS API v reálnom svete

Aj keď GSS API sľubuje vyriešenie mnohých bezpečnostných problémov pomocou zásuvných mechanizmov, existuje len málo prípadov použitia, ktoré sa prijali v širšom rozsahu:

• Je to široko používaný v SASL ako bezpečnostný mechanizmus, najmä ak je základným mechanizmom voľby protokol Kerberos. Kerberos je široko používaný autentifikačný mechanizmus, najmä v rámci podnikovej siete. Je skutočne užitočné využiť Kerberized infraštruktúru na autentifikáciu novej aplikácie. Preto GSS API túto medzeru pekne preklenuje.
• Je to tiež použité v konjugácii s SPNEGO rokovať o bezpečnostnom mechanizme, ak nie je vopred známy. V tomto ohľade je SPNEGO v istom zmysle pseudo mechanizmus GSS API. Toto je široko podporované vo všetkých moderných prehľadávačoch, vďaka čomu sú schopné využívať autentifikáciu na báze Kerberos.

6. GSS API v porovnaní

GSS API je celkom efektívne v poskytovaní bezpečnostných služieb aplikáciám pripojiteľným spôsobom. Nie je to však jediná voľba, ako to dosiahnuť v prostredí Java.

Poďme pochopiť, čo ešte môže Java ponúkať a aké sú porovnania s GSS API:

• Rozšírenie Java Secure Socket Extension (JSSE): JSSE je sada balíkov v Jave, ktorá implementuje SSL (Secure Sockets Layer) pre Javu. Poskytuje šifrovanie údajov, autentifikáciu klienta a servera a integritu správ. Na rozdiel od GSS API sa JSSE spolieha na fungovanie infraštruktúry verejných kľúčov (PKI). GSS API teda vychádza z toho, že je flexibilnejšie a ľahšie ako JSSE.
• Jednoduchá autentifikácia a vrstva Java (SASL): SASL je rámec pre autentizáciu a zabezpečenie údajov pre internetové protokoly ktorý ich oddeľuje od konkrétnych mechanizmov autentifikácie. Rozsahom je to podobné ako GSS API. Java GSS má však obmedzenú podporu základných bezpečnostných mechanizmov prostredníctvom dostupných poskytovateľov zabezpečenia.

Celkovo je GSS API dosť silné pri poskytovaní bezpečnostných služieb mechanizmom agnostickým spôsobom. Podpora ďalších bezpečnostných mechanizmov v Jave to však bude prijímať ďalej.

7. Záver

Ak to zhrnieme, v tomto tutoriále sme pochopili základy GSS API ako bezpečnostný rámec. Prešli sme si Java API pre GSS a pochopili sme, ako ich môžeme využiť. V rámci tohto procesu sme vytvorili jednoduché komponenty klienta a servera, ktoré vykonávali vzájomné overovanie a zabezpečili bezpečnú výmenu údajov.

Ďalej sme tiež videli, aké sú praktické aplikácie GSS API a aké sú alternatívy dostupné v Jave.

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

Práve som oznámil nové Naučte sa jar kurz zameraný na základy jari 5 a Spring Boot 2: