Od prvega dodajanja strani za prijavo v spletno aplikacijo je bila varnost vedno ena ključnih komponent, ki so ključne za uspeh aplikacij v spletu. V zgodovini je bilo vse kodirano ročno. Vsaka spletna aplikacija je imela prilagojen način preverjanja pristnosti in nato pooblaščanja uporabnikov. Razvijalci so vgradili tudi komponente za registracijo, upravljanje in vse druge potrebne funkcije. Čeprav je bil ta pristop precej režijski, je omogočil veliko prilagodljivost.
S prihodom JAAS, Java Authentication and Authorization Service, so aplikacije dobile nabor vmesnikov in konfiguracijo, ki jo lahko izkoristijo za standardizacijo teh nalog. Tudi z dodajanjem JAAS v specifikacijo ima J2EE še vedno nekaj težav, ki jih je treba rešiti, preden lahko razvijalci aplikacij prenehajo ustvarjati API-je po meri. Če želite izbirati med uporabo standardov J2EE ali izdelavo rešitve po meri, morate poznati kompromise vsakega in seveda zahteve vaše aplikacije.
Cilj tega članka je zagotoviti vse informacije, potrebne za odločitev med varnostjo po meri ali vsebnikom. Govorim o najpogostejših varnostnih funkcijah aplikacij, da zagotovim potrebno ozadje varnosti. Po tej razpravi sledi podrobna razlaga varnostnih izvedb J2EE, ki jih zagotavljajo specifikacije, pa tudi najpogostejše metode izvajanja zaščite po meri. Ko boste bolje razumeli vsako od metod, morate imeti dovolj informacij, da izberete, katera metoda najbolje ustreza zahtevam vaše aplikacije.
Kaj je posoda?
Preden se pogovorimo o različnih vrstah zaščite in težavah pri izvajanju varnosti, si oglejmo, kaj a posoda je. Vsebnik je okolje, v katerem se aplikacija izvaja. Prav tako je sinonim za strežnik aplikacij J2EE. Kar zadeva vsebnike J2EE, se znotraj vsebnika izvaja aplikacija J2EE, ki ima posebne odgovornosti v zvezi z aplikacijo. Obstaja veliko različnih vrst vsebnikov J2EE in različne stopnje podpore J2EE. Tomcat iz Apacheja je spletni vsebnik, ki izvaja samo dele Servlet (spletna aplikacija) specifikacije J2EE. BEA-in WebLogic je popolnoma skladen aplikacijski strežnik J2EE, kar pomeni, da podpira vse vidike specifikacije J2EE in je opravil Sun-ove certifikacijske teste J2EE. Če niste prepričani v podporo, ki jo nudi vaš aplikacijski strežnik, se za več informacij obrnite na prodajalca.
Varnost aplikacij
Druga tema, ki jo moramo obravnavati, preden začnemo, je razlikovanje med varnost aplikacij in druge vrste varovanja. Varnost aplikacije je zaščita, ki jo neposredno izvaja aplikacija ali posredno ogrodje ali vsebnik za aplikacijo glede na uporabnike te aplikacije. Primer uporabnika aplikacije je nekdo, ki se prijavi v spletno knjigarno in kupi nekaj knjig Java. Obstajajo tudi druge vrste varnosti, kot sta omrežna in JVM. Primer teh vrst zaščite je uporabnik, ki v računalniku zažene postopek Java. V preostalem delu članka, kadar koli razpravljam o varnosti, mislim na varnost aplikacije. Druge vrste varnosti presegajo področje razprave.
Tu se osredotočamo predvsem na varnost J2EE, ki je vrsta zaščite aplikacije, ker obravnava uporabnike aplikacije J2EE (tj. Klicatelje). Uporabnik je lahko nekdo, ki uporablja spletno knjigarno ali drugo aplikacijo, ki uporablja nabavne storitve aplikacije knjigarne, na primer drug spletni prodajalec.
Varnostne funkcije aplikacij
Pri obravnavi varnosti aplikacije obstaja pet glavnih funkcij: preverjanje pristnosti, avtorizacija, registracija, vzdrževanje računa (posodobitve) in brisanje / deaktiviranje računa. Čeprav ima aplikacija le majhno podskupino vseh možnih funkcij, so te najbolj temeljne in dokaj standardne za vse aplikacije. Manj formalno so te funkcije poznavanje uporabnika (preverjanje pristnosti), vedenje, kaj lahko uporabnik naredi (avtorizacija), ustvarjanje novih uporabnikov (registracija), posodabljanje uporabniških podatkov (vzdrževanje računa) in odstranjevanje uporabnika ali preprečevanje dostopa uporabnika do aplikacije (izbris računa).
Večina aplikacij omogoča uporabniku ali skrbniku izvajanje teh funkcij. Ko uporabniki izvajajo te funkcije, to storijo sami. Skrbniki te funkcije vedno izvajajo v imenu drugih uporabnikov.
Kot bo prikazano, vseh teh funkcij ni mogoče izvesti brez rešitve po meri, niti za preverjanje pristnosti. Vsako bomo na kratko pregledali, da bomo nadalje ponazorili koncepte in kaj vse manjka J2EE, kar je treba izdelati po meri.
Preverjanje pristnosti
Preverjanje pristnosti je postopek prepoznavanja uporabnika v interakciji z aplikacijo. V času pisanja tega dokumenta je bilo mogoče overjanje J2EE izvajati z različnimi rešitvami, od katerih je vsaka opredeljena kot del specifikacije J2EE (različica 1.0-1.4). Preverjanje pristnosti je glavni koncept te razprave in bo podrobneje obravnavan kasneje. Pomembno je vedeti, da je overjanje varnostna funkcija, ki ima največ podpore v specifikaciji J2EE, vendar je za izvajanje overjanja J2EE (aka overjanje vsebnika) običajno potrebna koda ali konfiguracija po meri.
Pooblastilo
Pooblastitev je postopek preverjanja, ali ima uporabnik dovoljenje za določeno dejanje. J2EE pokriva to temo, vendar je omejena na avtorizacijo na podlagi vlog, kar pomeni, da je mogoče dejavnost omejiti na podlagi vlog, ki jih je dobil uporabnik. Uporabniki v vlogi upravitelja na primer morda lahko izbrišejo inventar, medtem ko uporabniki v vlogi zaposlenega morda ne.
Poleg tega lahko aplikacije upoštevajo dve različni vrsti avtorizacije: Java Runtime Environment (JRE) / vsebnik in odobritev aplikacije. Pooblastitev JRE / vsebnika je postopek ugotavljanja, ali ima uporabnik, ki zahteva, privilegije. JRE / vsebnik to določi pred izvajanjem katere koli kode. Primer je vsebnik J2EE, ki mora najprej preveriti, ali ima trenutni uporabnik dovoljenja za izvajanje programčka (prek omejitve URL-ja vira), preden ga izvede. Ta vrsta dovoljenja je znana tudi kot izjava o varnosti ker je navedena v konfiguracijskih datotekah za spletno aplikacijo. Deklarativne zaščite ni mogoče spreminjati med izvajanjem, razen če je vsebnik ne podpira. Izjavo o varnosti lahko uporabimo na več načinov za pooblastitev uporabnikov aplikacije J2EE, vendar ta tema presega obseg te razprave. (Glejte poglavje 12. Specifikacija Servlet 2.3. Oddelek 2 zajema deklarativno varnost, 8 pa je dobro izhodišče za varnostne omejitve.)
Kot smo že omenili, je lahko uporabnik druga aplikacija ali preprosto uporabnik aplikacije. Kakor koli, dovoljenje JRE / vsebnika se izvede med vsako zahtevo. Te zahteve so lahko zahteve HTTP iz brskalnika do spletne aplikacije ali oddaljeni klici EJB (Enterprise JavaBeans). V obeh primerih lahko pod pogojem, da JRE / vsebnik pozna uporabnika, izvede pooblastilo na podlagi podatkov tega uporabnika.
Pooblastitev aplikacije je postopek avtorizacije med izvajanjem aplikacije. Pooblastilo aplikacije lahko nadalje razdelimo na pooblastilo na podlagi vlog in na podlagi odsekov. Primer pooblastila za uporabo vloge je, ko aplikacija uporablja različne ravni označevanja glede na to, ali je uporabnik zaposleni ali obiskovalec (tj. Popust zaposlenega). J2EE ponuja imenovane API-je programska varnost za izvedbo pooblastila na podlagi vlog (za več informacij glejte poglavje 12 specifikacije Servlet 2.3, oddelek 3).
Pooblastilo na podlagi segmentov je pooblastilo, ki temelji na uporabnikovih drugih lastnostih, kot so starost ali hobiji. Pooblastilo na podlagi segmentov se imenuje tako, ker združuje uporabnike v segmente na podlagi določenih atributov. J2EE nima metode za izvajanje pooblastila na podlagi segmentov. Primer pooblastila na podlagi segmenta je, ali je gumb na obrazcu viden uporabnikom, starejšim od 40 let. Nekateri prodajalci lahko ponujajo tovrstno pooblastilo, vendar bi to zagotovilo zaklepanje prodajalca v vseh primerih.
Registracija
Registracija je postopek dodajanja novega uporabnika v aplikacijo. Uporabniki aplikacij bodo morda lahko sami ustvarili nove račune ali pa se bodo odločili, da bodo to dejavnost omejili na skrbnike aplikacij. Specifikacija J2EE nima API-ja ali konfiguracije, ki aplikacijam omogoča dodajanje novih uporabnikov; zato je ta vrsta varovanja vedno izdelana po meri. J2EE nima zmožnosti povedati vsebniku, da je registriran nov uporabnik, in da je treba med njeno sejo ohraniti in vzdrževati njene podatke.
Vzdrževanje
Vzdrževanje računa je postopek spreminjanja podatkov o računu, kot so kontaktni podatki, prijave ali gesla. Večina aplikacij uporabnikom aplikacij in skrbnikom omogoča izvajanje vzdrževanja. Specifikacija J2EE prav tako nima API-ja ali konfiguracije za vzdrževanje računa. Manjka mehanizem za obveščanje vsebnika o spremembi uporabniških podatkov.
Izbris
Brisanje računa je običajno omejeno samo na skrbniške uporabnike. V redkih primerih lahko nekatere aplikacije uporabnikom dovolijo, da izbrišejo lastne račune. Večina aplikacij dejansko nikoli ne izbriše uporabnikov; preprosto deaktivirajo račun, tako da se uporabnik ne more več prijaviti. Strogo in hitro brisanje se ponavadi namrsti, ker je podatke računa veliko težje obuditi, če je to potrebno. J2EE ne omogoča odstranjevanja ali deaktiviranja uporabnikov iz aplikacij. Manjka mehanizem, ki bi vsebniku sporočil, da je bil določen uporabnik deaktiviran ali odstranjen. J2EE tudi nima mehanizma za takojšnjo odjavo uporabnika iz aplikacije, ko je bil njen račun izbrisan.
Kaj je preverjanje pristnosti vsebnika?
Preverjanje pristnosti vsebnika je postopek, ki vsebniku pove identiteto uporabnika, ki poda trenutno zahtevo. Za večino vsebnikov ta postopek vključuje povezovanje toka ServletRequest objekt, trenutna izvedbena nit in notranja seja z identiteto uporabnika. S povezovanjem seje z identiteto lahko vsebnik zagotovi, da je trenutna zahteva in vse nadaljnje zahteve istega uporabnika lahko povezane z isto sejo, dokler seja tega uporabnika ne poteče. Ta predmet seje običajno ni enak kot HttpSession objekt, čeprav se prvi uporablja za ustvarjanje in vzdrževanje drugega. Vsaka naslednja zahteva istega uporabnika je povezana s sejo z uporabo bodisi prepisovanja URL-jev bodisi piškotka seje, v skladu s specifikacijami Servlet 2.3, poglavje 7.
Kot je bilo omenjeno zgoraj v naši razpravi o pooblastilu, so vsa dejanja, ki jih izvede vsebnik, in vsa dejanja, ki jih JRE izvede v imenu tega uporabnika, skrbno preverjena, da se zagotovi, da ima uporabnik dovoljenje za izvedbo dejanja. Da ponovimo naš prejšnji primer, ko vsebnik v imenu uporabnika izvede strežniški programček, preveri, ali uporabnik pripada naboru vlog z dovoljenji za izvajanje tega strežniškega programčka. JRE 1.4 ta preverjanja izvaja tudi za številna dejanja, tudi ko se odpre datoteka ali vtičnica. Preverjanje pristnosti JRE je močan koncept in lahko zagotovi, da je vsaka zahteva za vsebnik v bistvu varna.
Trenutno J2EE ponuja nekaj različnih mehanizmov za izvajanje preverjanja pristnosti uporabnikov. Sem spadajo preverjanje pristnosti na podlagi obrazcev, overjanje odjemalca HTTPS in osnovno preverjanje pristnosti HTTP. JAAS je vključen kot zahtevana metoda preverjanja pristnosti, ki jo morajo podpirati vsebniki. Vendar specifikacija ni stroga glede tega, kako naj vsebnik zagotavlja to funkcionalnost; zato ima vsak vsebnik različno podporo za JAAS. Poleg tega je JAAS sam po sebi samostojen okvir za preverjanje pristnosti in bi ga lahko uporabili za izvajanje preverjanja pristnosti vsebnika, ne glede na to, ali ga specifikacija podpira. Ta koncept podrobneje razložim kasneje.
Vsak od mehanizmov za preverjanje pristnosti zagotavlja standardni način posredovanja vsebnika o uporabniku. To imenujem uveljavitev poverilnic. Vsebnik mora še vedno uporabiti te informacije, da preveri, ali uporabnik obstaja in ima dovoljenja, ki zadostujejo za oddajo zahteve. To imenujem kot overitev poverilnic. Nekateri vsebniki ponujajo konfiguracijo za nastavitev overjanja poverilnic, drugi pa vmesnike, ki jih je treba implementirati.
Metode preverjanja pristnosti J2EE
Oglejmo si na kratko nekaj najpogostejših metod za izvajanje in konfiguriranje preverjanja pristnosti vsebnika.
Preverjanje pristnosti na podlagi obrazca
Preverjanje pristnosti na podlagi obrazca omogoča identifikacijo in overjanje uporabnikov s strežnikom aplikacij J2EE s katerim koli obrazcem HTML. Dejanje obrazca mora biti j_security_check in dva parametra zahteve HTTP (vnosna polja obrazca) morata biti vedno v zahtevi, pri čemer mora biti eden poklican j_username in drugi, j_password. Z uporabo preverjanja pristnosti na podlagi obrazca pride do uresničitve poverilnic, ko je obrazec oddan in uporabniško ime in geslo poslani strežniku.
Tu je primer strani JSP (JavaServer Pages), ki uporablja preverjanje pristnosti na podlagi obrazca:
Prijava Vnesite svoje uporabniško ime:Vnesite geslo:
