Kopš pirmās pieteikšanās lapas pievienošanas tīmekļa lietojumprogrammai drošība vienmēr ir bijusi viena no galvenajām sastāvdaļām, kas ir kritiska lietojumprogrammu panākumiem tīmeklī. Vēsturiski viss tika kodēts ar rokām. Katrai tīmekļa lietojumprogrammai bija pielāgota metode, kā autentificēt un pēc tam autorizēt lietotājus. Izstrādātāji arī iebūvēja komponentus reģistrācijai, administrēšanai un visām citām nepieciešamajām funkcijām. Lai gan šī pieeja bija diezgan maza, šī pieeja ļāva ļoti elastīgi.
Līdz ar JAAS, Java autentifikācijas un autorizācijas dienesta parādīšanos, lietojumprogrammas ieguva saskarņu kopumu un konfigurāciju, ko tās varēja izmantot, lai standartizētu šos uzdevumus. Pat pievienojot specifikācijai JAAS, J2EE joprojām ir dažas problēmas, kas jārisina, pirms lietojumprogrammu izstrādātāji var pārtraukt pielāgotu API veidošanu. Izvēloties starp J2EE standartu izmantošanu vai pielāgota risinājuma izveidi, ir jāzina katra kompromiss un, protams, jūsu lietojumprogrammas prasības.
Šī raksta mērķis ir sniegt visu nepieciešamo informāciju, lai izlemtu, vai izvēlēties pielāgoto vai konteinera drošību. Es apspriedu visizplatītākās lietojumprogrammu drošības funkcijas, lai nodrošinātu nepieciešamo drošības fonu. Pēc šīs diskusijas ir detalizēts J2EE drošības ieviešanas skaidrojums, ko nodrošina specifikācijas, kā arī visizplatītākās pielāgotās drošības ieviešanas metodes. Kad esat labāk izpratis katru no metodēm, jums vajadzētu būt pietiekami daudz informācijas, lai izvēlētos, kura metode vislabāk atbilst jūsu lietojumprogrammas prasībām.
Kas ir konteiners?
Pirms mēs apspriedīsim dažādus drošības veidus un drošības ieviešanas problēmas, pārskatīsim, kas a konteiners ir. Konteiners ir vide, kurā darbojas lietojumprogramma. Tas ir arī J2EE lietojumprogrammu servera sinonīms. Runājot par J2EE konteineriem, konteinera iekšpusē darbojas J2EE lietojumprogramma, kurai ir īpaši pienākumi attiecībā uz lietojumprogrammu. Ir daudz dažādu veidu J2EE konteineru un dažāda līmeņa J2EE atbalsts. Tomcat no Apache ir tīmekļa konteiners, kas realizē tikai J2EE specifikācijas Serversīklietnes (tīmekļa lietojumprogrammas) daļas. BEA WebLogic ir pilnībā saderīgs J2EE lietojumprogrammu serveris, kas nozīmē, ka tas atbalsta visus J2EE specifikācijas aspektus un ir izturējis Sun J2EE sertifikācijas testus. Ja neesat pārliecināts par lietojumprogrammu servera sniegto atbalstu, sazinieties ar pārdevēju, lai iegūtu vairāk informācijas.
Lietojumprogrammu drošība
Vēl viena tēma, kas mums jāapskata, pirms sākam, ir atšķirība starp lietojumprogrammu drošība un cita veida drošība. Lietojumprogrammu drošība ir drošība, ko tieši veic lietojumprogramma, vai netieši ar programmas ietvaru vai konteineru attiecībā uz šīs lietojumprogrammas lietotājiem. Lietojumprogrammas lietotāja piemērs ir kāds, kurš piesakās tiešsaistes grāmatnīcā un iegādājas dažas Java grāmatas. Pastāv arī citi drošības veidi, piemēram, tīkla drošība un JVM drošība. Viens no šiem drošības veidiem ir lietotājs, kurš mašīnā sāk Java procesu. Visā pārējā šī raksta daļā es vienmēr domāju drošības lietojumprogrammas. Pārējie drošības veidi ir ārpus šīs diskusijas darbības jomas.
Šeit galvenā uzmanība tiek pievērsta J2EE drošībai, kas ir lietojumprogrammu drošības veids, jo tā nodarbojas ar J2EE lietojumprogrammas lietotājiem (t.i., zvanītājiem). Lietotājs var būt kāds, kurš izmanto tiešsaistes grāmatnīcu vai citu lietojumprogrammu, kas izmanto grāmatnīcas lietojumprogrammas pirkšanas pakalpojumus, piemēram, cits tiešsaistes tālākpārdevējs.
Lietojumprogrammu drošības funkcijas
Apsverot lietojumprogrammu drošību, ir piecas galvenās funkcijas: autentifikācija, autorizācija, reģistrācija, konta uzturēšana (atjauninājumi) un konta dzēšana / deaktivizēšana. Lai arī lietojumprogrammai var būt tikai neliela visu iespējamo funkciju apakškopa, tās ir vissvarīgākās un diezgan standarta visām lietojumprogrammām. Mazāk formāli šīs funkcijas ir lietotāja pazīšana (autentifikācija), zināšana, ko lietotājs var darīt (autorizācija), jaunu lietotāju izveide (reģistrācija), lietotāja informācijas atjaunināšana (konta uzturēšana) un lietotāja noņemšana vai lietotājam liegta piekļuve lietojumprogrammai (konta dzēšana).
Lielākā daļa lietojumprogrammu ļauj lietotājam vai administratoram izpildīt šīs funkcijas. Kad lietotāji izpilda šīs funkcijas, viņi to dara paši. Administratori šīs funkcijas vienmēr veic citu lietotāju vārdā.
Kā tiks parādīts, visas šīs funkcijas nevar izpildīt bez pielāgota risinājuma pat autentifikācijai. Mēs īsi apskatīsim katru no tiem, lai vēl vairāk ilustrētu jēdzienus un to, kas trūkst J2EE, kas jāveido pēc pasūtījuma.
Autentifikācija
Autentifikācija ir lietotāja identificēšanas process, kas mijiedarbojas ar lietojumprogrammu. Šīs rakstīšanas laikā J2EE autentifikāciju varēja ieviest, izmantojot dažādus risinājumus, no kuriem katrs tika definēts kā daļa no J2EE specifikācijas (versija 1.0-1.4). Autentifikācija ir šīs diskusijas galvenā koncepcija, un tā tiks aplūkota sīkāk vēlāk. Ir svarīgi saprast, ka autentifikācija ir drošības funkcija, kurai ir vislielākais atbalsts J2EE specifikācijā, taču J2EE autentifikācijas (aka konteinera autentifikācijas) ieviešanai parasti ir nepieciešams pielāgots kods vai konfigurācija.
Atļauja
Autorizācija ir process, kurā tiek pārbaudīts, vai lietotājam ir atļauja veikt noteiktu darbību. J2EE aptver šo tēmu, taču tā ir ierobežota ar lomu balstītu autorizāciju, kas nozīmē, ka darbību var ierobežot, pamatojoties uz lietotājam piešķirtajām lomām. Piemēram, lietotāji pārvaldnieka lomā, iespējams, varēs izdzēst krājumus, bet lietotāji - darbinieka lomā.
Turklāt lietojumprogrammas var apsvērt divus dažādus autorizācijas veidus: Java Runtime Environment (JRE) / konteineru un lietojumprogrammu autorizāciju. JRE / konteinera autorizācija ir process, lai noteiktu, vai lietotājam, kurš iesniedz pieprasījumu, ir tiesības to darīt. JRE / konteiners to nosaka pirms jebkura koda izpildes. Piemērs ir J2EE konteiners, kuram pirms servletīles izpildīšanas vispirms jāpārbauda, vai pašreizējam lietotājam ir atļaujas izpildīt servletīklu (izmantojot resursa URL ierobežojumu). Šis atļaujas veids ir pazīstams arī kā deklaratīvā drošība jo tas ir deklarēts tīmekļa lietojumprogrammas konfigurācijas failos. Deklaratīvo drošību izpildes laikā nevar mainīt, ja vien konteiners to neatbalsta. Deklaratīvo drošību var izmantot dažādos veidos, lai autorizētu J2EE lietojumprogrammu lietotājus, taču šī tēma ir ārpus šīs diskusijas darbības jomas. (Skatiet Servlet 2.3 specifikācijas 12. nodaļu. 2. sadaļa attiecas uz deklaratīvo drošību, un 8. punkts ir labs sākumpunkts drošības ierobežojumiem.)
Kā minēts iepriekš, lietotājs var būt cita lietojumprogramma vai vienkārši lietojumprogrammas lietotājs. Katrā ziņā JRE / konteinera autorizācija tiek veikta katra pieprasījuma laikā. Šie pieprasījumi var būt HTTP pieprasījumi no pārlūkprogrammas uz Web lietojumprogrammu vai attālinātie EJB (Enterprise JavaBeans) zvani. Jebkurā gadījumā ar nosacījumu, ka JRE / konteiners pazīst lietotāju, tas var veikt autorizāciju, pamatojoties uz šī lietotāja informāciju.
Pieteikuma autorizācija ir autorizācijas process, kad programma tiek izpildīta. Lietojumprogrammu autorizāciju var tālāk sadalīt uz lomām un segmentiem balstītā autorizācijā. Uz lomu balstītas lietojumprogrammas autorizācijas piemērs ir gadījums, kad lietojumprogramma izmanto dažādus marķēšanas līmeņus, pamatojoties uz to, vai lietotājs ir darbinieks vai apmeklētājs (t.i., darbinieka atlaide). J2EE nodrošina sauktās API programmatiskā drošība lai veiktu autorizāciju, kas balstīta uz lomu (papildinformāciju skatiet Servlet 2.3 specifikācijas 12. nodaļas 3. sadaļā).
Segmentu autorizācija ir autorizācija, kuras pamatā ir citi lietotāja atribūti, piemēram, vecums vai vaļasprieki. Segmentu autorizāciju sauc par tādu, jo tā grupē lietotājus segmentos, pamatojoties uz konkrētiem atribūtiem. J2EE nav metodes, kā ieviest uz segmentiem balstītu autorizāciju. Uz segmentiem balstītas autorizācijas piemērs ir tas, vai poga uz veidlapas ir redzama lietotājiem, kas vecāki par 40 gadiem. Daži pārdevēji var piedāvāt šāda veida autorizāciju, taču tas visos gadījumos garantētu pārdevēja bloķēšanu.
Reģistrācija
Reģistrācija ir jauna lietotāja pievienošana lietojumprogrammai. Lietojumprogrammu lietotāji, iespējams, varēs izveidot sev jaunus kontus, vai arī programma var izvēlēties ierobežot šo darbību lietojumprogrammu administratoriem. J2EE specifikācijai nav API vai konfigurācijas, kas ļautu lietojumprogrammām pievienot jaunus lietotājus; tāpēc šāda veida drošība vienmēr tiek veidota pēc pasūtījuma. J2EE trūkst iespēju pateikt konteineram, kuru jauns lietotājs ir reģistrējis, un ka viņas informācija sesijas laikā ir jāsaglabā un jāuztur.
Apkope
Konta uzturēšana ir konta informācijas, piemēram, kontaktinformācijas, pieteikumvārdu vai paroļu, maiņas process. Lielākā daļa lietojumprogrammu ļauj lietojumprogrammu lietotājiem, kā arī administratoriem veikt apkopi. J2EE specifikācijā trūkst arī API vai konfigurācijas konta uzturēšanai. Trūkst mehānisma, kas informētu konteineru, ka lietotāja informācija ir mainījusies.
Dzēšana
Konta dzēšana parasti tiek ierobežota tikai administratīvajiem lietotājiem. Retos gadījumos dažas lietojumprogrammas var ļaut lietotājiem izdzēst savus kontus. Lielākā daļa lietojumprogrammu faktiski nekad neizdzēš lietotājus; viņi vienkārši deaktivizē kontu, lai lietotājs vairs nevarētu pieteikties. Veicot ātru un ātru dzēšanu, parasti tiek noraizējies, jo konta datus, ja nepieciešams, ir daudz grūtāk atjaunot. J2EE nenodrošina lietotāju noņemšanu vai deaktivizēšanu no lietojumprogrammām. Tam trūkst mehānisma, kas paziņotu konteineram, ka konkrēts lietotājs ir inaktivēts vai noņemts. J2EE trūkst arī mehānisma, kas ļautu nekavējoties pieteikties lietotājam no lietojumprogrammas, kad viņas konts ir izdzēsts.
Kas ir konteinera autentifikācija?
Konteinera autentifikācija ir process, kurā konteineram tiek paziņots tā lietotāja identitāte, kurš iesniedz pašreizējo pieprasījumu. Lielākajai daļai konteineru šis process ietver pašreizējās saistīšanu ServletLūdzība objektu, pašreizējo izpildes pavedienu un iekšējo sesiju ar lietotāja identitāti. Saistot sesiju ar identitāti, konteiners var garantēt, ka pašreizējo pieprasījumu un visus nākamos viena un tā paša lietotāja pieprasījumus var saistīt ar to pašu sesiju, līdz beidzas šī lietotāja sesijas termiņš. Šis sesijas objekts parasti nav tāds pats kā HttpSession objekts, lai gan pirmais tiek izmantots, lai izveidotu un uzturētu otro. Katrs nākamais viena un tā paša lietotāja pieprasījums ir saistīts ar sesiju, izmantojot URL pārrakstīšanu vai sesijas sīkfailu, saskaņā ar Servlet 2.3 specifikācijas 7. nodaļu.
Kā minēts iepriekš diskusijā par autorizāciju, tiek rūpīgi pārbaudītas visas konteinera veiktās darbības, kā arī visas darbības, ko JRE veic šī lietotāja vārdā, lai pārliecinātos, ka lietotājam ir atļauja veikt šo darbību. Lai atkārtotu mūsu iepriekšējo piemēru, kad konteiners lietotāja vārdā izpilda servletīklu, tas pārbauda, vai lietotājs pieder lomu kopai, kurai piešķirtas atļaujas izpildīt šo servletīklu. JRE 1.4 arī veic šīs pārbaudes daudzām darbībām, tostarp, kad tiek atvērts fails vai kontaktligzda. JRE autentifikācija ir spēcīgs jēdziens, un tas var nodrošināt, ka katrs pieprasījums konteineram ir būtībā drošs.
Pašlaik J2EE nodrošina dažus dažādus mehānismus lietotāju autentifikācijas ieviešanai. Tie ietver veidlapu autentifikāciju, HTTPS klienta autentifikāciju un HTTP pamata autentifikāciju. JAAS ir iekļauta kā obligāta autentifikācijas metode, kas konteineriem jāatbalsta. Bet specifikācija nav stingra par to, kā konteineram jānodrošina šī funkcionalitāte; tāpēc katrs konteiners nodrošina atšķirīgu atbalstu JAAS. Turklāt JAAS pati par sevi ir atsevišķa autentifikācijas sistēma, un to var izmantot, lai ieviestu konteinera autentifikāciju neatkarīgi no tā, vai specifikācija to atbalsta. Šo jēdzienu es sīkāk izskaidroju vēlāk.
Katrs no autentifikācijas mehānismiem nodrošina standarta veidu, kā konteineram sniegt informāciju par lietotāju. Es to atsaucos kā akreditācijas datu realizācija. Konteineram joprojām ir jāizmanto šī informācija, lai pārliecinātos, ka lietotājs pastāv un viņam ir pietiekamas atļaujas pieprasījuma veikšanai. Es to atsaucos kā akreditācijas datu autentifikācija. Daži konteineri nodrošina konfigurāciju, lai iestatītu akreditācijas datu autentifikāciju, un citi nodrošina saskarnes, kas jāievieš.
J2EE autentifikācijas metodes
Īsumā apskatīsim dažas no visbiežāk izmantotajām konteineru autentifikācijas ieviešanas un konfigurēšanas metodēm.
Veidlapu autentifikācija
Veidlapu autentifikācija ļauj lietotājus identificēt un autentificēt J2EE lietojumprogrammu serverī, izmantojot jebkuru HTML formu. Formas darbībai jābūt j_security_check un diviem HTTP pieprasījuma parametriem (veidlapas ievades laukiem) vienmēr jābūt pieprasījumā, vienu izsaucot j_lietotājvārds un otrs, j_parole. Izmantojot veidlapu autentifikāciju, akreditācijas datu realizācija notiek, kad veidlapa ir iesniegta un lietotājvārds un parole tiek nosūtīti serverim.
Šeit ir JSP (JavaServer Pages) lapas piemērs, kurā tiek izmantota veidlapu autentifikācija:
Pieteikšanās Ievadiet savu lietotājvārdu:Ievadiet savu paroli:
