Authentication and Authorization in Java Systems
Sadržaj |
Authentication and Authorization in Java Systems
U ovoj temi obraditi će općenito što je to autentikacija (eng. authentication) i autorizacija (eng. authorization), te na primjeru Java sustava demonstrirati kako se to izvodi kroz sami java kod. Autentikacija je zapravo proces u kojem korisnik, koji bi trebao biti čovjek, verificira svoj identitet, dok je autorizacija proces kojim se programskom podrškom ostvaruje kontrola pristupa do određenih dijelova aplikacija, naravno nakon što se zna identitet korisnika koji šalje zahtjev za pristup do sadržaja. Kada se gleda cjelina ova dva koncepta idu ruku pod ruku, jer bez autorizacije i nema neke potrebe za autentikacijom, dok bez autentikacije ne postoji mogućnost kojom bi se mogla uvidjeti razlika između korisnika kojima se vjeruje, i onima kojima se ne vjeruje. Ponekad se javlja potreba da se individualno autenticira svaki korisnik, zbog posebnih prava te zbog same sigurnosti sustava, a ponekad je dovoljno autenticirati po grupi, tj. dodijeliti određena prava grupi, naravno pritom treba voditi brigu da se ne ugrozi sigurnost sustava. Još jedan zanimljiv aspekt autentikacije i autorizacije je da jedan entitet može imati nekoliko uloga u sustavu, tako na primjer jedna osoba može biti u isto vrijeme zaposlenik tvrtke, te i tajnik koji bi imao neka dodatna prava u odnosu na običnog zaposlenika. Kada se promatraju ova dva pojma važno je napomenuti da iako se čini da se oni odvijaju kombinirano autentikacija uvijek prethodi autorizaciji.
Autentikacija
Autentikacija je u užem smislu zapravo proces u kojem se podaci koje korisnik unosi (pruža) uspoređuju s onima unutar baze podataka, ili unutar nekog sustava u kojem se spremaju podaci za korisnika najčešće je te autentikacisjki server, a to je zapravo aplikacija koja olakšava autentikaciju entiteta koji pokušava pristupiti mreži ili u ovom slučaju određenom sustavu. Ukoliko podaci koji su poslani od strane korisnika odgovaraju proces se smatra završenim te se korisniku provjerava pravo pristupa unutar sustava. Rezultat ovog dijela rada sustava je pravo pristupa do određenih datoteka te područja sustava s kojima korisnik koji se prijavi može komunicirati. Postavke svih definiranih ograničenja te prava koja se dodjeljuju najčešće određuje administrator, koji ima krovnu ulogu u samom sustavu.
Elementi autentikacije
Autentikacija se praktički bazira na nekoliko elemenata:
• Što znamo. (eng. What you know.) – Ova kategorija uključuje informacije koje pojedinac zna, a ostatak korisnika ne zna, neki primjeri bi bili razni pinovi, lozinke i osobne informacije koje ne želimo da budu javne.
• Što posjedujemo. (eng. What you have.) – Ova kategorija uključuje fizičke elemente koji omogućuju pojedincu da dobije pristup pojedinim resursima, neki primjeri bi bili kreditne kartice te različite bankovne kartice.
• Tko smo. (eng. Who you are.) – Ova kategorija uključuje različite biometrije poput otiska prsta fotografija i slično.
Većinom je potrebno više od jedne kategorije za autorizaciju, primjer bi bio korištenje kreditne kartice na bankomatu, koja zahtjeva pin uz fizički element koji je u ovom slučaju kartica. Ovime se dodatno može osigurati sigurnost da iako se izgubi kartica, sigurnost kartice nije kompromitirana u velikoj razini, no naravno nije ni potpuno sigurnost zajamčena.
Jednofaktorska autentikacija (Autentikacija putem lozinke)
U početku izrade sustava potreba za zaštitom određenih resursa unutar sustava bila je puno jednostavnija, mnogo sustavi su bili sigurni, tj. bili su dovoljno sigurni za mogućnosti tadašnjih računala, no razvojem sve jačih računala i pojačavanjem računalne opreme pojavila se mogućnost vrlo brzog probijanja lozinke koju posjeduje određeni korisnik. Nakon toga uvodila su se pravila razne veće dužine lozinka te čak i uvođenje fraza za lozinke kako bi se otežalo probijanje lozinke. No kako uvijek postoji mogućnost da kada se uloži određeni trud lozinka bude probijena, to je primarno zato što svaki ovakav pristup koji zahtjeva bazu da se korisnik autenticira, ta baza naravno može imati kriptirane lozinke, no ukoliko postoji i najmanja slabost spremanja lozinke, napadač može brzinom koja je ograničena samo njegovom hardverskom opremom pogađati lozinku te nakon određenog vremena otkriti te kompromitirati sigurnost resursa određenog korisnika unutar sustava. Od ovakvih napada korisnik se može zaštititi tako da koristi razne lozinke koje se teže probijaju, koje mogu biti razne kombinacije ili fraze koje i nemaju pretjeranog smisla, a sustav se može zaštiti korištenjem najnovijih verzija svih alata koje posjeduje te naravno krpanjem svih sigurnosnih propusta koji mogu postojati unutar samog sustavu. U nastavku je prikazan pristup do resursa kada se koristi jednofaktorska autentikacija, zbog jednostavnosti nije prikazano korištenje certifikata kako bi se provjerilo dali je pristup do sustava siguran tj. dali je sustav kojem korisnik pristupa označen sustav kojemu se vjeruje.
Slika 1. Jednofaktorska autentikacija vlastita izrada
Dvofaktorska autentikacija
Dvofaktorska autentikacija ili kako se često zove verifikacija u dva koraka, je sigurnosni proces u kojem korisnik sustavu pruža dva faktora (elementa) autentikacije koja su ranije navedena, kako bi potvrdio tko je on zapravo. Dvofaktorska autentikacija pruža dodatni sloj sigurnosti i otežava napadaču da dobije pristup do korisnikovih podataka, ili nekih zaštićenih resursa, jer sad nije dovoljno samo poznavati npr. korisnikovu šifru kako bi se autentikacija smatrala uspješnom, nego je dodatno potrebno znati još jedan faktor. Ovakva vrsta autentikacije je uvedena primarno kako bi se korisnici dodatno zaštitili kada se dogodi krađa baze podataka, ili kako je korisnikova lozinka otkrivena putem „phishing“ napada. Važno je napomenuti da korištenje dva faktora iz iste kategorije se i dalje smatra jednofaktorskom autentikacijom primjer bi bio korištenje lozinke, te neke tajne riječi, jer oboje spadaju u autentikacijski faktor znanja, tj. onoga što korisnik zna. Kada se želi implementirati dvofaktorska autentikacija važno je spomenuti da postoji više uređaja te servisa s kojima se ta implementacija može izvesti, a neki od tih su tokeni, razne kartice te čak i različite aplikacije. S implementacijske strane ovo se rješava tako da se implementira generator tokena koji se generira prilikom prijave te kreiranjem infrastrukture za provjeru i prihvaćanje generiranog tokena te nakon toga autenticira korisnika koji ima ispravan token. Prvi dio procesa tj. generiranje tokena može biti i fizički uređaj kao što je „Yubikey“, ili kartica koju korisnik posjeduje, te može postojati unutar software-a kao mobilna, web ili desktop aplikacija koja generira PIN kod za autentikaciju. Drugi dio procesa se rješava tako da postoji sustav koji će prihvatiti procesirati te dopustiti ili odbiti pristup korisniku koji se autenticira s tokenom. Pojavljuje se pitanje dali je dvofaktorska autentikacija sigurna, to se može odgovoriti jednostavno a to je da je onoliko sigurna koliko je sigurna najslabija komponenta sustava, za primjer se može uzeti zaobilaženje dvofaktorske autentikacije, a najpoznatiji slučaj je hakiranje Gmail računa izvršnog direktora „Cloudflare“ i to na način da su putem oporavka računa uspjeli resetirati sve podatke za prijavu te tako zaobići dvofaktorsku autentikaciju. Dugo je najpoznatiji način dvofaktorske autentikacije bilo slanje dodatnog PIN-a putem SMS poruke jer je jeftin, lako se implementira se i smatra se da je lak za korištenje korisniku, no treba uzeti u obzir da je ovaj način autentikacije ranjiv na brojne napade, te je upravo iz tog razloga obustavljen (eng. deprecated) od strane NIST-a u „Special Publication 800-63-3: Digital Authentication Guidelines“, a napad koji se može izvesti je hakiranje mobilne mreže „Signaling System 7“, a malware koji postoji je „Eurograbber“ koji može presresti ili preusmjeriti SMS poruke. Primjer rada dvofaktorske autentikacije može se vidjeti na sljedećoj slici, prikazana je dvofaktorska autentikacija koja se koristi za sustav Facebook te koji kako se može vidjeti koristi nesiguran način dvofaktorske autentikacije tj. koristi slanje PIN-a tj. šesteroznamenkastog broja korisniku putem SMS poruke.
Slika 2. Dvofaktorska autentikacija vlastita izrada
JAAS (Java Authentication and Authorization Service)
JAAS je implementacija standardnog programskog okvira „Pluggable Authenication Module“ (PAM) od strane Jave, predstavljen je kao ekstenzija unutar biblioteka u standardnoj verziji Java platforme 1.3 te je integriran u verziji 1.4. Glavna uloga je odvajanje briga korisničke autentikacije, te uvodi dodatni mehanizam zaštite. To se najbolje vidi po tome da su prethodni mehanizmi autentikacije sadržavali informacije o podrijetlu koda i tko je potpisao kod JAAS dodaje i marker o onome tko pokreće kod. Login moduli primarno vode brigu o autentikaciji, a od njega se očekuje da implementira „javax.security.auth.spi.LoginModule“ sučelje koje specificira sljedeće metode:
Initialize – Kod za inicijalizaciju login modula najčešće tako da spremi parametre koji su proslijeđeni u za to namijenjene atribute klase
Login- Provjerava podatke koji su proslijeđeni putem objekta koji implementira „javax.security.auth.Callback“ sučelje. Ova metoda može obavijestiti korisnika da treba unijeti svoje podatke ili može koristiti prethodno dobivene detalje. Važno za napomenuti je da ukoliko se unesu pogrešni podaci potrebno je baciti grešku „javax.security.auth.login.FailedLoginException“
Commit – Kada se verificira korisnikov identitet, kod u metodama može postaviti uloge
Abort – Poziva se ukoliko je proces autentikacije zakazao, ukoliko ova metoda vrati false tada se Login modul ignorira
Logout – Kod koji se izvšava kod odjave korisnika
Na sljedećoj slici može se vidjeti arhitektura JAAS-a tj. primjer kako JAAS ostvaruje uključivost (eng. pluggability):
Slika 3. JAAS arhitektura preuzeto s "https: //www.javaworld.com/article/2074873/java-web-development/all-that-jaas.html" 06.02.2018.
Na sljedećoj slici može se vidjeti kako JAAS zapravo izgleda sa svim svojim elementima:
Slika 4. Elementi JAAS-a preuzeto s "https ://docs.oracle.com/cd/E19798-01/821-1794/gepfq/index.html" 06.02.2018.
Autorizacija
Autorizacija se praktički bazira na dva osnovna načina kontrole pristupa do osjetljivog koda:
• Deklarativna (eng. Declarative) autorizacija može biti izvedena od strane administratora sustava, koji konfigurirati pristup sustavu, tj. definira tko može pristupiti kojim aplikacijama unutar sustava. Kod ovog načina autorizacije privilegije pristupa korisnika se mogu dodavati, mijenjati ili obnavljati po potrebi i to bez utjecaja na kod same aplikacije.
• Programska (eng. Programmatic) autorizacija koristi java kod aplikacije za ostvarenje autorizacijskih odluka. Ona je potrebna kada odluke kod autorizacije zahtijevaju složeniju logiku i odluke koje su iznad mogućnosti prethodno navedene autorizacije. Kako je ovaj način autorizacije ugrađen unutar koda aplikacije, razne promjene koje se izvode zahtijevaju istovremenu promjenu koda same aplikacije.
OAuth
OAuth je otvoreni protokol koji omogućava web stranicama ili aplikacijama (eng. Consumers) da pristupe zaštićenim resursima web servisa putem API-ja, bez zahtijevanja korisnika da otkrije podatke davatelja usluga (eng. Service Provider) aplikacijama (eng. Consumer). Primjer tj. slučaj korištenja je dopuštanje servisu za ispisivanje (Consumer) da pristupi privatnim fotografijama spremljenim na pružatelju usluga (eng. Service Provider) bez zahtijevanja korisnika da unose svoje korisničke podatke koje su spremljene kod pružatelja usluga, samom Cosumer-u tj. u ovom slučaju servisu za ispisivanje. Kada se gleda kroz povijest OAuth Core 1.0 verzija je krenula s radom 2007. godine no već 2009. godine prestaje potpora te se kreće s novom verzijom a to je OAuth Core 1.0 Revision A, kako bi se popravio „session fixation attack“. Primarna razlika između OAuth 1.0a te OAuth 2.0 je ta da OAuth 2.0 zahtjeva HTTPS. Proces autentikacije u vezriji 1.0a prikazan je na sljedećoj slici:
Slika 5. Proces autentikacije OAuth 1.0a preuzeto s "https ://www.cubrid.org/blog/dancing-with-oauth-understanding-how-authorization-works", 05.02.2018.
Terminologija koja se koristi unutar OAuth protokola i koju je važno razumjeti prije početka rada:
Potpisano/ Potpis (eng. Signed/Signature) – String koji se sastoji od nekoliko elemenata HTTP zahtjeva, ovo uključuje Metoda zahtjeva (eng. Request Method), URL i Parametre koji su kriptirani putem ključa koji se sastoji od „consumer_secret“ i „token_secret“, kada se koristi RSA kriptiranje najčešće se koristi samo „consumer_secret“.
Ključ potrošača (eng. Consumer Key) – String identifikator generiran od strane API-ja koji se koristi za OAuth rukovanje (eng. Handshake). Ekvivalent korisničkom imenu.
Tajna potrošača (eng. Consumer Secret) – Jedinstveni token generiran za korištenje kod OAuth rukovanja, i ona služi kao element za kreiranje potpisa (eng. signature)
Nonce/UID – Jedinstveno generiran ID zadane duljine, po standardu duljina je 32 znaka
OAuth Token – Token koji generira server kod potpisanog zahtjeva, može biti ili „request_token“ ili „access_token“ zavisno o tome u kojem koraku toka se nalazimo
OAuth Token Secret - Ovo je tajna koja se uobičajeno šalje s zahtjevom za određenim tokenom. Koristi se i za razmjenu, generiranje potpisa ili osvježavanje „access_token“-a
Query – Dio URL-a koji sadrži ključ-vrijednost (eng. key-value) podatke koji se pozovu sa simbolom „?“ ključ i vrijednosti su odvojeni s znakom „=“, dok je potpis i svaki podatak odvojen znakom „&“, primjer http : //httpbin.org /?query=looks&like=this
Parametar/Argument – Ovo su zapravo djelići informacije koji su oblika „oauth_token = 'helloWorld' “gdje je prvi dio tj. dio prije znaka „=“ parametar ili argument a drugi dio je vrijednost
Plaintext – Kao što samo ime kaže potpuno čitljivi tekst
HMAC-SHA1 – Kombinacija hash algoritma i autentikacijskog koda poruke baziranog na hashu, ova kombinacija daje bolju sigurnost, jer je SHA1 nesiguran sam po sebi od napada kolizijom
RSA-SHA1 – Kombinacija hash algoritma i privatnog i javnog ključa
Service – Pružatelj informacija, izvora podataka, Twitter je primjer jednog servisa
Signature Method – Prihvaćene metode kriptiranja, mogu biti neke od sljedećih: „PLAINTEXT“, „HMAC-SHA1“, „RSA-SHA1“
Value – Informacija u relaciji s parametrom
URL/URI – Lokacija na internetu ili u resursima
OAuth 1.0a je također zapostavljena, tj. označena je kao „deprecated“, jer je od 2012. godine predstavljen OAuth 2.0 koji nije kompatibilan s ranijim verzijama (eng. backward compatible). OAuth2 je puno jednostavniji od OAuth1 jer ne zahtjeva digitalne potpise, i umjesto toga sva komunikacije ide kroz SSL protokol. OAuth2.0 standard definira četiri uloge:
Resource owner – Korisnik koji autorizira aplikaciju kako bi mogla pristupiti njegovom računu
Client – Aplikacija (web, mobile, itd.) koja želi korisnikove resurse
Resource Server – Web server s kojega se pokušavaju dohvatiti resursi
Authorization server – Server koji posjeduje korisnikove podatke i on verificira identitet korisnika
Na sljedećoj slici može se vidjeti tijek rada autorizacije koristeći OAuth2.0:
Slika 6. Authorization Code tip autorizacijskih odobrenja preuzeto s "https ://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2" 06.02.2018.
Literatura
[1] www.github.com, GitHub, "https ://github.com/scribejava/scribejava/blob/master/scribejava-apis/src/test/java/com/github/scribejava/apis/examples/TwitterExample.java" preuzeto 05.02.2018.
[2] Implementing Twitter Sign-In for Web Apps, Akoskm, "http: //akoskm.com/2015/07/31/twitter-sign-in-for-web-apps.html" preuzeto 06.02.2018.
[3] TechTarget, Margaret Rouse, preuzeto s "http ://searchsecurity.techtarget.com/definition/authentication" na dan 05.02.2018.
[4] DigitalOcean, preuzeto s "https ://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2" na dan 06.02.2018.
[5] Emil Kleszcz, Java web application based on OAuth2, preuzeto s "https ://db-blog.web.cern.ch/blog/emil-kleszcz/2016-08-java-web-application-based-oauth2" na dan 05.02.2018.
[6] OAuth, preuzeto s "https ://oauth.net/1/" na dan 05.02.2018.
[7] Changhun Oh, Dancing with OAuth: Understanding how Authorization Works, preuzeto s "https ://www.cubrid.org/blog/dancing-with-oauth-understanding-how-authorization-works" na dan 05.02.2018.
[8] Nijiko Yonskai, The OAuth Bible pruezeto s "http ://oauthbible.com/" na dan 05.02.2018.
[9] IETF, The OAuth 2.0 Authorization Framework, preuzeto s "https ://tools.ietf.org/html/rfc6749" na dan 05.02.2018.
[10] Alex Zhitnitsky, OverOps, Tutorial: How to Implement Java OAuth 2.0 to Sign-In with GitHub and Google, preuzeto s "https ://blog.takipi.com/tutorial-how-to-implement-java-oauth-2-0-to-sign-in-with-github-and-google/" na dan 05.02.2018.
[11] Varun Ojha, IBM, Client credentials grant preuzeto s "https ://www.ibm.com/developerworks/library/se-oauthjavapt2/index.html" na dan 06.02.2018.
[12] ORACLE, JAAS Authentication Tutorial, preuzeto s "https ://docs.oracle.com/javase/7/docs/technotes/guides/security/jaas/tutorials/GeneralAcnOnly.html" na dan 05.02.2018.
