Ohjelmointi

J2EE-suojaus: Kontti vs. mukautettu

Ensimmäisen kerran kirjautumissivu lisättiin ensimmäistä kertaa verkkosovellukseen, joten suojaus on aina ollut yksi tärkeimmistä komponenteista verkkosovellusten menestymisen kannalta. Historiallisesti kaikki koodattiin käsin. Jokaisella verkkosovelluksella oli mukautettu menetelmä käyttäjien todentamiseksi ja sitten valtuuttamiseksi. Kehittäjät rakensivat myös komponentteja rekisteröintiä, hallintaa ja muita tarvittavia toimintoja varten. Vaikka tämä lähestymistapa oli melko pieni, se antoi paljon joustavuutta.

JAASin, Java-todennus- ja valtuutuspalvelun myötä sovellukset saivat joukon rajapintoja ja kokoonpanoa, joita ne voisivat hyödyntää näiden tehtävien standardoimiseksi. JASEE: llä on vielä muutama ratkaistavissa oleva ongelma, vaikka JAAS lisätään määritykseen, ennen kuin sovelluskehittäjät voivat lopettaa mukautettujen sovellusliittymien luomisen. J2EE-standardien käyttäminen tai mukautetun ratkaisun rakentaminen vaatii jokaisen kompromissin ja tietysti sovelluksesi vaatimusten tuntemisen.

Tämän artikkelin tarkoituksena on antaa kaikki tarvittavat tiedot, jotta voidaan päättää mukautetun tai kontin suojauksen välillä. Keskustelen yleisimmistä sovellusten suojaustoiminnoista tarvittavan tietoturvan takaamiseksi. Tämän keskustelun jälkeen on yksityiskohtainen selitys spesifikaatioiden tarjoamista J2EE-suojaustoteutuksista sekä yleisimmistä tavoista mukautetun tietoturvan toteuttamiseksi. Kun olet ymmärtänyt paremmin kaikki menetelmät, sinulla on oltava tarpeeksi tietoa, jotta voit valita, mikä menetelmä sopii parhaiten sovelluksesi vaatimuksiin.

Mikä on kontti?

Ennen kuin keskustelemme erilaisista tietoturvatyypeistä ja tietoturvan toteuttamiseen liittyvistä huolenaiheista, tarkistetaan mitä astiaan On. Säilö on ympäristö, jossa sovellus toimii. Se on myös synonyymi J2EE-sovelluspalvelimelle. J2EE-konttien osalta kontin sisällä toimii J2EE-sovellus, jolla on erityiset vastuut sovelluksesta. J2EE-kontteja on useita erilaisia ​​ja J2EE-tuki eri tasoilla. Apache-palvelun Tomcat on verkkosäiliö, joka toteuttaa vain J2EE-määrityksen Servlet (Web-sovellus) -osat. BEA: n WebLogic on täysin yhteensopiva J2EE-sovelluspalvelin, eli se tukee kaikkia J2EE-spesifikaatioiden näkökohtia ja on läpäissyt Sunin J2EE-sertifiointitestit. Jos et ole varma sovelluspalvelimesi tuesta, ota yhteyttä myyjään saadaksesi lisätietoja.

Sovelluksen turvallisuus

Toinen aihe, joka meidän on käsiteltävä ennen aloittamista, on ero niiden välillä sovelluksen turvallisuus ja muun tyyppinen turvallisuus. Sovellusturva on suojaus, jonka suoritti suoraan sovellus tai epäsuorasti sovelluksen kehys tai säilö sovelluksen käyttäjille. Esimerkki sovelluksen käyttäjästä on joku, joka kirjautuu online-kirjakauppaan ja ostaa muutaman Java-kirjan. Muita tietoturvatyyppejä on, kuten verkkoturva ja JVM-suojaus. Yksi esimerkki näistä suojaustyypeistä on käyttäjä, joka käynnistää Java-prosessin koneella. Aina kun puhun tietoturvasta, tarkoitan tämän asiakirjan loppuosassa sovellusten turvallisuutta. Muut tietoturvatyypit ulottuvat tämän keskustelun ulkopuolelle.

Tässä painopiste on erityisesti J2EE-tietoturvassa, joka on eräänlainen sovellusturva, koska se käsittelee J2EE-sovelluksen käyttäjiä (so. Soittajia). Käyttäjä voi olla joku, joka käyttää online-kirjakauppaa tai muuta sovellusta, joka käyttää kirjakauppasovelluksen ostopalveluja, kuten toinen online-jälleenmyyjä.

Sovellusten suojaustoiminnot

Sovellusten turvallisuutta tarkasteltaessa on viisi päätoimintoa: todennus, valtuutus, rekisteröinti, tilin ylläpito (päivitykset) ja tilin poistaminen / inaktivointi. Vaikka sovelluksella voi olla vain pieni osajoukko kaikista mahdollisista toiminnoista, nämä ovat kaikkein perustavanlaatuisimpia ja melko standardeja kaikille sovelluksille. Muodollisemmin nämä toiminnot ovat käyttäjän tunteminen (todennus), sen tietäminen, mitä käyttäjä voi tehdä (valtuutus), uusien käyttäjien luominen (rekisteröinti), käyttäjätietojen päivittäminen (tilin ylläpito) ja käyttäjän poistaminen tai käyttäjän estäminen pääsemästä sovellukseen (tilin poisto).

Suurin osa sovelluksista sallii käyttäjän tai järjestelmänvalvojan suorittaa nämä toiminnot. Kun käyttäjät suorittavat nämä toiminnot, he tekevät sen itse. Järjestelmänvalvojat suorittavat nämä toiminnot aina muiden käyttäjien puolesta.

Kuten havainnollistetaan, kaikkia näitä toimintoja ei voida suorittaa ilman mukautettua ratkaisua edes todennuksessa. Käymme läpi jokaisen lyhyesti valaisemaan tarkemmin käsitteitä ja mitä J2EE: stä puuttuu, mikä on räätälöitävä.

Todennus

Todennus on prosessi, jolla tunnistetaan käyttäjä, joka on vuorovaikutuksessa sovelluksen kanssa. Tämän kirjoituksen ajankohtana J2EE-todennus voitiin toteuttaa käyttämällä erilaisia ​​ratkaisuja, joista kukin määriteltiin osana J2EE-spesifikaatiota (versio 1.0-1.4). Todennus on tämän keskustelun pääkäsite, ja sitä käsitellään tarkemmin myöhemmin. On tärkeää ymmärtää, että todennus on suojaustoiminto, jolla on eniten tukea J2EE-spesifikaatioissa, mutta J2EE-todennuksen (eli konttitodennuksen) toteuttamiseksi tarvitaan yleensä mukautettua koodia tai kokoonpanoa.

Valtuutus

Valtuutus on prosessi, jolla varmistetaan, että käyttäjällä on lupa suorittaa tietty toiminto. J2EE kattaa tämän aiheen, mutta se on rajoitettu roolipohjaiseen valtuutukseen, mikä tarkoittaa, että toimintaa voidaan rajoittaa käyttäjälle annettujen roolien perusteella. Esimerkiksi johtajaroolissa olevat käyttäjät saattavat pystyä poistamaan mainosjakauman, kun taas työntekijäroolin käyttäjät eivät ehkä.

Lisäksi sovellukset saattavat harkita kahta erityyppistä valtuutusta: Java Runtime Environment (JRE) / säilö ja sovelluksen valtuutus. JRE / container-valtuutus on prosessi, jolla määritetään, onko pyynnön esittävällä käyttäjällä oikeudet tehdä niin. JRE / säilö määrittää tämän ennen koodin suorittamista. Esimerkki on J2EE-säilö, jonka on ensin tarkistettava, onko nykyisellä käyttäjällä käyttöoikeudet servlet-sovelluksen suorittamiseen (resurssin URL-rajoituksen kautta) ennen servlet-sovelluksen suorittamista. Tämän tyyppinen lupa tunnetaan myös nimellä vakuuttava vakuus koska se on ilmoitettu Web-sovelluksen määritystiedostoissa. Ilmoittavaa suojausta ei voida muuttaa ajon aikana, ellei säilö tue sitä. Vakuutettua suojausta voidaan käyttää monin tavoin J2EE-sovelluksen käyttäjien valtuuttamiseen, mutta kyseinen aihe ei kuulu tämän keskustelun piiriin. (Katso Servlet 2.3 -määrityksen luku 12. Osa 2 kattaa ilmoituksenmukaisen suojauksen, ja 8 on hyvä lähtökohta suojausrajoituksille.)

Kuten aiemmin mainittiin, käyttäjä voi olla toinen sovellus tai yksinkertaisesti sovelluksen käyttäjä. Kummassakin tapauksessa JRE / konttien valtuutus suoritetaan jokaisen pyynnön aikana. Nämä pyynnöt voivat olla HTTP-pyyntöjä selaimelta verkkosovellukseen tai EJB (Enterprise JavaBeans) -puheluita. Kummassakin tapauksessa, jos JRE / säilö tuntee käyttäjän, se voi suorittaa valtuutuksen kyseisen käyttäjän tietojen perusteella.

Sovelluksen valtuutus on prosessi, jolla valtuutetaan sovelluksen toteutuessa. Hakemuslupa voidaan edelleen jakaa roolipohjaiseen ja segmenttipohjaiseen valtuutukseen. Esimerkki roolipohjaisen sovelluksen valtuutuksesta on, kun sovellus käyttää erilaisia ​​merkintätasoja sen perusteella, onko käyttäjä työntekijä vai vierailija (ts. Työntekijän alennus). J2EE tarjoaa sovellusliittymiä kutsutaan ohjelmallinen suojaus roolipohjaisen valtuutuksen suorittamiseksi (katso lisätietoja Servlet 2.3 -määrityksen luvun 12 osasta 3).

Segmenttiin perustuva valtuutus on käyttäjän muihin ominaisuuksiin, kuten ikään tai harrastuksiin, perustuva valtuutus. Segmenttipohjaista valtuutusta kutsutaan sellaiseksi, koska se ryhmitellä käyttäjät segmentteihin tiettyjen ominaisuuksien perusteella. J2EE: llä ei ole menetelmää segmenttipohjaisen valtuutuksen toteuttamiseksi. Esimerkki segmenttipohjaisesta valtuutuksesta on, näkyykö lomakkeen painike yli 40-vuotiaille käyttäjille. Tietyt myyjät voivat tarjota tämän tyyppistä valtuutusta, mutta se takaa toimittajan lukituksen kaikissa tapauksissa.

Rekisteröinti

Rekisteröinti on uuden käyttäjän lisääminen sovellukseen. Sovelluksen käyttäjät saattavat pystyä luomaan itselleen uusia tilejä tai sovellus voi rajoittaa tämän toiminnan sovellusten järjestelmänvalvojille. J2EE-määrityksessä ei ole sovellusliittymää tai kokoonpanoa, joka sallisi sovellusten lisätä uusia käyttäjiä. siksi tämän tyyppinen suojaus on aina räätälöity. J2EE: llä ei ole kykyä kertoa säilölle, jonka uusi käyttäjä on rekisteröitynyt, ja että hänen tietojaan on säilytettävä ja ylläpidettävä istunnon aikana.

Huolto

Tilin ylläpito on tilitietojen, kuten yhteystietojen, kirjautumistunnusten tai salasanojen, muuttaminen. Suurin osa sovelluksista antaa sovellusten käyttäjille ja järjestelmänvalvojille mahdollisuuden suorittaa ylläpitoa. J2EE-määrityksestä puuttuu myös sovellusliittymä tai kokoonpano tilin ylläpitoa varten. Mekanismi puuttuu, jotta kontille voidaan ilmoittaa, että käyttäjätiedot ovat muuttuneet.

Poistaminen

Tilin poistaminen on yleensä rajoitettu vain järjestelmänvalvojille. Harvinaisissa tapauksissa jotkin sovellukset voivat sallia käyttäjien poistaa omat tilinsä. Suurin osa sovelluksista ei koskaan poista käyttäjiä; ne yksinkertaisesti inaktivoivat tilin, jotta käyttäjä ei voi enää kirjautua sisään. Kovien ja nopeiden poistojen tekeminen on yleensä paheksuttavaa, koska tilitietoja on paljon vaikeampaa herättää tarvittaessa. J2EE ei tarjoa tapaa poistaa tai inaktivoida käyttäjiä sovelluksista. Siinä ei ole mekanismia kertoa säiliölle, että tietty käyttäjä on inaktivoitu tai poistettu. J2EE: stä puuttuu myös mekanismi, jolla käyttäjä kirjataan heti ulos sovelluksesta, kun hänen tilinsä on poistettu.

Mikä on säilön todennus?

Säiliön todennus on prosessi, jossa kerrotaan säilölle nykyisen pyynnön esittävän käyttäjän henkilöllisyys. Useimpien säiliöiden osalta tämä prosessi edellyttää virran liittämistä ServletPyyntö objekti, nykyinen suorituslanka ja sisäinen istunto käyttäjän henkilöllisyydellä. Yhdistämällä istunnon identiteettiin säilö voi taata, että saman käyttäjän nykyinen pyyntö ja kaikki seuraavat pyynnöt voidaan liittää samaan istuntoon, kunnes kyseisen käyttäjän istunto päättyy. Tämä istuntoobjekti ei yleensä ole sama kuin HttpSession vaikka ensimmäistä käytetään jälkimmäisen luomiseen ja ylläpitoon. Jokainen saman käyttäjän seuraava pyyntö liitetään istuntoon joko URL: n uudelleenkirjoituksella tai istuntoevästeellä Servlet 2.3 -määrityksen luvun 7 mukaisesti.

Kuten yllä olevassa valtuutuskeskustelussamme mainittiin, kaikki säilön tekemät toiminnot sekä kaikki JRE: n kyseisen käyttäjän puolesta suorittamat toiminnot tarkistetaan huolellisesti sen varmistamiseksi, että käyttäjällä on lupa suorittaa toiminto. Toistaaksemme edellisen esimerkkimme, kun säilö suorittaa palvelinsovelluksen käyttäjän puolesta, se tarkistaa, että käyttäjä kuuluu rooleihin, joille on annettu lupa suorittaa kyseinen palvelinsovellus. JRE 1.4 suorittaa myös nämä tarkistukset monille toiminnoille, myös silloin, kun tiedosto tai socket avautuu. JRE-todennus on tehokas käsite, ja se voi varmistaa, että jokainen pyyntö säilölle on olennaisesti turvallista.

Tällä hetkellä J2EE tarjoaa muutamia erilaisia ​​mekanismeja käyttäjien todennuksen toteuttamiseksi. Näitä ovat lomakepohjainen todennus, HTTPS-asiakkaan todennus ja HTTP-perustodennus. JAAS sisältyy pakolliseen todennustapaan, jota säilöjen on tuettava. Mutta määrittely ei ole tiukka siitä, miten säiliön tulisi tarjota tämä toiminto; siksi jokainen kontti tarjoaa erilaisen tuen JAAS: lle. Lisäksi JAAS itsessään on itsenäinen todennuskehys, ja sitä voidaan käyttää säilön todennuksen toteuttamiseen riippumatta siitä, tukeeko määritys sitä. Selitän tämän käsitteen yksityiskohtaisemmin myöhemmin.

Jokainen todennusmekanismi tarjoaa tavanomaisen tavan antaa kontille tietoa käyttäjästä. Viittaan tähän tunnistetiedot. Säilön on edelleen käytettävä näitä tietoja varmistaakseen, että käyttäjä on olemassa ja että hänellä on riittävät oikeudet pyynnön tekemiseen. Viittaan siihen tunnistetiedot. Jotkut säilöt tarjoavat kokoonpanon tunnistetietojen todennuksen määrittämiseksi ja toiset tarjoavat käyttöliittymiä, jotka on toteutettava.

J2EE-todennustavat

Tarkastellaan lyhyesti joitain yleisimpiä tapoja säilön todennuksen toteuttamiseksi ja määrittämiseksi.

Lomakepohjainen todennus

Lomakepohjaisen todennuksen avulla käyttäjät voidaan tunnistaa ja todentaa J2EE-sovelluspalvelimella millä tahansa HTML-lomakkeella. Lomaketoiminnan on oltava j_turvallisuuden_tarkistus ja kahden HTTP-pyynnön parametrin (lomakkeen syöttökentät) on aina oltava pyynnössä, yksi kutsutaan j_käyttäjänimi ja se toinen, j_salasana. Lomakepohjaista todennusta käyttämällä tunnistetiedot toteutetaan, kun lomake lähetetään ja käyttäjänimi ja salasana lähetetään palvelimelle.

Tässä on esimerkki JSP (JavaServer Pages) -sivusta, joka käyttää lomakepohjaista todennusta:

 Kirjaudu sisään Anna käyttäjänimesi:

Syötä salasanasi:

$config[zx-auto] not found$config[zx-overlay] not found