JavaRush /Java blogi /Random-UZ /JAAS - Texnologiyaga kirish (1-qism)

Daraja

28 February 2021
39 views
0 comments

JAAS - Texnologiyaga kirish (1-qism)

Kirish xavfsizligi Java-da ancha vaqtdan beri joriy qilingan va ushbu xavfsizlikni ta'minlash arxitekturasi JAAS - Java autentifikatsiya va avtorizatsiya xizmati deb ataladi. Ushbu sharh autentifikatsiya, avtorizatsiya nima va JAASning bunga nima aloqasi borligi sirini ochishga harakat qiladi. JAAS qanday qilib Servlet API bilan do'st va ularning munosabatlarida qayerda muammolar bor.

Kirish

Ushbu sharhda men veb-ilovalar xavfsizligi kabi mavzuni muhokama qilmoqchiman. Java-da xavfsizlikni ta'minlaydigan bir nechta texnologiyalar mavjud:

" Java SE platformasi xavfsizlik arxitekturasi ", bu haqda batafsil ma'lumotni Oracle qo'llanmasida o'qishingiz mumkin: " JavaTM SE platformasi xavfsizlik arxitekturasi ". Ushbu arxitektura Java SE ish vaqti muhitida Java ilovalarimizni qanday himoyalashimiz kerakligini tasvirlaydi. Ammo bugungi suhbatimiz mavzusi bu emas.
" Java kriptografiya arxitekturasi " bu ma'lumotlarni shifrlashni tavsiflovchi Java kengaytmasi. JavaRush-da ushbu kengaytma haqida ko'proq ma'lumotni " Java kriptografiyasi arxitekturasi: Birinchi tanishuv " sharhida yoki Oracle qo'llanmasida o'qishingiz mumkin: " Java Kriptografiya Arxitekturasi (JCA) Reference Guide ".

Ammo bugungi suhbatimiz "Java Autentifikatsiya va Avtorizatsiya Xizmati (JAAS)" deb nomlangan boshqa texnologiya haqida bo'ladi. Aynan u autentifikatsiya va avtorizatsiya kabi muhim narsalarni tasvirlaydi. Keling, buni batafsil ko'rib chiqaylik.

JAAS

JAAS Java SE ning kengaytmasi boʻlib, Java autentifikatsiya va avtorizatsiya xizmati (JAAS) Yoʻriqnomasida tasvirlangan . Texnologiya nomidan ko'rinib turibdiki, JAAS autentifikatsiya va avtorizatsiya qanday amalga oshirilishi kerakligini tasvirlaydi:

" Autentifikatsiya ": yunon tilidan tarjima qilingan "authentikos" "haqiqiy, haqiqiy" degan ma'noni anglatadi. Ya'ni, autentifikatsiya - bu haqiqiylik sinovi. Autentifikatsiya qilinayotgan har bir kishi haqiqatan ham ular aytganidek.
" Authorization ": ingliz tilidan tarjima qilinganda "ruxsat" degan ma'noni anglatadi. Ya'ni avtorizatsiya muvaffaqiyatli autentifikatsiyadan so'ng amalga oshiriladigan kirishni boshqarishdir.

Ya'ni, JAAS resursga kim kirishni so'raganini aniqlash va u ushbu ruxsatni olishi mumkinligi to'g'risida qaror qabul qilish bilan bog'liq. Hayotdan kichik o'xshashlik: siz yo'lda ketyapsiz va sizni inspektor to'xtatdi. Iltimos, hujjatlarni taqdim eting - autentifikatsiya. Hujjatlar bilan mashina haydash mumkinmi - avtorizatsiya. Yoki, masalan, siz do'konda spirtli ichimliklar sotib olmoqchisiz. Birinchidan, sizdan pasport so'raladi - autentifikatsiya. Keyinchalik, yoshingizdan kelib chiqib, spirtli ichimliklarni sotib olish huquqiga ega ekanligingiz hal qilinadi. Bu avtorizatsiya. Veb-ilovalarda foydalanuvchi sifatida tizimga kirish (foydalanuvchi nomi va parolni kiritish) autentifikatsiya hisoblanadi. Va qaysi sahifalarni ochishingiz mumkinligini aniqlash avtorizatsiya bilan belgilanadi. Bu erda "Java autentifikatsiya va avtorizatsiya xizmati (JAAS)" bizga yordam beradi. JAASni ko'rib chiqayotganda, JAAS ta'riflaydigan bir nechta asosiy tushunchalarni tushunish muhimdir: Mavzu, Asosiylar, Hisob ma'lumotlari. Mavzu autentifikatsiya predmeti hisoblanadi. Ya'ni, u huquqlarning egasi yoki egasidir. Hujjatlarda Mavzu ba'zi harakatlarni bajarish uchun so'rovning manbai sifatida belgilanadi. Mavzu yoki manba qandaydir tarzda tasvirlangan bo'lishi kerak va buning uchun Principal ishlatiladi, rus tilida uni ba'zan asosiy deb ham atashadi. Ya'ni, har bir Direktor ma'lum bir nuqtai nazardan Mavzuning vakilidir. Aniqroq bo'lishi uchun misol keltiramiz: Muayyan shaxs - bu sub'ekt. Va quyidagilar direktor sifatida harakat qilishi mumkin:

uning haydovchilik guvohnomasi yo'l harakati ishtirokchisi sifatida shaxsning vakili sifatida
uning pasporti, o'z mamlakatining fuqarosi sifatida shaxsning vakili sifatida
uning chet el pasporti, xalqaro munosabatlar ishtirokchisi sifatida shaxsning vakili sifatida
kutubxonadagi uning kutubxona kartasi, kutubxonaga biriktirilgan o'quvchi sifatida shaxsning vakili sifatida

Bundan tashqari, Subject-da ingliz tilida "identifikatsiya" degan ma'noni anglatuvchi "Ishonch ma'lumotlari" to'plami mavjud. Sub'ekt o'zining o'zi ekanligini shu tarzda tasdiqlaydi. Masalan, foydalanuvchi paroli Hisob ma'lumotlari bo'lishi mumkin. Yoki foydalanuvchi haqiqatan ham u ekanligini tasdiqlashi mumkin bo'lgan har qanday ob'ekt. Keling, veb-ilovalarda JAAS qanday qo'llanilishini ko'rib chiqaylik.

JAAS - Texnologiyaga kirish (1-qism) - 3

Veb ilova

Shunday qilib, bizga veb-ilova kerak. Gradle avtomatik loyiha qurish tizimi uni yaratishda bizga yordam beradi. Gradle-dan foydalanish tufayli biz kichik buyruqlarni bajarish orqali Java loyihasini o'zimizga kerakli formatda yig'ishimiz, avtomatik ravishda kerakli katalog tuzilmasini yaratishimiz va boshqalar. Siz Gradle haqida ko'proq ma'lumotni qisqacha sharhda o'qishingiz mumkin: " Gradle haqida qisqacha kirish " yoki " Gradle Ishga kirishish " rasmiy hujjatlarida . Biz loyihani ishga tushirishimiz kerak (Initialization) va buning uchun Gradle-da maxsus plagin mavjud: “ Gradle Init Plugin ” (Init Initialization uchun qisqa, eslab qolish oson). Ushbu plagindan foydalanish uchun buyruq satrida buyruqni bajaring:

gradle init --type java-application

Muvaffaqiyatli tugagandan so'ng, bizda Java loyihasi bo'ladi. Endi tahrir qilish uchun loyihamizning qurish skriptini ochamiz. build.gradleQurilish skripti - bu dastur tuzishning nuanslarini tavsiflovchi fayl . Shuning uchun nom, skript yaratish. Aytishimiz mumkinki, bu loyihani yaratish skripti. Gradle - bu juda ko'p qirrali vosita bo'lib, uning asosiy imkoniyatlari plaginlar bilan kengaytirilgan. Shuning uchun, birinchi navbatda, "plaginlar" blokiga e'tibor qarataylik:

plugins {
    id 'java'
    id 'application'
}

Odatiy bo'lib, Gradle biz ko'rsatgan " "ga muvofiq --type java-application, ba'zi asosiy plaginlar to'plamini o'rnatdi, ya'ni Gradle-ning tarqatilishiga kiritilgan plaginlar. Agar siz gradle.org veb- saytidagi "Hujjatlar" (ya'ni hujjatlar) bo'limiga kirsangiz , u holda "Ma'lumotnoma" bo'limidagi mavzular ro'yxatining chap tomonida biz " Asosiy plaginlar " bo'limini ko'ramiz, ya'ni. ushbu juda asosiy plaginlarning tavsifi bilan bo'lim. Keling, Gradle biz uchun yaratgan plaginlarni emas, balki bizga kerakli plaginlarni tanlaylik. Hujjatlarga ko'ra, " Gradle Java Plugin " Java kodi bilan asosiy operatsiyalarni, masalan, manba kodini kompilyatsiya qilishni ta'minlaydi. Shuningdek, hujjatlarga ko'ra, " Gradle ilovasi plagini "bizni "bajariladigan JVM ilovasi" bilan ishlash uchun vositalar bilan ta'minlaydi, ya'ni. mustaqil dastur sifatida ishga tushirilishi mumkin bo'lgan java ilovasi bilan (masalan, konsol ilovasi yoki o'z foydalanuvchi interfeysiga ega ilova). Ma'lum bo'lishicha, bizga "ilova" plagini kerak emas, chunki... bizga mustaqil dastur kerak emas, bizga veb-ilova kerak. Keling, uni o'chirib tashlaymiz. Shuningdek, faqat ushbu plaginga ma'lum bo'lgan "mainClassName" sozlamasi. Bundan tashqari, Ilova plaginining hujjatlariga havola berilgan " Qadoqlash va tarqatish " bo'limida Gradle War plaginiga havola mavjud. Hujjatlarda aytilganidek, Gradle War Plugin Java veb-ilovalarini urush formatida yaratishni qo'llab-quvvatlaydi. WAR formatida JAR arxivi o'rniga WAR arxivi yaratiladi. Bu bizga kerak bo'lgan narsaga o'xshaydi. Shuningdek, hujjatlarda aytilganidek, "Urush plagini Java plaginini kengaytiradi". Ya'ni, java plaginini urush plaginiga almashtirishimiz mumkin. Shunday qilib, bizning plagin blokimiz oxir-oqibat shunday ko'rinadi:

plugins {
    id 'war'
}

Shuningdek, "Gradle War Plugin" hujjatlarida plagin qo'shimcha "Loyiha tartibi" dan foydalanishi aytilgan. Layout ingliz tilidan joylashuv deb tarjima qilingan. Ya'ni, urush plagini sukut bo'yicha o'z vazifalari uchun foydalanadigan fayllarning ma'lum bir joylashuvi mavjudligini kutadi. U veb-ilova fayllarini saqlash uchun quyidagi katalogdan foydalanadi: src/main/webapp Plaginning harakati quyidagicha tasvirlangan:

JAAS - Texnologiyaga kirish (1-qism) - 4

Ya'ni, plagin veb-ilovamizning WAR arxivini yaratishda ushbu joydan fayllarni hisobga oladi. Bundan tashqari, Gradle War Plugin hujjatlarida aytilishicha, ushbu katalog "arxivning ildizi" bo'ladi. Va allaqachon unda biz WEB-INF katalogini yaratishimiz va u erga web.xml faylini qo'shishimiz mumkin. Bu qanday fayl? web.xml- bu "Tartibga solish identifikatori" yoki "tarqatish deskriptori". Bu veb-ilovani ishlash uchun qanday sozlashni tavsiflovchi fayl. Ushbu fayl ilovamiz qanday so'rovlarni bajarishini, xavfsizlik sozlamalarini va boshqa ko'p narsalarni belgilaydi. Asosan, u JAR faylidagi manifest faylga biroz o'xshaydi (qarang: " Manifest fayllari bilan ishlash: Asoslar "). Manifest fayli Java ilovasi (yaʼni JAR arxivi) bilan qanday ishlashni, web.xml esa Java veb-ilovasi (yaʼni WAR arxivi) bilan qanday ishlashni aytadi. "O'rnatish deskriptori" tushunchasi o'z-o'zidan paydo bo'lmagan, ammo " Servlet API spetsifikatsiyasi" hujjatida tasvirlangan.". Har qanday Java veb-ilovasi ushbu "Servlet API" ga bog'liq. Bu API ekanligini tushunish muhimdir - ya'ni bu ba'zi o'zaro ta'sir shartnomasining tavsifi. Veb-ilovalar mustaqil ilovalar emas. Ular veb-serverda ishlaydi. , bu foydalanuvchilar bilan tarmoq aloqasini ta'minlaydi.Ya'ni veb-server veb-ilovalar uchun o'ziga xos "konteyner"dir.Bu mantiqan to'g'ri, chunki biz veb-ilovaning mantiqini yozmoqchimiz, ya'ni foydalanuvchi qanday sahifalarni ko'radi va qanday qilib ular foydalanuvchining harakatlariga munosabat bildirishlari kerak.Va biz foydalanuvchiga xabar qanday yuborilishi, axborot baytlari qanday uzatilishi va boshqa past darajadagi va juda sifat talab qiladigan narsalar haqida kod yozishni istamaymiz.Bundan tashqari, ma'lum bo'lishicha, veb-ilovalar barchasi har xil, lekin ma'lumotlarni uzatish bir xil.Ya'ni, million dasturchilar bir xil maqsad uchun kodni qayta-qayta yozishga to'g'ri keladi.Demak, veb-server foydalanuvchilarning ba'zi o'zaro ta'siri uchun javobgardir. va ma'lumotlar almashinuvi va veb-ilova va ishlab chiquvchi ushbu ma'lumotlarni yaratish uchun javobgardir. Va bu ikki qismni ulash uchun, ya'ni. veb-server va veb-ilova, ularning o'zaro ta'siri uchun sizga shartnoma kerak, ya'ni. Buning uchun ular qanday qoidalarga amal qilishadi? Shartnomani qandaydir tarzda tasvirlash uchun veb-ilova va veb-server o'rtasidagi o'zaro ta'sir qanday bo'lishi kerak, Servlet API ixtiro qilingan. Qizig'i shundaki, siz Spring kabi ramkalardan foydalansangiz ham, kaput ostida ishlaydigan Servlet API mavjud. Ya'ni, siz Spring dan foydalanasiz va Spring siz uchun Servlet API bilan ishlaydi. Ma'lum bo'lishicha, bizning veb-ilova loyihamiz Servlet API-ga bog'liq bo'lishi kerak. Bunday holda, Servlet API qaramlik bo'ladi. Ma'lumki, Gradle sizga loyihaga bog'liqliklarni deklarativ tarzda tasvirlashga ham imkon beradi. Plaginlar bog'liqliklarni qanday boshqarish mumkinligini tasvirlaydi. Misol uchun, Java Gradle Plugin "testImplementation" bog'liqligini boshqarish usulini taqdim etadi, unda bunday qaramlik faqat testlar uchun zarurligini aytadi. Ammo Gradle War plaginiga "providedCompile" qaramlikni boshqarish usuli qo'shiladi, unda bunday qaramlik bizning veb-ilovamizning WAR arxiviga kiritilmaydi. Nega biz Servlet API-ni WAR arxivimizga kiritmaymiz? Chunki Servlet API veb-ilovamizga veb-serverning o'zi tomonidan taqdim etiladi. Agar veb-server Servlet API-ni taqdim etsa, u holda server servlet konteyneri deb ataladi. Shu sababli, bizni Servlet API bilan ta'minlash veb-serverning mas'uliyati va ServletAPI-ni faqat kod tuzilgan vaqtda taqdim etish bizning javobgarligimizdir. Shunung uchun providedCompile. Shunday qilib, bog'liqliklar bloki quyidagicha ko'rinadi:

dependencies {
    providedCompile 'javax.servlet:javax.servlet-api:3.1.0'
    testImplementation 'junit:junit:4.12'
}

Shunday qilib, web.xml fayliga qaytaylik. Odatiy bo'lib, Gradle hech qanday Deployment Descriptor yaratmaydi, shuning uchun biz buni o'zimiz qilishimiz kerak. Keling, katalog yaratamiz src/main/webapp/WEB-INFva unda biz XML faylini yaratamiz web.xml. Endi “Java Servlet Spetsifikatsiyasi”ning o‘zini va “ 14-BOB O‘rnatish deskriptori ” bo‘limini ochamiz . “14.3 Deployment Descriptor”da aytilganidek, Deployment Deskriptorning XML hujjati http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd sxemasi bilan tavsiflanadi . XML sxemasi hujjat qanday elementlardan iborat bo'lishi va ular qanday tartibda paydo bo'lishi kerakligini tavsiflaydi. Qaysi biri majburiy va qaysi biri shart emas. Umuman olganda, u hujjatning tuzilishini tavsiflaydi va XML hujjati to'g'ri tuzilgan yoki yo'qligini tekshirish imkonini beradi. Keling, " 14.5 Misollar " bobidagi misoldan foydalanamiz , lekin sxema 3.1 versiyasi uchun ko'rsatilishi kerak, ya'ni.

http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd

Bizning bo'sh joyimiz web.xmlquyidagicha ko'rinadi:

<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
         http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
         version="3.1">
    <display-name>JAAS Example</display-name>
</web-app>

Keling, JAAS yordamida himoya qiladigan servletni tasvirlab beraylik. Ilgari Gradle biz uchun App sinfini yaratgan. Keling, uni servletga aylantiramiz. " 2-BOB Servlet interfeysi " spetsifikatsiyasida ta'kidlanganidek , " Ko'pgina maqsadlarda dasturchilar o'zlarining servletlarini amalga oshirish uchun HttpServlet-ni kengaytiradilar ", ya'ni sinfni servlet qilish uchun siz ushbu sinfni dan meros qilib olishingiz kerak HttpServlet:

public class App extends HttpServlet {
	public String getGreeting() {
        return "Secret!";
    }
    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        response.getWriter().print(getGreeting());
    }
}

Aytganimizdek, Servlet API server va veb-ilovamiz o'rtasidagi shartnomadir. Ushbu shartnoma foydalanuvchi server bilan bog'langanda, server foydalanuvchidan ob'ekt ko'rinishidagi so'rovni yaratishi HttpServletRequestva uni servletga o'tkazishini tasvirlash imkonini beradi. Shuningdek, u servletni ob'ekt bilan ta'minlaydi HttpServletResponse, shunda servlet foydalanuvchi uchun unga javob yozishi mumkin. Servlet ishlashni tugatgandan so'ng, server foydalanuvchiga unga asoslangan javobni taqdim etishi mumkin bo'ladi HttpServletResponse. Ya'ni, servlet foydalanuvchi bilan bevosita bog'lanmaydi, faqat server bilan. Server bizda servlet borligini va undan qanday so'rovlar uchun foydalanish kerakligini bilishi uchun biz bu haqda serverga joylashtirish deskriptorida aytib berishimiz kerak:

<servlet>
	<servlet-name>app</servlet-name>
	<servlet-class>jaas.App</servlet-class>
</servlet>
<servlet-mapping>
	<servlet-name>app</servlet-name>
	<url-pattern>/secret</url-pattern>
</servlet-mapping>

Bunday holda, barcha so'rovlar sinfga mos keladigan /secretnom bilan bizning bitta servletimizga yuborilmaydi . Yuqorida aytib o'tganimizdek, veb-ilovani faqat veb-serverda joylashtirish mumkin. Veb-server alohida o'rnatilishi mumkin (mustaqil). Ammo ushbu ko'rib chiqish maqsadlari uchun muqobil variant mos keladi - o'rnatilgan serverda ishlash. Bu shuni anglatadiki, server dasturiy ravishda yaratiladi va ishga tushiriladi (plagin biz uchun buni qiladi) va shu bilan birga bizning veb-ilovamiz unga joylashtiriladi. Gradle qurish tizimi " Gradle Gretty Plugin " plaginidan quyidagi maqsadlarda foydalanish imkonini beradi :appjaas.App

plugins {
    id 'war'
    id 'org.gretty' version '2.2.0'
}

Bundan tashqari, Gretty plaginida yaxshi hujjatlar mavjud . Keling, Gretty plagini turli veb-serverlar o'rtasida almashish imkonini berishidan boshlaylik. Bu hujjatlarda batafsilroq tasvirlangan: " Servlet konteynerlari o'rtasida almashish ". Keling, Tomcat-ga o'tamiz, chunki ... u foydalanishdagi eng mashhurlaridan biri bo'lib, shuningdek, yaxshi hujjatlar va ko'plab misollar va tahlil qilingan muammolarga ega:

gretty {
    // Переключаемся с дефолтного Jetty на Tomcat
    servletContainer = 'tomcat8'
    // Укажем Context Path, он же Context Root
    contextPath = '/jaas'
}

Endi biz "gradle appRun" ni ishga tushirishimiz mumkin va keyin bizning veb-ilovamiz http://localhost:8080/jaas/secret manzilida mavjud bo'ladi.

JAAS - Texnologiyaga kirish (1-qism) - 5

Servlet konteyneri Tomcat tomonidan tanlanganligini tekshirish muhim (qarang: №1) va bizning veb-ilovamiz qaysi manzilda mavjudligini tekshiring (№2 ga qarang).

JAAS - Texnologiyaga kirish (1-qism) - 6

Autentifikatsiya

Autentifikatsiya sozlamalari odatda ikkita qismdan iborat: server tomonidagi sozlamalar va ushbu serverda ishlaydigan veb-ilova tomonidagi sozlamalar. Veb-ilovaning xavfsizlik sozlamalari veb-serverning xavfsizlik sozlamalari bilan o'zaro ta'sir qilishi mumkin, agar boshqa sabablarga ko'ra veb-ilova veb-server bilan o'zaro ta'sir qila olmasa. Tomcat-ga o'tganimiz bejiz emas edi, chunki... Tomcat yaxshi tavsiflangan arxitekturaga ega (qarang: " Apache Tomcat 8 Architecture "). Ushbu arxitektura tavsifidan ko'rinib turibdiki, Tomcat veb-server sifatida veb-ilovani " Tomcat Context " deb nomlangan ma'lum bir kontekst sifatida ifodalaydi. Ushbu kontekst har bir veb-ilovaga boshqa veb-ilovalardan ajratilgan o'z sozlamalariga ega bo'lish imkonini beradi. Bundan tashqari, veb-ilova ushbu kontekst sozlamalariga ta'sir qilishi mumkin. Moslashuvchan va qulay. Chuqurroq tushunish uchun " Tomcat kontekstli konteynerlarni tushunish " maqolasini va Tomcat hujjatlari bo'limini " Kontekst konteyneri " ni o'qishni tavsiya etamiz. Yuqorida aytib o'tilganidek, bizning veb-ilovamiz ilovamizning Tomcat kontekstiga /META-INF/context.xml. Va biz ta'sir qilishimiz mumkin bo'lgan eng muhim sozlamalardan biri bu xavfsizlik sohalari. Xavfsizlik sohalari o'ziga xos "xavfsizlik sohasi" dir. Muayyan xavfsizlik sozlamalari ko'rsatilgan hudud. Shunga ko'ra, Xavfsizlik sohasidan foydalanganda biz ushbu hudud uchun belgilangan xavfsizlik sozlamalarini qo'llaymiz. Xavfsizlik sohalari konteyner tomonidan boshqariladi, ya'ni. bizning veb-ilovamiz emas, balki veb-server. Biz faqat serverga ilovamizga qaysi xavfsizlik doirasini kengaytirish kerakligini ayta olamiz. Tomcat hujjatlarining " Realm komponenti " bo'limida Realm foydalanuvchilar va ularning autentifikatsiyani amalga oshirishdagi rollari haqidagi ma'lumotlar to'plami sifatida tasvirlangan. Tomcat turli xil Security Realm ilovalari to'plamini taqdim etadi, ulardan biri " Jaas Realm ". Bir oz terminologiyani tushunib, fayldagi Tomcat kontekstini tavsiflaymiz /META-INF/context.xml:

<?xml version="1.0" encoding="UTF-8"?>
<Context>
    <Realm className="org.apache.catalina.realm.JAASRealm"
           appName="JaasLogin"
           userClassNames="jaas.login.UserPrincipal"
           roleClassNames="jaas.login.RolePrincipal"
           configFile="jaas.config" />
</Context>

appName- ilova nomi. Tomcat ushbu nomni configFile. configFile- bu "kirish konfiguratsiya fayli". Bunga misol JAAS hujjatlarida ko'rish mumkin: " Ilova B: Kirish konfiguratsiyasiga misol ". Bunga qo'shimcha ravishda, ushbu fayl birinchi navbatda resurslardan qidirilishi muhimdir. Shuning uchun bizning veb-ilovamiz ushbu faylni o'zi taqdim etishi mumkin. Atributlar userClassNamesva roleClassNamesfoydalanuvchi printsipini ifodalovchi sinflar ko'rsatkichini o'z ichiga oladi. JAAS "foydalanuvchi" va "rol" tushunchalarini ikki xil tushuncha sifatida ajratadi java.security.Principal. Keling, yuqoridagi sinflarni tavsiflaymiz. Keling, foydalanuvchi direktori uchun eng oddiy dasturni yarataylik:

public class UserPrincipal implements Principal {
    private String name;
    public UserPrincipal(String name) {
        this.name = name;
    }
    @Override
    public String getName() {
        return name;
    }
}

Biz uchun aynan bir xil amalni takrorlaymiz RolePrincipal. Interfeysdan ko'rinib turibdiki, Direktor uchun asosiy narsa direktorni ifodalovchi ba'zi nomni (yoki identifikatorni) saqlash va qaytarishdir. Endi bizda Xavfsizlik sohasi bor, asosiy sinflarimiz bor. Faylni " configFile" atributidan to'ldirish qoladi, aka login configuration file. Uning tavsifini Tomcat hujjatlarida topish mumkin: " Realm komponenti ".

JAAS - Texnologiyaga kirish (1-qism) - 7

Ya'ni, biz JAAS Login Config sozlamalarini veb-ilovamiz resurslariga joylashtirishimiz mumkin va Tomcat Context tufayli biz undan foydalana olamiz. Ushbu fayl ClassLoader uchun resurs sifatida mavjud bo'lishi kerak, shuning uchun uning yo'li quyidagicha bo'lishi kerak: \src\main\resources\jaas.config Keling, ushbu faylning mazmunini o'rnatamiz:

JaasLogin {
    jaas.login.JaasLoginModule required debug=true;
};

Shunisi e'tiborga loyiqki, context.xmlbir xil nom bu erda va ichida ishlatiladi. Bu Xavfsizlik sohasini LoginModule bilan taqqoslaydi. Shunday qilib, Tomcat Context bizga qaysi sinflar asosiylarni ifodalashini, shuningdek, qaysi LoginModule-dan foydalanishni aytdi. Biz qilishimiz kerak bo'lgan yagona narsa ushbu LoginModule-ni amalga oshirishdir. LoginModule , ehtimol JAAS-dagi eng qiziqarli narsalardan biridir. Rasmiy hujjatlar LoginModule-ni ishlab chiqishda bizga yordam beradi: " Java autentifikatsiya va avtorizatsiya xizmati (JAAS): LoginModule dasturchi qo'llanmasi ". Keling, kirish modulini amalga oshiramiz. Keling, interfeysni amalga oshiradigan sinf yarataylik LoginModule:

public class JaasLoginModule implements LoginModule {
}

Avval biz ishga tushirish usulini tasvirlaymiz LoginModule:

private CallbackHandler handler;
private Subject subject;
@Override
public void initialize(Subject subject, CallbackHandler callbackHandler, <String, ?> sharedState, Map<String, ?> options) {
	handler = callbackHandler;
	this.subject = subject;
}

Bu usul saqlaydi Subject, biz keyinchalik autentifikatsiya qilamiz va direktorlar haqidagi ma'lumotlarni to'ldiramiz. Biz ham kelajakda foydalanish uchun saqlaymiz CallbackHandler, bizga berilgan. Yordam bilan CallbackHandlerbiz bir oz keyinroq autentifikatsiya mavzusi haqida turli ma'lumotlarni so'rashimiz mumkin. Bu haqda ko'proq CallbackHandlerhujjatlarning tegishli bo'limida o'qishingiz mumkin: " JAAS Reference Guide: CallbackHandler ". loginKeyinchalik, autentifikatsiya qilish usuli bajariladi Subject. Bu autentifikatsiyaning birinchi bosqichi:

@Override
public boolean login() throws LoginException {
	// Добавляем колбэки
	Callback[] callbacks = new Callback[2];
	callbacks[0] = new NameCallback("login");
	callbacks[1] = new PasswordCallback("password", true);
	// При помощи колбэков получаем через CallbackHandler логин и пароль
	try {
		handler.handle(callbacks);
		String name = ((NameCallback) callbacks[0]).getName();
		String password = String.valueOf(((PasswordCallback) callbacks[1]).getPassword());
		// Далее выполняем валидацию.
		// Тут просто для примера проверяем определённые значения
		if (name != null && name.equals("user123") && password != null && password.equals("pass123")) {
			// Сохраняем информацию, которая будет использована в методе commit
			// Не "пачкаем" Subject, т.к. не факт, что commit выполнится
			// Для примера проставим группы вручную, "хардcodeно".
			login = name;
			userGroups = new ArrayList<String>();
			userGroups.add("admin");
			return true;
		} else {
			throw new LoginException("Authentication failed");
		}
	} catch (IOException | UnsupportedCallbackException e) {
		throw new LoginException(e.getMessage());
	}
}

loginni o'zgartirmasligimiz muhim Subject. Bunday o'zgarishlar faqat tasdiqlash usulida sodir bo'lishi kerak commit. Keyinchalik, muvaffaqiyatli autentifikatsiyani tasdiqlash usulini tasvirlashimiz kerak:

@Override
public boolean commit() throws LoginException {
	userPrincipal = new UserPrincipal(login);
	subject.getPrincipals().add(userPrincipal);
	if (userGroups != null && userGroups.size() > 0) {
		for (String groupName : userGroups) {
			rolePrincipal = new RolePrincipal(groupName);
			subject.getPrincipals().add(rolePrincipal);
		}
	}
	return true;
}

Usulni ajratish g'alati tuyulishi mumkin loginva commit. Lekin gap shundaki, login modullari birlashtirilishi mumkin. Muvaffaqiyatli autentifikatsiya qilish uchun bir nechta kirish modullari muvaffaqiyatli ishlashi kerak bo'lishi mumkin. Va agar barcha kerakli modullar ishlagan bo'lsa, o'zgarishlarni saqlang. Bu autentifikatsiyaning ikkinchi bosqichidir. Keling, abortva usullari bilan yakunlaylik logout:

@Override
public boolean abort() throws LoginException {
	return false;
}
@Override
public boolean logout() throws LoginException {
	subject.getPrincipals().remove(userPrincipal);
	subject.getPrincipals().remove(rolePrincipal);
	return true;
}

Usul abortautentifikatsiyaning birinchi bosqichi muvaffaqiyatsizlikka uchraganda chaqiriladi. Usul logouttizim tizimdan chiqqanda chaqiriladi. O'zimiznikini amalga oshirib Login Module, uni sozlaganimizdan so'ng, endi biz aniq biridan foydalanmoqchi ekanligimizni Security Realmko'rsatishimiz kerak : web.xmlLogin Config

<login-config>
  <auth-method>BASIC</auth-method>
  <realm-name>JaasLogin</realm-name>
</login-config>

Biz Xavfsizlik sohamiz nomini ko'rsatdik va autentifikatsiya usulini belgiladik - BASIC. Bu Servlet API-ning " 13.6 Autentifikatsiya " bo'limida tasvirlangan autentifikatsiya turlaridan biridir . Qolgan n

Izohlar

TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION