J2EE sigurnost: spremnik nasuprot prilagođenom

Od prvog dodavanja stranice za prijavu u web-aplikaciju, sigurnost je uvijek bila jedna od ključnih komponenti kritičnih za uspjeh aplikacija na webu. Povijesno je sve bilo kodirano ručno. Svaka web aplikacija imala je prilagođenu metodu autentifikacije, a zatim i autorizacije korisnika. Programeri su također ugradili komponente za registraciju, administraciju i sve druge potrebne funkcije. Iako poprilično režijski, ovaj je pristup omogućio veliku fleksibilnost.

Pojavom JAAS-a, Java Authentication and Authorization Service, aplikacije su dobile set sučelja i konfiguraciju koju su mogle iskoristiti za standardizaciju tih zadataka. Čak i s dodavanjem JAAS-a u specifikaciju, J2EE i dalje mora riješiti nekoliko problema prije nego što programeri aplikacija mogu prestati stvarati prilagođene API-je. Odabir između upotrebe J2EE standarda ili izrade prilagođenog rješenja zahtijeva poznavanje kompromisa svakog i, naravno, zahtjeva vaše aplikacije.

Ovaj članak ima za cilj pružiti sve informacije potrebne za odlučivanje između prilagođene sigurnosti ili sigurnosti spremnika. Raspravljam o najčešćim sigurnosnim funkcijama aplikacija kako bih pružio potrebnu pozadinu sigurnosti. Nakon te rasprave slijedi detaljno objašnjenje J2EE sigurnosnih implementacija predviđenih specifikacijama, kao i najčešće metode primjene prilagođene sigurnosti. Nakon što bolje razumijete svaku od metoda, trebali biste imati dovoljno podataka da odaberete koja metoda najbolje odgovara zahtjevima vaše aplikacije.

Što je kontejner?

Prije nego što razgovaramo o različitim vrstama sigurnosti i problemima oko implementacije sigurnosti, pregledajmo što je spremnikje. Spremnik je okruženje u kojem se aplikacija izvodi. Također je sinonim za poslužitelj aplikacija J2EE. Što se tiče J2EE spremnika, unutar spremnika radi J2EE aplikacija koja ima specifične odgovornosti u odnosu na aplikaciju. Postoji mnogo različitih vrsta J2EE spremnika i različite razine podrške za J2EE. Tomcat iz Apachea web je spremnik koji implementira samo dijelove Servleta (web aplikacija) J2EE specifikacije. BEA-in WebLogic potpuno je sukladan J2EE aplikacijski poslužitelj, što znači da podržava sve aspekte J2EE specifikacije i prošao je Sunine J2EE certifikacijske testove. Ako niste sigurni u podršku koju pruža vaš poslužitelj aplikacija, za više informacija obratite se dobavljaču.

Sigurnost aplikacije

Druga tema koju moramo obraditi prije nego što započnemo jest razlika između sigurnosti aplikacija i drugih vrsta sigurnosti. Sigurnost aplikacije je zaštita koju izravno izvodi aplikacija ili neizravno okvir ili spremnik za aplikaciju u odnosu na korisnike te aplikacije. Primjer korisnika aplikacije je netko tko se prijavi u internetsku knjižaru i kupi nekoliko Java knjiga. Postoje i druge vrste sigurnosti, poput mrežne i JVM zaštite. Jedan od primjera tih vrsta sigurnosti je korisnik koji pokreće Java proces na stroju. U ostatku ovog članka, kad god raspravljam o sigurnosti, mislim na sigurnost aplikacija. Ostale vrste sigurnosti dosežu izvan dosega ove rasprave.

Ovdje je fokus posebno na sigurnosti J2EE, koja je vrsta zaštite aplikacija jer se bavi korisnicima J2EE aplikacije (tj. Pozivima). Korisnik može biti netko tko koristi mrežnu knjižaru ili drugu aplikaciju koja koristi usluge kupnje aplikacije knjižara, poput drugog mrežnog prodavača.

Sigurnosne funkcije aplikacija

Pet je glavnih funkcija kada se razmatra sigurnost aplikacije: provjera autentičnosti, autorizacija, registracija, održavanje računa (ažuriranja) i brisanje / deaktiviranje računa. Iako samo mali podskup svih mogućih funkcija koji aplikacija može imati, ovo su najosnovnije i prilično standardne za sve programe. Manje formalno, ove funkcije su poznavanje korisnika (provjera autentičnosti), znanje što korisnik može učiniti (autorizacija), stvaranje novih korisnika (registracija), ažuriranje korisničkih podataka (održavanje računa) i uklanjanje korisnika ili sprečavanje korisnika u pristupu aplikaciji (brisanje računa).

Većina aplikacija omogućuje korisniku ili administratoru izvršavanje ovih funkcija. Kada korisnici izvršavaju ove funkcije, oni to čine za sebe. Administratori uvijek izvršavaju ove funkcije u ime drugih korisnika.

Kao što će biti prikazano, sve se ove funkcije ne mogu ostvariti bez prilagođenog rješenja, čak ni za provjeru autentičnosti. Kratko ćemo razmotriti svaku od njih kako bismo dalje ilustrirali koncepte i ono što nedostaje J2EE, a što mora biti izrađeno po mjeri.

Ovjera

Autentifikacija je postupak identificiranja korisnika koji komunicira s aplikacijom. U vrijeme pisanja ovog članka, J2EE provjera autentičnosti mogla se provesti pomoću različitih rješenja, od kojih je svako definirano kao dio J2EE specifikacije (verzija 1.0-1.4). Autentifikacija je glavni koncept ove rasprave i bit će detaljnije obrađena kasnije. Važno je shvatiti da je provjera autentičnosti sigurnosna funkcija koja ima najviše podrške u okviru J2EE specifikacije, ali za provedbu J2EE provjere identiteta (aka provjera autentičnosti spremnika) obično je potreban prilagođeni kôd ili konfiguracija.

Odobrenje

Ovlaštenje je postupak provjere da li korisnik ima dopuštenje za poduzimanje određene radnje. J2EE pokriva ovu temu, ali ograničena je na autorizaciju na temelju uloga, što znači da se aktivnost može ograničiti na temelju uloga koje je korisnik dobio. Na primjer, korisnici u ulozi upravitelja možda će moći brisati inventar, dok korisnici u ulozi zaposlenika možda neće.

Uz to, aplikacije mogu razmotriti dvije različite vrste autorizacije: Java Runtime Environment (JRE) / spremnik i autorizacija aplikacije. JRE / autorizacija spremnika postupak je utvrđivanja ima li korisnik koji podnosi zahtjev povlastice za to. JRE / spremnik to određuje prije bilo kojeg izvršavanja koda. Primjer je J2EE spremnik koji prvo mora provjeriti ima li trenutni korisnik dozvole za izvršavanje servleta (putem ograničenja URL-a resursa) prije izvođenja servleta. Ova vrsta autorizacije poznata je i kao deklarativna sigurnostjer je deklariran u konfiguracijskim datotekama za web aplikaciju. Ako spremnik nije podržan, deklarativna sigurnost ne može se mijenjati tijekom izvođenja. Deklarativna sigurnost može se koristiti na više načina za autorizaciju korisnika J2EE aplikacije, ali ta tema izlazi izvan dosega ove rasprave. (Pogledajte poglavlje 12. Specifikacije Servleta 2.3. Odjeljak 2 obuhvaća deklarativnu sigurnost, a 8 je dobra polazna točka za sigurnosna ograničenja.)

Kao što je već spomenuto, korisnik može biti neka druga aplikacija ili jednostavno korisnik aplikacije. U svakom slučaju, JRE / autorizacija spremnika provodi se tijekom svakog zahtjeva. Ti zahtjevi mogu biti HTTP zahtjevi iz preglednika za web aplikaciju ili udaljeni EJB (Enterprise JavaBeans) pozivi. U oba slučaja, pod uvjetom da JRE / spremnik poznaje korisnika, može izvršiti autorizaciju na temelju podataka tog korisnika.

Ovlaštenje aplikacije postupak je autorizacije tijekom izvršavanja aplikacije. Ovlaštenje aplikacije može se dalje raščlaniti na autorizaciju na temelju uloga i na temelju segmenata. Primjer autorizacije aplikacije temeljene na ulogama je kada aplikacija primjenjuje različite razine označavanja na temelju toga je li korisnik zaposlenik ili posjetitelj (tj. Popust zaposlenika). J2EE nudi API-je koji se nazivaju programska sigurnost za postizanje autorizacije temeljene na ulogama (za više informacija pogledajte poglavlje 12, odjeljak 3 specifikacije Servleta 2.3).

Ovlaštenje temeljeno na segmentima je autorizacija zasnovano na ostalim korisnikovim atributima, kao što su dob ili hobi. Ovlaštenje temeljeno na segmentima naziva se takvo jer grupira korisnike u segmente na temelju određenih atributa. J2EE nema metodu provedbe autorizacije zasnovane na segmentima. Primjer autorizacije na temelju segmenta je je li gumb na obrascu vidljiv korisnicima starijim od 40 godina. Određeni dobavljači mogu ponuditi ovu vrstu autorizacije, ali to bi jamčilo zaključavanje dobavljača u svim slučajevima.

Registracija

Registracija je postupak dodavanja novog korisnika u aplikaciju. Korisnici aplikacije mogli bi sami stvoriti nove račune ili bi aplikacija mogla ograničiti ovu aktivnost na administratore aplikacija. Specifikacija J2EE nema API ili konfiguraciju koja aplikacijama omogućuje dodavanje novih korisnika; stoga je ova vrsta sigurnosti uvijek izrađena po mjeri. J2EE nema mogućnost reći spremniku da se registrirao novi korisnik te da se njezini podaci moraju održavati i održavati tijekom njezine sesije.

Održavanje

Održavanje računa postupak je promjene podataka o računu, poput podataka o kontaktima, prijava ili lozinki. Većina aplikacija omogućuje korisnicima aplikacija, kao i administratorima, obavljanje održavanja. Specifikaciji J2EE također nedostaje API ili konfiguracija za održavanje računa. Nedostaje mehanizam za obavještavanje spremnika o promjeni korisničkih podataka.

Brisanje

Brisanje računa obično je ograničeno samo na administrativne korisnike. U rijetkim prilikama neke aplikacije mogu dopustiti korisnicima brisanje vlastitih računa. Većina aplikacija zapravo nikada ne briše korisnike; oni jednostavno deaktiviraju račun tako da se korisnik više ne može prijaviti. Čvrsto i brzo brisanje obično se mrzi jer je podatke računa puno teže obnoviti ako je potrebno. J2EE ne omogućuje uklanjanje ili deaktiviranje korisnika iz aplikacija. Nedostaje mehanizam kojim se spremniku može reći da je određeni korisnik deaktiviran ili uklonjen. J2EE također nema mehanizam za trenutnu odjavu korisnika iz aplikacije kada je njezin račun izbrisan.

Što je provjera autentičnosti spremnika?

Provjera autentičnosti kontejnera postupak je otkrivanja spremnika identitetom korisnika koji podnosi trenutni zahtjev. Za većinu spremnika ovaj postupak uključuje pridruživanje trenutnog ServletRequestobjekta, trenutne izvršne niti i interne sesije s identitetom korisnika. Povezivanjem sesije s identitetom spremnik može jamčiti da se trenutni zahtjev i svi sljedeći zahtjevi istog korisnika mogu povezati s istom sesijom, sve dok sesija tog korisnika ne istekne. Ovaj objekt sesije obično nije isto što i HttpSessionobjekt, iako se prvi koristi za stvaranje i održavanje drugog. Svaki sljedeći zahtjev istog korisnika povezan je sa sesijom pomoću prepisivanja URL-a ili kolačića sesije, prema Servlet 2.3 specifikaciji, poglavlje 7.

Kao što je gore spomenuto u našoj raspravi o autorizaciji, svaka radnja koju spremnik poduzme, kao i svaka radnja koju JRE poduzme u ime tog korisnika, pažljivo se provjerava kako bi se osiguralo da korisnik ima dopuštenje za izvršenje radnje. Da ponovimo naš prethodni primjer, kada spremnik izvršava servlet u ime korisnika, on potvrđuje da korisnik pripada skupu uloga s dodijeljenim dozvolama za izvršavanje tog servleta. JRE 1.4 također vrši ove provjere za mnoge radnje, uključujući i otvaranje datoteke ili utičnice. JRE provjera autentičnosti moćan je koncept i može osigurati da je svaki zahtjev kontejneru u biti siguran.

Trenutno J2EE nudi nekoliko različitih mehanizama za provođenje provjere autentičnosti korisnika. Uključuju provjeru autentičnosti na temelju oblika, HTTPS provjeru klijenta i osnovnu HTTP provjeru autentičnosti. JAAS je uključen kao obavezna metoda provjere autentičnosti koju spremnici moraju podržavati. No, specifikacija nije stroga o tome kako spremnik treba pružati tu funkcionalnost; stoga svaki spremnik pruža različitu potporu za JAAS. Uz to, JAAS je sam po sebi samostalni okvir za provjeru autentičnosti i mogao bi se koristiti za provedbu provjere autentičnosti spremnika bez obzira podržava li ga specifikacija. Kasnije ću detaljnije objasniti ovaj koncept.

Svaki od mehanizama provjere autentičnosti pruža standardni način davanja spremnika informacijama o korisniku. To nazivam realizacijom vjerodajnica . Spremnik i dalje mora koristiti ove podatke kako bi potvrdio da korisnik postoji i ima dozvole dovoljne za podnošenje zahtjeva. To nazivam provjerom vjerodostojnosti . Neki spremnici pružaju konfiguraciju za postavljanje provjere vjerodostojnosti, a drugi pružaju sučelja koja se moraju implementirati.

J2EE metode provjere autentičnosti

Pogledajmo ukratko neke od najčešćih metoda za implementaciju i konfiguriranje provjere autentičnosti spremnika.

Autentifikacija temeljena na obrascu

Autentifikacija temeljena na obrascu omogućuje korisnicima da se identificiraju i provjere autentičnost pomoću poslužitelja aplikacija J2EE pomoću bilo kojeg HTML obrasca. Akcija obrasca mora biti j_security_checki dva parametra HTTP zahtjeva (polja za unos obrasca) moraju uvijek biti u zahtjevu, jedan pozvan, j_usernamea drugi j_password,. Korištenjem provjere autentičnosti na temelju obrasca, realizacija vjerodajnica događa se kada se obrazac pošalje i korisničko ime i lozinka pošalju na poslužitelj.

Evo primjera JSP (JavaServer Pages) stranice koja koristi provjeru autentičnosti zasnovanu na obrascu:

 Prijava Unesite svoje korisničko ime:

Upiši svoju lozinku: