streamalism.org

Most jelentettem be az újat Tanulj tavaszt tanfolyam, amelynek középpontjában az 5. tavasz és a tavaszi bakancs 2 alapjai állnak:

1. Áttekintés

Ebben az oktatóanyagban megértjük a Generic Security Service API-t (GSS API) és azt, hogy miként tudjuk megvalósítani azt a Java-ban. Meglátjuk, hogyan tudjuk biztosítani a hálózati kommunikációt a Java-ban található GSS API segítségével.

Ennek során egyszerű kliens- és kiszolgáló-összetevőket hozunk létre, azokat a GSS API-val rögzítve.

2. Mi az GSS API?

Mi tehát valójában a Generic Security Service API? A GSS API általános keretet biztosít az alkalmazások számára különböző biztonsági mechanizmusok, például a Kerberos használatához, NTLM és SPNEGO plug-in módon. Következésképpen segíti az alkalmazásokat abban, hogy közvetlenül leválasszák magukat a biztonsági mechanizmusokról.

Hogy tisztázzuk, itt a biztonság átfog hitelesítés, adatintegritás és titoktartás.

2.1. Miért van szükségünk GSS API?

Az olyan biztonsági mechanizmusok, mint a Kerberos, az NTLM és a Digest-MD5, képességeikben és megvalósításukban meglehetősen különböznek egymástól. Egy ilyen mechanizmus egyikét támogató alkalmazás általában ijesztőnek találja a másikra való átállást.

Ez az, ahol egy olyan általános keretrendszer, mint a GSS API, absztrakcióval látja el az alkalmazásokat. Ezért a GSS API-t használó alkalmazások tárgyalhatnak egy megfelelő biztonsági mechanizmusról, és kommunikációra használhatják azt. Mindezt anélkül, hogy bármilyen mechanizmus-specifikus részletet meg kellene valósítanunk.

2.2. Hogyan működik GSS API munka?

A GSS API az token alapú mechanizmus. Úgy működik a biztonsági tokenek cseréje társak között. Ez a csere általában egy hálózaton keresztül történik, de a GSS API agnosztikus ezekre a részletekre.

Ezeket a tokeneket a GSS API speciális megvalósításai generálják és dolgozzák fel. A Ezen tokenek szintaxisa és szemantikája a biztonsági mechanizmusra jellemző a társaik között tárgyaltak:

A GSS API központi témája egy biztonsági környezet körül forog. Ezt a kontextust a társak között zsetonok cseréjével állapíthatjuk meg. Mi többszörös zsetoncserére lehet szükség társaik között a kontextus megállapításához.

Miután mindkét oldalon sikeresen létrejött, használhatjuk a biztonsági kontextust az adatok biztonságos cseréjéhez. Ez magában foglalhatja az adatok integritásának ellenőrzését és az adatok titkosítását, az alapul szolgáló biztonsági mechanizmustól függően.

3. GSS API támogatás Java-ban

A Java az „org.ietf.jgss” csomag részeként támogatja a GSS API-t. A csomag neve különösnek tűnhet. Ez azért van, mert a A GSS API Java-kötéseit egy IETF specifikáció határozza meg. Maga a specifikáció független a biztonsági mechanizmustól.

A Java GSS egyik népszerű biztonsági mechanizmusa a Kerberos v5.

3.1. Java GSS API

Próbáljuk megérteni a Java GSS-t felépítő alapvető API-kat:

• GSSContext összefoglalja a GSS API biztonsági kontextust, és a kontextusban elérhető szolgáltatásokat nyújt
• GSSCredential összefoglalja a GSS API hitelesítő adatait egy entitás számára, amely szükséges a biztonsági környezet létrehozásához
• GSSName összefoglalja a GSS API fő entitását, amely absztrakciót biztosít az alapul szolgáló mechanizmusok által használt különböző névtérhez

A fenti interfészeken kívül néhány fontos osztályt érdemes megjegyezni:

• GSSManager gyárosztályként szolgál más fontos GSS API osztályokhoz, mint például GSSName, GSSCredential, és GSSContext
• Oid az univerzális objektumazonosítókat (OID) jelenti, amelyek hierarchikus azonosítók, amelyeket a GSS API-n belül használnak a mechanizmusok és a névformátumok azonosítására
• MessageProp burkolja a tulajdonságokat, hogy jelezze a GSSContextet olyan dolgokon, mint a védelem minősége (QoP) és az adatcsere titkossága
• Csatornakötés összefoglalja az opcionális csatornakötési információkat, amelyek megerősítik a partneri entitások hitelesítésének minőségét

3.2. Java GSS biztonsági szolgáltató

Míg a Java GSS meghatározza a GSS API Java-ban történő megvalósításának alapvető keretrendszerét, nem biztosít megvalósítást. Java elfogadja Szolgáltató-biztonsági szolgáltatások dugaszolható megvalósításai beleértve a Java GSS-t.

Egy vagy több ilyen lehet a Java kriptográfiai architektúrában regisztrált biztonsági szolgáltatók (JCA). Minden biztonsági szolgáltató megvalósíthat egy vagy több biztonsági szolgáltatást, például Java GSSAPI-t és alatta lévő biztonsági mechanizmusokat.

Van egy alapértelmezett GSS-szolgáltató, amely a JDK-val szállít. Vannak azonban más gyártóspecifikus GSS-szolgáltatók, különböző biztonsági mechanizmusokkal, amelyeket felhasználhatunk. Az egyik ilyen szolgáltató az IBM Java GSS. Ilyen biztonsági szolgáltatót regisztrálnunk kell a JCA-nál, hogy használni tudjuk őket.

Sőt, ha szükséges, mi megvalósíthatja saját biztonsági szolgáltatónkat, esetleg egyedi biztonsági mechanizmusokkal. Erre azonban a gyakorlatban alig van szükség.

4. GSS API egy példán keresztül

Most a Java GSS-t láthatjuk működés közben egy példán keresztül. Létrehozunk egy egyszerű kliens és szerver alkalmazást. Az ügyfelet a GSS-ben gyakrabban nevezik kezdeményezőnek és szervert elfogadónak. A hitelesítéshez Java GSS-t és alatta található Kerberos v5-öt fogunk használni.

4.1. GSS kontextus az ügyfél és a kiszolgáló számára

Először is meg kell tennünk létrehozni a GSSContext, mind a szerver, mind az ügyfél oldalon az alkalmazás.

Először nézzük meg, hogyan tehetjük ezt meg az ügyfél oldalon:

GSSManager manager = GSSManager.getInstance (); String serverPrinciple = "HTTP / [e-mail védett]"; GSSName kiszolgálónév = manager.createName (szerverPrinciple, null); Oid krb5Oid = új Oid ("1.2.840.113554.1.2.2"); GSSContext clientContext = manager.createContext (szervernév, krb5Oid, (GSSCredential) null, GSSContext.DEFAULT_LIFETIME); clientContext.requestMutualAuth (true); clientContext.requestConf (true); clientContext.requestInteg (true);

Elég sok minden történik itt, bontsuk le őket:

• Először a GSSManager
• Ezután ezt a példányt használjuk a létrehozáshoz GSSContext, haladva:
  • a GSSName a kiszolgáló megbízóját képviselve, jegyzet a Kerberos-fõnév itt
  • a Oid a felhasználási mechanizmus, Kerberos v5 itt
  • a kezdeményező igazolása, nulla itt azt jelenti, hogy alapértelmezett hitelesítő adatokat fognak használni
  • az élet a kialakult kontextusban
• Végül felkészülünk a kölcsönös hitelesítés, a titoktartás és az adatok integritásának kontextusa

Hasonlóképpen meg kell határoznunk a szerveroldali kontextust:

GSSManager manager = GSSManager.getInstance (); GSSContext serverContext = manager.createContext (((GSSCredential) null);

Mint láthatjuk, ez sokkal egyszerűbb, mint az ügyféloldali kontextus. Az egyetlen különbség itt az, hogy szükségünk van az elfogadó hitelesítő adatokra, amelyeket már használtunk nulla. Mint azelőtt, nulla azt jelenti, hogy az alapértelmezett hitelesítő adatokat fogják használni.

4.2. GSS API hitelesítés

Habár létrehoztuk a szerver és kliens oldalt GSSContext, kérjük, vegye figyelembe, hogy ebben a szakaszban nincsenek létrehozva.

Ezen összefüggések megállapításához cserélnünk kell a megadott biztonsági mechanizmusra jellemző jelzőket, vagyis a Kerberos v5-öt:

// Az ügyféloldali clientToken = clientContext.initSecContext (új bájt [0], 0, 0); sendToServer (clientToken); // Ezt állítólag a hálózaton keresztül kell elküldeni // A kiszolgálóoldali serverToken = serverContext.acceptSecContext (clientToken, 0, clientToken.length); sendToClient (serverToken); // Ezt állítólag a hálózaton keresztül kell elküldeni // Vissza az ügyféloldali clientContext.initSecContext (serverToken, 0, serverToken.length);

Ez végül megalapozza a kontextust mindkét végén:

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

4.3. GSS API biztonságos kommunikáció

Most, hogy a kontextus mindkét végén létrejött, megkezdhetjük az adatok küldését integritással és bizalmasan:

// Az ügyféloldali bájton [] messageBytes = "Baeldung" .getBytes (); MessageProp clientProp = új MessageProp (0, igaz); byte [] clientToken = clientContext.wrap (messageBytes, 0, messageBytes.length, clientProp); sendToClient (serverToken); // Ezt állítólag a hálózaton keresztül kell elküldeni // A kiszolgálóoldali MessageProp serverProp = new MessageProp (0, false); bájt [] bájt = serverContext.unwrap (clientToken, 0, clientToken.length, serverProp); String string = új karakterlánc (bájt); assertEquals ("Baeldung", húr);

Pár dolog történik itt, elemezzük:

• MessageProp az ügyfél használja a betakar metódust és generálja a tokent
• A módszer, a metódus betakar az adatok kriptográfiai MIC-jét is hozzáadja, a MIC a token részeként van kötegelve
• A tokent elküldjük a szervernek (esetleg hálózati híváson keresztül)
• A szerver kihasználja MessageProp ismét beállítani a kibont módszer és visszakeresheti az adatokat
• Továbbá a módszer kibont ellenőrzi a fogadott adatok MIC-jét, biztosítva az adatok integritását

Ennélfogva az ügyfél és a szerver integritással és bizalmasan képesek adatokat cserélni.

4.4. Kerberos beállítása a példához

Most egy GSS mechanizmus, mint A Kerberostól általában elvárják, hogy egy meglévőről szerezze be a hitelesítő adatokat Tantárgy. Osztály Tantárgy itt van egy JAAS-absztrakció, amely olyan entitást képvisel, mint egy személy vagy egy szolgáltatás. Ez általában JAAS alapú hitelesítés során kerül feltöltésre.

Példánkban azonban közvetlenül nem használunk JAAS-alapú hitelesítést. Hagyjuk, hogy a Kerberos közvetlenül szerezzen be hitelesítő adatokat, esetünkben egy kulcsfájl segítségével. Ennek eléréséhez van egy JVM rendszerparaméter:

-Djavax.security.auth.useSubjectCredsOnly = hamis

A Sun Microsystem által biztosított alapértelmezett Kerberos-implementáció azonban a JAAS-ra támaszkodik a hitelesítés biztosításában.

Ez ellentmondhat az imént tárgyaltaknak. Felhívjuk figyelmét, hogy kifejezetten használhatjuk a JAAS-t alkalmazásunkban, amely feltölti a Tantárgy. Vagy hagyja az alapul szolgáló mechanizmusra a közvetlen hitelesítést, ahol egyébként is használja a JAAS-t. Ezért meg kell adnunk egy JAAS konfigurációs fájlt az alapul szolgáló mechanizmusnak:

com.sun.security.jgss.initiate {com.sun.security.auth.module.Krb5LoginModule szükséges useKeyTab = true keyTab = példa.keytab fő = "client / localhost" storeKey = true; }; com.sun.security.jgss.accept {com.sun.security.auth.module.Krb5LoginModule szükséges useKeyTab = true keyTab = example.keytab storeKey = true principál = "HTTP / localhost"; };

Ez a konfiguráció egyszerű, ahol a Kerberost definiáltuk a szükséges bejelentkezési modulként mind az iniciátor, mind az elfogadó számára. Ezenkívül úgy konfiguráltuk, hogy egy kulcsfájl fájlból használjuk a megfelelő alapelveket. Ezt a JAAS konfigurációt átadhatjuk a JVM-nek rendszerszintű paraméterként:

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

Itt az a feltételezés, hogy hozzáférünk egy Kerberos KDC-hez. A KDC-ben felállítottuk a szükséges főkönyvet, és megszereztük a Keytab fájlt, amit mondjuk használhatunk “Példa.keytab”.

Ezenkívül szükségünk van a Kerberos konfigurációs fájlra, amely a jobb KDC-re mutat:

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

Ez az egyszerű konfiguráció egy KDC-t definiál, amely az 52135 porton fut, alapértelmezett tartománya: EXAMPLE.COM. Ezt rendszerparaméterként átadhatjuk a JVM-nek:

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

4.5. A példa futtatása

A példa futtatásához meg kell használja fel az utolsó szakaszban tárgyalt Kerberos-tárgyakat.

Továbbá át kell adnunk a szükséges JVM paramétereket:

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

Ez elegendő ahhoz, hogy a Kerberos hitelesítést hajtson végre a kulcskártya és a GSS hitelesítő adataival a kontextusok megállapításához.

5. GSS API a való világban

Míg a GSS API számos biztonsági probléma megoldását ígéri plug-in mechanizmusok révén, kevés olyan felhasználási eset van, amelyet szélesebb körben elfogadottak:

• Ez az széles körben használják a SASL-ben biztonsági mechanizmusként, főleg ott, ahol Kerberos a mögöttes választási mechanizmus. A Kerberos egy széles körben használt hitelesítési mechanizmus, különösen egy vállalati hálózaton belül. Nagyon hasznos kihasználni a Kerberised infrastruktúrát egy új alkalmazás hitelesítéséhez. Ezért a GSS API szépen áthidalja ezt a rést.
• Ez is SPNEGO-val konjugálva használják tárgyalni egy biztonsági mechanizmusról, ha egyelőre nem ismert. Ebben a tekintetben az SPNEGO bizonyos értelemben a GSS API álmechanizmusa. Ezt minden modern böngésző széles körben támogatja, így képesek kihasználni a Kerberos-alapú hitelesítést.

6. GSS API összehasonlításban

A GSS API meglehetősen hatékonyan nyújt biztonsági szolgáltatásokat az alkalmazások számára plug-in módon. Ennek elérése azonban nem az egyetlen választás a Java-ban.

Értsük meg, mit kínál még a Java, és hogyan viszonyulnak a GSS API-hoz:

• Java Secure Socket kiterjesztés (JSSE): A JSSE a Java csomagcsomagja, amely a Secure Sockets Layer (SSL) Java-t valósítja meg. Biztosítja az adatok titkosítását, az ügyfél és a szerver hitelesítését, valamint az üzenet integritását. A GSS API-val ellentétben a JSSE egy nyilvános kulcsú infrastruktúrára (PKI) támaszkodik. Ezért a GSS API rugalmasabb és könnyebb, mint a JSSE.
• Java egyszerű hitelesítési és biztonsági réteg (SASL): A SASL az internetes protokollok hitelesítésének és adatbiztonságának kerete amely leválasztja őket a meghatározott hitelesítési mechanizmusokról. Ez hatókörében hasonló a GSS API-hoz. A Java GSS azonban korlátozott mértékben támogatja a mögöttes biztonsági mechanizmusokat a rendelkezésre álló biztonsági szolgáltatókon keresztül.

Összességében elmondható, hogy a GSS API eléggé hatékony a biztonsági szolgáltatások mechanikus agnosztikus módon történő nyújtásában. A Java több biztonsági mechanizmusának támogatása azonban ezt tovább fogja vezetni.

7. Következtetés

Összefoglalva, ebben az oktatóanyagban megértettük a GSS API mint biztonsági keretrendszer alapjait. Átnéztük a Java API-t a GSS-hez, és megértettük, hogyan tudjuk ezeket kihasználni. Ennek során egyszerű kliens és szerver összetevőket hoztunk létre, amelyek kölcsönös hitelesítést hajtottak végre és biztonságosan cseréltek adatokat.

Továbbá azt is láttuk, hogy melyek a GSS API gyakorlati alkalmazásai, és milyen alternatívák állnak rendelkezésre a Java-ban.

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

Most jelentettem be az újat Tanulj tavaszt tanfolyam, amelynek középpontjában az 5. tavasz és a tavaszi bakancs 2 alapjai állnak: