streamalism.org

Jeg kunngjorde nettopp det nye Lær våren kurs, med fokus på det grunnleggende i vår 5 og vårstøvel 2:

1. Oversikt

I denne opplæringen vil vi forstå Generic Security Service API (GSS API) og hvordan vi kan implementere det i Java. Vi får se hvordan vi kan sikre nettverkskommunikasjon ved hjelp av GSS API i Java.

I prosessen vil vi lage enkle klient- og serverkomponenter, sikre dem med GSS API.

2. Hva er? GSS API?

Så, hva er egentlig Generic Security Service API? GSS API gir et generelt rammeverk for applikasjoner som bruker forskjellige sikkerhetsmekanismer som Kerberos, NTLM og SPNEGO på en pluggbar måte. Derfor hjelper det applikasjoner å koble seg fra sikkerhetsmekanismene direkte.

For å avklare spenner sikkerheten her autentisering, dataintegritet og konfidensialitet.

2.1. Hvorfor trenger vi GSS API?

Sikkerhetsmekanismer som Kerberos, NTLM og Digest-MD5 er ganske forskjellige i deres evner og implementeringer. Vanligvis finner en applikasjon som støtter en av disse mekanismene det ganske skremmende å bytte til en annen.

Dette er hvor et generelt rammeverk som GSS API gir applikasjoner en abstraksjon. Derfor kan applikasjoner som bruker GSS API forhandle om en passende sikkerhetsmekanisme og bruke den til kommunikasjon. Alt dette uten å måtte implementere noen mekanismespesifikke detaljer.

2.2. Hvordan gjør GSS API-arbeid?

GSS API er en tokenbasert mekanisme. Det fungerer etter utveksling av sikkerhetstokener mellom jevnaldrende. Denne utvekslingen skjer vanligvis over et nettverk, men GSS API er agnostisk for disse detaljene.

Disse tokens genereres og behandles av de spesifikke implementeringene av GSS API. De syntaksen og semantikken til disse tokens er spesifikke for sikkerhetsmekanismen forhandlet mellom jevnaldrende:

Det sentrale temaet i GSS API dreier seg om en sikkerhetskontekst. Vi kan etablere denne sammenhengen mellom jevnaldrende gjennom utveksling av tokens. Vi kan trenge flere utvekslinger av tokens mellom jevnaldrende å etablere sammenhengen.

Når vellykket er etablert i begge ender, kan vi bruke sikkerhetskonteksten til å utveksle data sikkert. Dette kan omfatte dataintegritetssjekker og datakryptering, avhengig av den underliggende sikkerhetsmekanismen.

3. GSS API-støtte i Java

Java støtter GSS API som en del av pakken "org.ietf.jgss". Pakkens navn kan virke merkelig. Det er fordi Java-bindinger for GSS API er definert i en IETF-spesifikasjon. Spesifikasjonen i seg selv er uavhengig av sikkerhetsmekanismen.

En av de populære sikkerhetsmekanismene for Java GSS er Kerberos v5.

3.1. Java GSS API

La oss prøve å forstå noen av de viktigste APIene som bygger Java GSS:

• GSSContext innkapsler GSS API-sikkerhetskontekst og gir tjenester tilgjengelige under konteksten
• GSSCredential innkapsler GSS API-legitimasjonen for en enhet som er nødvendig for å etablere sikkerhetskonteksten
• GSSnavn innkapsler GSS API-hovedenheten som gir en abstraksjon for forskjellige navneområder som brukes av underliggende mekanismer

Bortsett fra de ovennevnte grensesnittene, er det få andre viktige klasser å merke seg:

• GSSManager fungerer som fabrikklasse for andre viktige GSS API-klasser som GSSnavn, GSSCredential, og GSSContext
• Oid representerer Universal Object Identifiers (OIDs) som er hierarkiske identifikatorer som brukes i GSS API for å identifisere mekanismer og navneformater
• MessageProp bryter inn egenskaper for å indikere GSSContext på ting som Quality of Protection (QoP) og konfidensialitet for datautveksling
• ChannelBinding innkapsler den valgfrie kanalbindingsinformasjonen som brukes til å styrke kvaliteten som autentisering av jevnlig enhet blir gitt

3.2. Java GSS sikkerhetsleverandør

Mens Java GSS definerer kjernen for implementering av GSS API i Java, gir den ikke en implementering. Java vedtar Forsørger-baserte pluggbare implementeringer for sikkerhetstjenester inkludert Java GSS.

Det kan være en eller flere slike sikkerhetsleverandører registrert hos Java Cryptography Architecture (JCA). Hver sikkerhetsleverandør kan implementere en eller flere sikkerhetstjenester, som Java GSSAPI og sikkerhetsmekanismer under.

Det er en standard GSS-leverandør som leveres med JDK. Imidlertid er det andre leverandørspesifikke GSS-leverandører med forskjellige sikkerhetsmekanismer som vi kan bruke. En slik leverandør er IBM Java GSS. Vi må registrere en slik sikkerhetsleverandør hos JCA for å kunne bruke dem.

Videre, hvis nødvendig, vi kan implementere vår egen sikkerhetsleverandør med mulig tilpassede sikkerhetsmekanismer. Imidlertid er dette knapt nødvendig i praksis.

4. GSS API gjennom et eksempel

Nå ser vi Java GSS i aksjon gjennom et eksempel. Vi oppretter en enkel klient- og serverapplikasjon. Klienten blir oftere referert til som initiator og server som aksept i GSS. Vi bruker Java GSS og Kerberos v5 under for autentisering.

4.1. GSS-kontekst for klient og server

Til å begynne med må vi etablere en GSSContext, både på serveren og klientsiden av søknaden.

La oss først se hvordan vi kan gjøre dette på klientsiden:

GSSManager manager = GSSManager.getInstance (); Streng serverPrinciple = "HTTP / [e-postbeskyttet]"; GSSName servernavn = manager.createName (serverPrinciple, null); Oid krb5Oid = ny 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);

Det er ganske mange ting som skjer her, la oss bryte dem ned:

• Vi begynner med å lage en forekomst av GSSManager
• Deretter bruker vi denne forekomsten til å lage GSSContext, passerer langs:
  • en GSSnavn representerer serverens rektor, merknad det Kerberos-spesifikke hovednavnet her
  • de Oid av mekanismen å bruke, Kerberos v5 her
  • initiativtakerens legitimasjon, null her betyr at standard legitimasjon vil bli brukt
  • levetiden for den etablerte konteksten
• Til slutt forbereder vi oss konteksten for gjensidig autentisering, konfidensialitet og dataintegritet

På samme måte må vi definere konteksten på serversiden:

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

Som vi kan se er dette mye enklere enn kontekst på klientsiden. Den eneste forskjellen her er at vi trenger godkjenningsopplysninger som vi har brukt som null. Som før, null betyr at standard legitimasjon vil bli brukt.

4.2. GSS API-godkjenning

Selv om vi har opprettet serveren og klientsiden GSSContext, vær oppmerksom på at de ikke er etablert på dette stadiet.

For å etablere disse sammenhengene, må vi bytte tokens som er spesifikke for den angitte sikkerhetsmekanismen, det vil si Kerberos v5:

// På klientsiden clientToken = clientContext.initSecContext (ny byte [0], 0, 0); sendToServer (clientToken); // Dette skal sendes over nettverket // På server-siden serverToken = serverContext.acceptSecContext (clientToken, 0, clientToken.length); sendToClient (serverToken); // Dette skal sendes over nettverket // Tilbake på klientsiden clientContext.initSecContext (serverToken, 0, serverToken.length);

Dette gjør endelig konteksten etablert i begge ender:

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

4.3. GSS API Sikker kommunikasjon

Nå som vi har en kontekst etablert i begge ender, vi kan begynne å sende data med integritet og konfidensialitet:

// På klientsiden byte [] messageBytes = "Baeldung" .getBytes (); MessageProp clientProp = ny MessageProp (0, sant); byte [] clientToken = clientContext.wrap (messageBytes, 0, messageBytes.length, clientProp); sendToClient (serverToken); // Dette skal sendes over nettverket // På server-siden MessageProp serverProp = new MessageProp (0, false); byte [] bytes = serverContext.unwrap (clientToken, 0, clientToken.length, serverProp); Strengstreng = ny streng (byte); assertEquals ("Baeldung", streng);

Det er et par ting som skjer her, la oss analysere:

• MessageProp brukes av klienten til å stille inn pakke inn metode og generere token
• Metoden pakke inn legger også til kryptografisk MIC av dataene, MIC er samlet som en del av tokenet
• Atken sendes til serveren (muligens over en nettverksanrop)
• Serveren utnytter MessageProp igjen for å stille inn pakke ut metode og få tilbake data
• Også metoden pakke ut verifiserer MIC for mottatte data, og sikrer dataintegriteten

Derfor er klienten og serveren i stand til å utveksle data med integritet og konfidensialitet.

4.4. Kerberos-oppsett for eksemplet

Nå, en GSS-mekanisme som Det forventes vanligvis at Kerberos henter legitimasjon fra en eksisterende Emne. Klassen Emne her er en JAAS-abstraksjon som representerer en enhet som en person eller en tjeneste. Dette fylles vanligvis ut under en JAAS-basert autentisering.

Imidlertid, for vårt eksempel, bruker vi ikke direkte en JAAS-basert autentisering. Vi lar Kerberos få legitimasjon direkte, i vårt tilfelle ved hjelp av en keytab-fil. Det er en JVM-systemparameter for å oppnå det:

-Djavax.security.auth.useSubjectCredsOnly = false

Standardverdiene Kerberos-implementeringen fra Sun Microsystem er imidlertid avhengig av at JAAS gir autentisering.

Dette kan høres i strid med det vi nettopp diskuterte. Vær oppmerksom på at vi eksplisitt kan bruke JAAS i applikasjonen vår som vil fylle ut Emne. Eller la det være til den underliggende mekanismen for å autentisere direkte, der det uansett bruker JAAS. Derfor må vi gi en JAAS-konfigurasjonsfil til den underliggende mekanismen:

com.sun.security.jgss.initiate {com.sun.security.auth.module.Krb5LoginModule kreves useKeyTab = true keyTab = eksempel.keytab principal = "client / localhost" storeKey = true; }; com.sun.security.jgss.accept {com.sun.security.auth.module.Krb5LoginModule kreves useKeyTab = true keyTab = eksempel.keytab storeKey = true principal = "HTTP / localhost"; };

Denne konfigurasjonen er rett frem, der vi har definert Kerberos som den nødvendige påloggingsmodulen for både initiativtaker og akseptor. I tillegg har vi konfigurert til å bruke de respektive rektorene fra en tastaturfil. Vi kan overføre denne JAAS-konfigurasjonen til JVM som en systemparameter:

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

Her er antagelsen at vi har tilgang til en Kerberos KDC. I KDC har vi satt opp de nødvendige rektorene og fått takkefilen du skal bruke, la oss si “Eksempel.keytab”.

I tillegg trenger vi Kerberos-konfigurasjonsfilen som peker mot høyre KDC:

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

Denne enkle konfigurasjonen definerer en KDC som kjører på port 52135 med et standardområde som EXAMPLE.COM. Vi kan overføre dette til JVM som en systemparameter:

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

4.5. Kjører eksemplet

For å kjøre eksemplet må vi benytt deg av Kerberos-gjenstandene som ble diskutert i den siste delen.

Vi må også overføre de nødvendige JVM-parametrene:

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

Dette er tilstrekkelig for at Kerberos kan utføre autentisering med legitimasjon fra keytab og GSS for å etablere sammenhenger.

5. GSS API i den virkelige verden

Mens GSS API lover å løse en rekke sikkerhetsproblemer gjennom pluggbare mekanismer, er det få brukssaker som har blitt mer adoptert:

• Det er mye brukt i SASL som en sikkerhetsmekanisme, spesielt der Kerberos er den underliggende valgmekanismen. Kerberos er en mye brukt autentiseringsmekanisme, spesielt i et bedriftsnettverk. Det er veldig nyttig å utnytte en Kerberised infrastruktur for å autentisere en ny applikasjon. Derfor bygger GSS API det gapet pent.
• Det er også brukt i konjugasjon med SPNEGO å forhandle om en sikkerhetsmekanisme når man ikke er kjent på forhånd. I denne forbindelse er SPNEGO en pseudomekanisme for GSS API på en måte. Dette støttes bredt i alle moderne nettlesere, noe som gjør dem i stand til å utnytte Kerberos-basert autentisering.

6. GSS API i sammenligning

GSS API er ganske effektivt når det gjelder å tilby sikkerhetstjenester til applikasjoner på en pluggbar måte. Det er imidlertid ikke det eneste valget å oppnå dette i Java.

La oss forstå hva annet Java har å tilby, og hvordan sammenligner de seg med GSS API:

• Java Secure Socket Extension (JSSE): JSSE er et sett med pakker i Java som implementerer Secure Sockets Layer (SSL) for Java. Det gir datakryptering, klient- og serverautentisering og meldingsintegritet. I motsetning til GSS API, stoler JSSE på at en Public Key Infrastructure (PKI) fungerer. Derfor fungerer GSS API for å være mer fleksibel og lett enn JSSE.
• Java Simple Authentication and Security Layer (SASL): SASL er et rammeverk for autentisering og datasikkerhet for internettprotokoller som kobler dem fra spesifikke autentiseringsmekanismer. Dette har samme omfang som GSS API. Java GSS har imidlertid begrenset støtte for underliggende sikkerhetsmekanismer gjennom tilgjengelige sikkerhetsleverandører.

Generelt sett er GSS API ganske kraftig når det gjelder å tilby sikkerhetstjenester på en agnostisk måte. Imidlertid vil støtte for flere sikkerhetsmekanismer i Java ta dette videre i adopsjonen.

7. Konklusjon

For å oppsummere, i denne opplæringen, forsto vi det grunnleggende om GSS API som et sikkerhetsrammeverk. Vi gikk gjennom Java API for GSS og forsto hvordan vi kan utnytte dem. I prosessen opprettet vi enkle klient- og serverkomponenter som utførte gjensidig autentisering og utvekslet data sikkert.

Videre så vi også hva som er praktiske anvendelser av GSS API, og hva er alternativene som er tilgjengelige i Java.

Som alltid kan koden bli funnet på GitHub.

Jeg kunngjorde nettopp det nye Lær våren kurs, med fokus på det grunnleggende i vår 5 og vårstøvel 2: