Uvod

Cilj ovog projekta prikazati je slojeve sigurnosti koji se mogu postići na poslovnoj Java EE aplikaciji. Kako slojeve sigurnosti možemo grupirati u aplikacijski, transportni te Sloj za prijenos poruka, pokazati će se na primjeru korištenja GlassFish poslužitelja i NetBeans IDE razvojnog okruženja kako je moguće svaki od navedenih slojeva podesiti, koje su mogućnosti dostupne, te što koja od navedenih mogućnosti omogućava krajnjem korisniku.

Pregled Java EE Sigurnosti

Enterprise razina i web razine poslovne aplikacija su sastavljene od komponenti koje su smještene u različitim vrstama spremnika. Ove komponente u različitim kombinacijama stvaraju poslovnu aplikaciju od više razina. Sigurnosne komponente ove aplikacije razmatramo kroz njihove spremnike. Spremnici mogu imati dvije vrste sigurnosti : deklarativnu i programiranu.

• Deklarativna sigurnost se postiže kroz korištenje tzv. opisnika aplikacije (engl. deployment descriptor) ili putem anotacija (engl. annotations).
  

Opisnik aplikacije je XML datoteka smještena izvan poslovne aplikacije u kojoj su definirane sigurnosne postavke. Ove sigurnosne postavke su npr. razine pristupa, razine sigurnosti, autentikacijski uvjeti itd. Kako je opisnik aplikacije datoteka, moguće je raditi izmjene na njoj bez potrebe za izmjenama u programskom kodu poslovne aplikacije. U radu, aplikacija čita opisnik i primjenjuje pravila na pripadajuću aplikaciju, modul ili komponentu poslovne aplikacije. U slučaju Java EE aplikacija, opisnik aplikacije ima naziv web.xml a smješten je u WEB-INF direktoriju. Kako je prije navedeno, opisnik je XML datoteka a detalje o specifikaciji i implementaciji moguće je dobiti na Java Community Process stranicama.

Anotacije ili metadata izvornog koda koriste se za definiranje informacija o sigurnosti unutar class datoteke. Kada se aplikacija isporuči, ovako definirane informacije imaju veći prioritet nego deklarativno definirana sigurnost.

• Programibilna sigurnost je ugrađena u samu poslovnu aplikaciju i služi za donošenje odluka. Njeno korištenje posebno dolazi do izražaja kada sama deklarativna sigurnost nije dostatna.

Značajke sigurnosnih mehanizama

Sigurnosni mehanizmi koji su pravilno implementirani pružaju sljedeće funkcionalnosti

• sprječavaju neautorizirani pristup funkcijama poslovne aplikacije i poslovnim (privatnim) podacima
• drži korisnike poslovne aplikacije odgovornima za radnje koje vrše u poslovnoj aplikaciji (spriječava odricanje odgovornosti)
• štiti informacijski sustav od prekida usluge i ostalih potencijalnih čimbenika koji mogu utjecati na kvalitetu usluge
• jednostavan je za administraciju
• transparentan korisnicima poslovne aplikacije (izvor: Overview of Java EE Security)

Karakteristike sigurnosti poslovne aplikacije

Poslovne java aplikacije sastavljene su od komponenti koje mogu sadržavati kako zaštićene, tako i nezaštićene resurse. Cilj je primijeniti metode kako bi osigurali zaštićene resurse kako bi samo autorizirani korisnici njima imali pristup. Autorizacija se stoga temelji na identifikaciji i provjeri korisnika koji žele ostvariti pristup resursu. Identifikacija je proces koji omogućuje prepoznavanje korisnika od strane poslovne aplikacije dok proces provjere korisnika možemo opisati kao proces u kojem provjeravamo identitet korisnika. Ovi procesi predstavljaju temelj za ostvarivanje pristup zaštićenom resursu. Za slučaj da navedene metode ne provodimo nad korisnikom aplikacije, za takvog korisnika možemo reći da nije provjeren ili da je anoniman korisnik.

Aplikacije koje pravilno provode proces identifikacije i provjere korisnika smanjuju sigurnosnu prijetnju kojoj je poslovna aplikacija izložena a poslovna aplikacija time postiže sljedeće karakteristike :

• provjera korisnika (engl. authentication) - postupak neophodan da bi se potvrdilo da korisnik aplikacije jest onaj koji tvrdi da je
• provjera prava korisnika (engl. authorization ili engl access control) - utvrđujemo ukoliko korisnik aplikacije ima dozvolu za izvođenje operacije ili pristup podacima
• konzistencija podataka (engl. data integrity) - karakteristika koja dokazuje da informacija nije bila izmijenjena od treće strane, te da je izvorna onoj koju je pošiljatelj poslao.
• privatnost informacija (engl. confidentiality) - samo korisnici koji imaju pravo pristupa podatku mogu raditi izmjene i pregled podataka
• ne mogućnost poricanja (engl. non-repudiation) - karakteristika zahvaljujući kojoj korisnik ne može poreći radnju na poslovnoj aplikaciji. Ovo osigurava mogućnost dokazivanja radnji korisnika
• kvalitetu usluge (engl. quality of service)
• reviziju događaja (engl. audit) - stvaranje zapisa o događajima sa ciljem procjene efikasnosti sigurnosnih pravila i postupaka poslovne aplikacije.(izvor: Overview of Java EE Security)

Mehanizmi osiguranja sigurnosti

Prilikom izrade poslovne aplikacije bitno je odabrati mehanizme sigurnosti. Svaki od navedenih mehanizama može se implementirati individualno ili u kombinaciji sa nekim od drugih navedenih mehanizama. Kada govorimo o Java poslovnim aplikacijama, možemo razlikovati nekoliko slojeva sigurnosti. Redom ovi slojevi su : aplikacijski sloj, transportni sloj i sloj sigurnosti za prijenos poruka.

• Aplikacijski sloj sigurnosti koristimo kako bi pružili siguran pristup uslugama i podacima koje poslovna aplikacija nudi. Sigurnosne postavke definirane u ovom sloju odnose se samo na odabranu poslovnu aplikaciju i nisu prenosive na druge aplikacije koje postoje u istom okružju.

Prednosti korištenja ovog sloja sigurnosti su sljedeće :

• postavke su definirane u skladu sa potrebama aplikacije
• postavke aplikacijskog sloja sigurnosti ovise o aplikacijskim karakterističnim postavkama

Nedostatci korištenja aplikacijskog sloja sigurnosti :

• aplikacija je ovisna o sigurnosnim postavkama što onemogućava izmjenu tipa aplikacije
• podrška za više protokola čini ovaj tip sigurnosnog sloja ranjivim
• podaci su sadržani u točki ranjivosti

• Transportni sloj sigurnosti pruža transportni mehanizam korišten u prijenosu informacija između klijenta i servera, najčešće korisniku je to poznato kao HTTP ili HTTPS sloj u komunikaciji. Ovaj sloj predstavlja važnu točku u infrastrukturi aplikacije kako se koristi za identifikaciju i provjeru korisnika i njegovih prava te prijenos podataka.

Prednosti korištenja transportnog sloja sigurnosti

• korištenje tehnologije koja je jednostavna a dobro shvaćena i prihvaćena kod korisnika
• primjenjuje se kako na sadržaj poruke koja je šalje slojem tako i na priloge poruci

Nedostatci korištenja transportnog sloja

• snažno su povezani sa transportnim slojem, ovdje prvenstveno želimo naglasiti razliku između recimo SOAP tehnologije koja nema snažnu vezu
• koristi metodologiju "sve ili ništa", ukoliko se sigurna veza ne može uspostaviti, neće se uspostaviti uopće. Isto se odnosi i na sadržaj koji šaljemo transportnim slojem, sadržaj ne može biti selektivno zaštićen
• zaštita poruke u transportnom sloju postoji samo dok je podatak u njemu. U trenutku kada podatak napusti transportni sloj njegova se zaštita ukida

• Sloj za prijenos poruka sigurnosne informacije sadržava unutar SOAP poruka i unutar SOAP priloga poruke. Kako poruka u svome kretanju mrežom može proći kroz nekoliko čvorišta prije dolaska do željenog odredišta a tijekom tog kretanja poruka zadržava svoje karakteristike sigurnosti, ovaj sloj sigurnosti često nazivamo end-to-end sigurnost.

Prednosti korištenja sigurnosti sloja za prijenos poruka

• poruka je osigurana tijekom svog putovanja do odredišta
• sigurnosna politika se može selektivno primijeniti na dijelove poruke
• sigurnost poruke je neovisna o prethodnim slojevima sigurnosti (aplikacijskom i transportnom sloju)

Nedostatci korištenja ovog sloja sigurnosti

• kompleksnost implementacije

Realms, Users, Groups, and Roles - Aplikacijski sloj

Provođenje kontrole identiteta (autentikacija) i pristupnih dozvola (autorizacija) temelje se na domenama (realm). Domena se sastoji od "baze podataka" korisničkih imena i pripadajućih lozinki, te korisnicima pridruženih uloga. Postoje sljedeće vrste domena:

• JDBCRealm - pristupa autentikacijskim podacima koji su pohranjeni u relacijskoj bazi podataka kojoj se pristupa putem JDBC
• DataSourceRealm - pristupa autentikacijskim podacima koji su pohranjeni u relacijskoj bazi podataka kojoj se pristupa putem imenovanog JNDI JDBC zvora podataka (DataSource).
• JNDIRealm - pristupa autentikacijskim podacima koji su pohranjeni u LDAP baziranom poslužitelju, a pristupa se putem JNDI pružatelja.
• UserDatabaseRealm - pristupa autentikacijskim podacima koji su pohranjeni u UserDatabase JNDI izvoru, koji je tipično podržan XML dokumentom (conf/tomcatusers.xml).
• MemoryRealm - pristupa autentikacijskim podacima koji su pohranjeni u memorijskoj kolekciji objekata, koja je inicijalizirana iz XML dokumenta (conf/tomcat-users.xml).
• JAASRealm - pristupa autentikacijskim podacima putem JAAS okvira (Java Authentication & Authorization Service). (prema : NWTIS;FOI)

Podešavanje GlassFish poslužitelja

U osnovi baza podataka potrebna za ostvarivanje minimuma autentikacijske sigurnosti sastoji se od dvije tablice. Prva tablica sadrži atribute korisničkog imena i lozinke dok druga tablica ima kao atribute korisničko ime i ime grupe kojoj korisnik pripada. Važno je napomenuti da korisničko ime predstavlja primarni ključ i da ova organizacijska shema nije u potpunosti optimizirana.

S gotovom pripremom u bazi podataka, drugi korak je samo podešavanje na GlassFish poslužitelju. Pokretanjem administracijskog sučelja poslužitelja ( ukoliko je lokalno adresa je standardna http://localhost:4848/common/index.jsf, odabiremo Configurations opciju, zatim server-config, te onda Security pa Realms. Jednom kada smo odabrali opciju Realms, odabiremo New dugme i nastavljamo sa unosom osnovnih podataka koji moraju biti usklađeni sa prethodno unesenim podacima u bazi podataka koju koristimo za smještaj informacija o korisnicima. U ovome koraku možemo obratiti pozornost na JNDI resurs koji je potrebno prethodno definirati u Resources->JDBC a u kojemu je stvorena veza sa bazom podataka. Ovim putem smo uspješno podesili GlassFish poslužitelj za korištenje JDBCRealm-a.

Podešavanje razvojnog okruženja

<form method="POST" action="j_security_check">
     <h:outputLabel value="Korisničko ime"/>
     <input type="text" name="j_username" />
     
     <h:outputLabel value="Lozinka"/>
     <input type="password" name="j_password" />
                
     <input type="submit" value="Login" />
</form>

Preostalo je još izvršiti definiranje grupa korisnika i prava pristupa te izvršiti povezivanje definiranih grupa sa grupama definiranih u bazi podataka. Ovo se može napraviti stvaranjem GlassFish Descriptor dokumenta (File->New File->GlassFish->GlassFish Descriptor) gdje u Security opciji izvršimo mapiranje grupa.

Ostvarivanje sigurne veze - Transportni sloj

Secure Socket Layer ili skraćeno SSL je tehnologija koja omogućava internet preglednicima i poslužiteljima sigurnu komunikaciju. Ovo podrazumijeva da su poslani podaci kriptirani s jedne strane, poslani, te zatim dekriptirani s druge strane prije nego što ih je moguće koristiti. Ovaj proces je dvosmjeran, što znači da i poslužitelj i klijent(internet preglednik) kriptiraju sav promet prije slanja drugoj strani. Za korisnika, ovaj proces se najbolje ogleda pri pokušaju učitavanja internet stranice gdje ga poslužitelj traži potvrdu certifikata. U nekim slučajevima poslužitelj može tražiti i potvrdu identiteta korisnika iako to je praksa koja je više prisutna u poslovnim (B2B) transakcijama. Certifikati o kojima je riječ predstavljaju osobnu kartu poslužitelja te se kao takvi moraju moći provjeriti. Ova provjera odvija se kod izdavatelja certifikata ili tzv. Cerificate Authority(CA), usporedbu kojih je moguće naći na sljedećoj adresi. Kupovina Certifikata od CA osigurava tzv. zelenu traku koja korisnicima ukazuje da je veza sa poslužiteljem sigurna i nema straha da netko prisluškuje promet.

Stvaranje osobnog certifikata

Java razvojno okruženje omogućava stvaranje tzv. osobnih certifikata (engl. self-signed Certificate) koji se mogu koristiti kako u svrhe testiranja aplikacije, tako i u svrhe gdje je osobni certifikat dostatan za dokazivanje identiteta. Za ovaj postupak koristiti ćemo komandnu aplikaciju koja se isporučuju sa Java development kit (skraćeno JDK) nazvanu keytool.exe (izvor: Key and Certificate Management Tool javadoc).

Certifikati od entiteta kojima se vjeruje tipično se uključuju u vlastito spremište ključeva (engl. Java key store) kao povjerljivi certifikati. Javni ključ u takvom certifikatu može se koristiti za provjeru potpisa koji su generirani korištenjem korespondirajućeg privatnog ključa. Privatni ključevi i njima pridruženi certifikati javnih ključeva spremaju se u bazu podataka koja je zaštićena lozinkom i naziva se spremište ključeva. Ono može sadržavati dvije vrste elemenata:

• povjerljive certifikate
• parove ključ/certifikat kod kojih svaki sadrži privatni ključ i certifikat javnog ključa.

Svaki ključ u spremištu ključeva označen je tzv. aliasom koji se koristi u npr. postavkama poslužitelja kada moramo definirati koje spremište ključeva poslužitelj koristi za provjeru identiteta.

C:\Program Files\Java\jdkXX\bin>keytool.exe
Key and Certificate Management Tool

Commands:

 -certreq            Generates a certificate request
 -changealias        Changes an entry's alias
 -delete             Deletes an entry
 -exportcert         Exports certificate
 -genkeypair         Generates a key pair
 -genseckey          Generates a secret key
 -gencert            Generates certificate from a certificate request
 -importcert         Imports a certificate or a certificate chain
 -importpass         Imports a password
 -importkeystore     Imports one or all entries from another keystore
 -keypasswd          Changes the key password of an entry
 -list               Lists entries in a keystore
 -printcert          Prints the content of a certificate
 -printcertreq       Prints the content of a certificate request
 -printcrl           Prints the content of a CRL file
 -storepasswd        Changes the store password of a keystore

Use "keytool -command_name -help" for usage of command_name

C:\Program Files\Java\jdkXX\bin>keytool -genkeypair -alias kbilic -keyalg RSA -keystore kbilicKS.jks -storepass 123456 -keypass 654321
What is your first and last name?
  [Unknown]:  Krunoslav Bilic
What is the name of your organizational unit?
  [Unknown]:  Fakultet organizacije i informatike
What is the name of your organization?
  [Unknown]:  University of Zagreb
What is the name of your City or Locality?
  [Unknown]:  Varazdin
What is the name of your State or Province?
  [Unknown]:  Varazdin
What is the two-letter country code for this unit?
  [Unknown]:  HR
Is CN=Krunoslav Bilic, OU=Fakultet organizacije i informatike, O=University of Z
agreb, L=Varazdin, ST=Varazdin, C=HR correct?
  [no]:  yes

C:\Program Files\Java\jdkXX\bin>keytool -keystore kbilicKS.jks -list
Enter keystore password:123456

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

kbilic, 24-Nov-2015, PrivateKeyEntry,
Certificate fingerprint (SHA1): 05:DB:46:3B:A2:52:64:AC:EA:AD:6F:97:80:68:58:72:B4:46:03:80

C:\Users\giri>keytool -export -keystore kbilicKS.jks -storepass 123456 -alias kbilic -file kbilic.cer
Certificate stored in file <kbilic.cer>

Iz toga možemo zaključiti neke karakteristike Certifikata :

• Certifikat je javni ključ, stvoren iz Java key store-a (JKS) gdje se nalazi u paru sa privatnim ključem koji služi za kriptiranje-dekriptiranje poruke. JKS se koristi od strane platforme kao sigurna baza takvih ključeva.
• Certifikat sadrži informaciju o jasnom nazivu entiteta (osoba, tvrtka) koji ga je certificirao. Taj entitet se refleksira kao subjekt certifikata odnosno vlasnik. Informacija o jasnom nazivu sadrži sljedeće atribute :

• naziv entiteta
• organizacijska jedinica
• organizacija
• grad ili lokalitet
• državu ili provinciju
• kod države

• Certifikat sadrži digitalni potpis. Certifikat je potpisan od entiteta, izdavača, koji jamči za činjenicu da je uključeni javni ključ stvarni javni ključ drugog entiteta, vlasnika.
• i konačno Certifikat sadrži jasnu informaciju o potpisniku, izdavaču - Certificate Authority (CA).

Podešavanje sigurnosti transportnog sloja

Ranije je navedeno da za postizanje deklarativne sigurnosti možemo koristiti tzv. opisnik aplikacije (engl. deployment descriptor). Ovaj segment odnosi se na transportni sloj veze korisnika i klijenta, a objašnjava podešavanje razine sigurnosti koja je očekivana u toj komunikaciji. U razvojnom programskom okruženju NetBeans podešavanje deklarativne sigurnosti možemo ostvariti koristeći ugrađeni alat za vizualizaciju postavki. Otvaranjem web.xml datoteke, odabiremo Security panel gdje se susrećemo sa tri kategorije : Login Configuration , Security Roles i Security Constraint. Kako smo u aplikacijskoj razini sigurnosti definirali uloge i razine pristupa, sada nam se otvara mogućnost odabira razine sigurnosti za transportni sloj. Odabirom Enable User Data Constraint definiramo razinu garantirane sigurnosti za prijenos podataka. Ovdje su nam dostupne mogućnosti CONFIDENTIAL, INTEGRAL i NONE.

U ovisnosti o odabiru, razinu sigurnosti transportnog sloja možemo definirati :

• CONFIDENTIAL - razmjenu podataka između klijenta i poslužitelja nije moguće nadzirati od treće strane
• INTEGRAL - podaci koji se razmjenjuju se mogu nadzirati ali ih treća strana ne može izmijeniti dok se komunikacija odvija
• NONE - ne pruža razinu sigurnosti, odnosno poslužitelj neće zahtijevati razinu sigurnosti transportnog sloja.

U praksi Java EE poslužitelji za CONFIDENTIAL i INTEGRAL razinu sigurnosti postupaju jednako.

Podešavanje GlassFish poslužitelja

Kako bi poslužitelj bio upoznat sa osobnim Certifikatom koji smo kreirali ranije potrebno je u poslužiteljevo spremište ključeva unijeti osobni Certifikat i napraviti određene izmjene. Prilikom instalacije GlassFish poslužitelja, poslužitelj stvara vlastiti osobni Certifikat koji se koristi za lokalno testiranje. Vlastiti Certifikat koji GlassFish poslužitelj stvara učestalo nije prepoznat od strane klijenta jer kao što je ranije navedeno, to je osobni certifikat. Unatoč tome certifikat je s klijentske strane moguće prihvatiti jednokratno ili trajno.

Ukoliko testiranje aplikacije vršimo u razvojnom okruženju, te koristimo NetBeans kao razvojno sučelje na Windows operacijskom sučelju, domain1 se uobičajeno nalazi na lokaciji C:\Users\User\AppData\Roaming\NetBeans\8.0.2\config\GF_4.1. U mapi config nalaze se konfiguracijske datoteke za postavke domene i spremište ključeva poslužitelja.

Kada se vrši provjera Certifikata poslužitelja, vrši se i provjera da li je naziv Certifikata - polje CN - jednako potpunom nazivu poslužitelja (engl. fully-qualified domain name). Ukoliko nazivi nisu identični, javlja se sigurnosna greška ili upozorenje.

Koristeći opisanu proceduru za kreiranje osobnog Certifikata, stvorili smo jedan koji u CN polju sadrži localhost vrijednost.

>keytool -list -v -keystore kbilicKS.jks -storepass 123456

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 2 entries

Alias name: kbilic
Creation date: 24-Nov-2015
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=Krunoslav Bilic, OU=Fakultet organizacije i informatike, O=University
of Zagreb, L=Varazdin, ST=Varazdin, C=HR
Issuer: CN=Krunoslav Bilic, OU=Fakultet organizacije i informatike, O=University
 of Zagreb, L=Varazdin, ST=Varazdin, C=HR
Serial number: 110554cf
Valid from: Tue Nov 24 21:54:19 CET 2015 until: Mon Feb 22 21:54:19 CET 2016
Certificate fingerprints:
         MD5:  6B:A0:CA:E1:BB:F9:59:42:F5:B5:B1:48:88:55:7C:23
         SHA1: 05:DB:46:3B:A2:52:64:AC:EA:AD:6F:97:80:68:58:72:B4:46:03:80
         SHA256: C5:78:6E:71:4C:B1:1A:C9:41:27:BA:1F:D6:FB:41:79:33:D5:8D:C3:0B:4D:E3:9E:DF:94:04:94:BE:B8:9B:1B
         Signature algorithm name: SHA256withRSA
         Version: 3

Extensions:

#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: AE 72 08 6B 58 A9 32 F6   C8 6F 21 93 02 92 0D 6B  .r.kX.2..o!....k
0010: 84 C3 8D EB                                        ....
]
]



*******************************************
*******************************************


Alias name: localhost
Creation date: 25-Nov-2015
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=localhost, OU=Fakultet organizacije i informatike, O=University of Zag
reb, L=Varazdin, ST=Varazdin, C=HR
Issuer: CN=localhost, OU=Fakultet organizacije i informatike, O=University of Za
greb, L=Varazdin, ST=Varazdin, C=HR
Serial number: 65eb1dab
Valid from: Wed Nov 25 09:50:37 CET 2015 until: Tue Feb 23 09:50:37 CET 2016
Certificate fingerprints:
         MD5:  5D:44:ED:38:2F:A7:23:55:15:E0:F3:1C:CA:C5:72:04
         SHA1: 38:B8:CE:1A:B6:AA:2E:69:1C:79:C4:64:45:21:D9:BF:E2:86:27:3C
         SHA256: 75:83:DB:05:92:76:C6:6D:43:F3:1C:1E:64:24:DF:9D:06:AE:B7:06:D6:B2:CD:C5:57:20:1C:5E:4C:DA:3C:53
         Signature algorithm name: SHA256withRSA
         Version: 3

Extensions:

#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 9F EB 3A 68 C7 03 B4 90   3B E2 57 74 41 9D 93 CA  ..:h....;.WtA...
0010: 3E 33 06 8D                                        >3..
]
]

*******************************************
*******************************************

Koristeći isti postupak, osobni certifikat izvezemo iz privatnog JKS-a. Sada kada posjedujemo localhost.cer datoteku možemo početi postupak uvođenja iste u skladište ključeva poslužitelja.

C:\Users\User\AppData\Roaming\NetBeans\8.0.2\config\GF_4.1\domain1\config>keytool -list -v -keystore keystore.jks
Enter keystore password:

*****************  WARNING WARNING WARNING  *****************
* The integrity of the information stored in your keystore  *
* has NOT been verified!  In order to verify its integrity, *
* you must provide your keystore password.                  *
*****************  WARNING WARNING WARNING  *****************

...

*******************************************
*******************************************


Alias name: xws-security-client
Creation date: 25-Nov-2015
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=xwssecurityclient, OU=SUN, O=Internet Widgits Pty Ltd, ST=Some-State,
C=AU
Issuer: CN=SUNCA, OU=JWS, O=SUN, ST=Some-State, C=AU
Serial number: 3
Valid from: Mon Mar 12 11:24:40 CET 2007 until: Thu Mar 09 11:24:40 CET 2017
Certificate fingerprints:
         MD5:  D1:45:A1:A9:6D:A9:57:9F:69:35:E3:4C:63:B6:98:C9
         SHA1: 47:45:53:77:60:84:69:34:C3:DE:A2:7F:94:0A:26:9B:7D:47:01:14
         SHA256: 63:3E:B5:5D:E1:5B:97:E5:70:9B:03:18:B9:5F:10:CB:A8:07:65:0C:B0:9E:5C:3D:69:2C:F3:28:54:CF:62:67
         Signature algorithm name: MD5withRSA
         Version: 3

Extensions:

#1: ObjectId: 2.16.840.1.113730.1.13 Criticality=false
0000: 16 1D 4F 70 65 6E 53 53   4C 20 47 65 6E 65 72 61  ..OpenSSL Genera
0010: 74 65 64 20 43 65 72 74   69 66 69 63 61 74 65     ted Certificate


#2: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 67 BA 65 C6 CE 95 C8 E3   8E 4D 21 72 A2 30 D5 D3  g.e......M!r.0..
0010: F6 18 8C 95                                        ....
]
[CN=SUNCA, OU=JWS, O=SUN, ST=Some-State, C=AU]
SerialNumber: [    db1e425a aba2a28e]
]

#3: ObjectId: 2.5.29.19 Criticality=false
BasicConstraints:[
  CA:false
  PathLen: undefined
]

#4: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: FE 62 2D 7E FB 85 75 2E   C0 D0 60 B2 B0 4E F5 4C  .b-...u...`..N.L
0010: 54 71 3F 67                                        Tq?g
]
]



*******************************************
*******************************************


Alias name: s1as
Creation date: 21-Aug-2014
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=localhost, OU=GlassFish, O=Oracle Corporation, L=Santa Clara, ST=Calif
ornia, C=US
Issuer: CN=localhost, OU=GlassFish, O=Oracle Corporation, L=Santa Clara, ST=Cali
fornia, C=US
Serial number: 31eb8d9f
Valid from: Thu Aug 21 15:30:10 CEST 2014 until: Sun Aug 18 15:30:10 CEST 2024
Certificate fingerprints:
         MD5:  59:4F:81:11:21:79:0C:71:53:2A:00:AB:22:3E:0E:8A
         SHA1: 1F:F8:EF:F1:B1:7D:C7:44:19:1E:21:3A:31:02:9A:A7:59:82:A6:3C
         SHA256: 08:DE:FE:E6:7D:8B:16:8E:29:B8:0A:97:E5:23:3C:8B:E3:2B:31:6E:D3:89:AA:CE:05:BE:31:DA:A7:02:03:6B
         Signature algorithm name: SHA256withRSA
         Version: 3

Extensions:

#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 13 55 DB 7D A9 31 71 A3   33 40 56 D3 49 A9 77 42  .U...1q.3@V.I.wB
0010: 90 A3 59 39                                        ..Y9
]
]



*******************************************
*******************************************

Iz priloženog je vidljivo da localhost certifikat nosi par sa aliasom s1as.

C:\Users\User\AppData\Roaming\NetBeans\8.0.2\config\GF_4.1\domain1\config>keytoo
l -delete -alias s1as -keystore keystore.jks
Enter keystore password: changeit

C:\Users\giri\AppData\Roaming\NetBeans\8.0.2\config\GF_4.1\domain1\config>keytoo
l -delete -alias s1as -keystore keystore.jks
Enter keystore password:

C:\Users\giri\AppData\Roaming\NetBeans\8.0.2\config\GF_4.1\domain1\config>keytoo
l -import -v -alias s1as -file localhost.cer -keystore keystore.jks -storepass c
hangeit
Owner: CN=localhost, OU=Fakultet organizacije i informatike, O=University of Zag
reb, L=Varazdin, ST=Varazdin, C=HR
Issuer: CN=localhost, OU=Fakultet organizacije i informatike, O=University of Za
greb, L=Varazdin, ST=Varazdin, C=HR
Serial number: 65eb1dab
Valid from: Wed Nov 25 09:50:37 CET 2015 until: Tue Feb 23 09:50:37 CET 2016
Certificate fingerprints:
         MD5:  5D:44:ED:38:2F:A7:23:55:15:E0:F3:1C:CA:C5:72:04
         SHA1: 38:B8:CE:1A:B6:AA:2E:69:1C:79:C4:64:45:21:D9:BF:E2:86:27:3C
         SHA256: 75:83:DB:05:92:76:C6:6D:43:F3:1C:1E:64:24:DF:9D:06:AE:B7:06:D6:
B2:CD:C5:57:20:1C:5E:4C:DA:3C:53
         Signature algorithm name: SHA256withRSA
         Version: 3

Extensions:

#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 9F EB 3A 68 C7 03 B4 90   3B E2 57 74 41 9D 93 CA  ..:h....;.WtA...
0010: 3E 33 06 8D                                        >3..
]
]

Trust this certificate? [no]:  yes
Certificate was added to keystore
[Storing keystore.jks]

C:\Users\User\AppData\Roaming\NetBeans\8.0.2\config\GF_4.1\domain1\config>keytool -certreq -alias s1as -file localhost.cer -keystore keystore.jks -storepass changeit

U ovome primjeru krenuli smo putem osobnih certifikata i brisanjem postojećih certifikata iz skladišta ključeva. Alternativno mogli smo dodati vlastiti certifikat i napraviti potrebne izmjene u GlassFish admin sučelju kao što je prikazano u galeriji.

Reference

• Napredne Web tehnologije i servisi -predavanja- FOI
• Overview of Java EE Security
• SIS Wiki
• Java Platform, Enterprise Edition (Java EE) 7
• Java EE 6 Cookbook for Securing, Tuning, and Extending Enterprise Applications; Mick Knutson; 2012
• GlassFish Security; Masoud Kalali; 2010

--kbilic 02:47, 27. studenog 2015. (CET)