JavaRush /Java блогы /Random-KK /JAAS - Технологияға кіріспе (1 бөлім)

Деңгей

28 February 2021
35 views
0 comments

JAAS - Технологияға кіріспе (1 бөлім)

Қолжетімділік қауіпсіздігі Java тілінде ұзақ уақыт бойы жүзеге асырылып келеді және бұл қауіпсіздікті қамтамасыз ету архитектурасы JAAS – Java Authentication and Authorization Service деп аталады. Бұл шолу аутентификацияның, авторизацияның және JAAS-тың оған қандай қатысы барының құпиясын ашуға тырысады. JAAS Servlet API-мен қалай дос және олардың қарым-қатынасында проблемалары бар.

Кіріспе

Бұл шолуда мен веб-қосымшалардың қауіпсіздігі сияқты тақырыпты талқылағым келеді. Java-да қауіпсіздікті қамтамасыз ететін бірнеше технологиялар бар:

" Java SE платформасының қауіпсіздік архитектурасы ", ол туралы толығырақ ақпаратты Oracle нұсқаулығынан оқуға болады: " JavaTM SE платформасының қауіпсіздік архитектурасы ". Бұл архитектура Java SE орындалу ортасындағы Java қолданбаларын қорғау жолын сипаттайды. Бірақ бүгінгі әңгімеміздің тақырыбы бұл емес.
" Java криптографиялық архитектурасы " деректерді шифрлауды сипаттайтын Java кеңейтімі болып табылады. JavaRush қолданбасында осы кеңейтім туралы толығырақ « Java криптографиясының архитектурасы: алғашқы танысу » шолуынан немесе Oracle нұсқаулығынан: « Java криптографиялық архитектурасының (JCA) анықтамалық нұсқаулығында » оқи аласыз.

Бірақ біздің бүгінгі әңгімеміз «Java Authentication and Authorization Service (JAAS)» деп аталатын басқа технология туралы болмақ. Ол аутентификация және авторизация сияқты маңызды нәрселерді сипаттайды. Мұны толығырақ қарастырайық.

JAAS

JAAS Java SE кеңейтімі болып табылады және Java Authentication and Authorization Service (JAAS) анықтамалық нұсқаулығында сипатталған . Технологияның аты айтып тұрғандай, JAAS аутентификация мен авторизацияны қалай орындау керектігін сипаттайды:

" Аутентификация ": грек тілінен аударғанда "authentikos" "шынайы, шынайы" дегенді білдіреді. Яғни, аутентификация – шынайылықты тексеру. Түпнұсқалығы расталып жатқандар шынымен олар кім екенін айтады.
« Authorизация »: ағылшын тілінен аударғанда «рұқсат» дегенді білдіреді. Яғни авторизация сәтті аутентификациядан кейін орындалатын қатынасты басқару болып табылады.

Яғни, JAAS ресурсқа кімнің рұқсат сұрайтынын анықтау және оның осы рұқсатты ала алатындығы туралы шешім қабылдау туралы. Өмірден алынған кішігірім ұқсастық: сіз жол бойымен келе жатырсыз және сізді инспектор тоқтатады. Құжаттарды беріңіз - аутентификация. Құжаттар - рұқсатпен көлік жүргізе аласыз ба. Немесе, мысалы, сіз дүкеннен алкоголь сатып алғыңыз келеді. Біріншіден, сізден төлқұжат сұралады - аутентификация. Әрі қарай, сіздің жасыңызға байланысты алкогольді сатып алуға құқығыңыз бар-жоғы шешіледі. Бұл рұқсат. Веб қолданбаларында пайдаланушы ретінде кіру (пайдаланушы аты мен құпия сөзді енгізу) аутентификация болып табылады. Ал қай беттерді ашуға болатынын авторизация анықтайды. Мұнда бізге «Java аутентификация және авторизация қызметі (JAAS)» көмектеседі. JAAS қарастырған кезде, JAAS сипаттайтын бірнеше негізгі ұғымдарды түсіну маңызды: Тақырып, Басшылар, Тіркелгі деректер. Субъект аутентификация пәні болып табылады. Яғни, ол құқық иеленушісі немесе иесі. Құжаттамада Тақырып қандай да бір әрекетті орындауға сұраудың көзі ретінде анықталады. Тақырып немесе дереккөз қандай да бір түрде сипатталуы керек және осы мақсат үшін Principal пайдаланылады, оны орыс тілінде кейде негізгі деп те атайды. Яғни, әрбір Басшы белгілі бір көзқарас тұрғысынан субъектінің көрінісі болып табылады. Түсінікті болу үшін мысал келтірейік: Белгілі бір адам – субъект. Төмендегілер Басшылар ретінде әрекет ете алады:

оның жүргізуші куәлігі жол қозғалысына қатысушы ретінде тұлғаның өкілі ретінде
оның төлқұжаты адамның өз елінің азаматы ретіндегі өкілдігі ретінде
оның шетелдік паспорты, тұлғаның халықаралық қатынастарға қатысушы ретіндегі өкілдігі ретінде
оның кітапханадағы кітапхана картасы, кітапханаға тіркелген оқырман ретінде тұлғаның бейнесі ретінде

Сонымен қатар Subject-те ағылшын тілінен аударғанда «жеке куәлік» дегенді білдіретін «Тіркелгі деректері» жинағы бар. Осылай Субъект өзінің өзі екенін растайды. Мысалы, пайдаланушының құпия сөзі тіркелгі деректері болуы мүмкін. Немесе пайдаланушы өзінің шын мәнінде ол екенін растай алатын кез келген нысан. Енді JAAS веб-қосымшаларда қалай қолданылатынын көрейік.

JAAS - Технологияға кіріспе (1 бөлім) - 3

Веб қолданбасы

Сонымен, бізге веб-қосымша қажет. Gradle автоматты жоба құру жүйесі бізге оны жасауға көмектеседі. Gradle қолданбасының арқасында біз шағын командаларды орындау арқылы Java жобасын өзімізге қажетті форматта жинай аламыз, қажетті каталог құрылымын автоматты түрде жасай аламыз және т.б. Сіз Gradle туралы қосымша ақпаратты қысқаша шолудан оқи аласыз: « Gradle туралы қысқаша кіріспе » немесе « Gradle бастау » ресми құжаттамасынан . Біз жобаны инициализациялауымыз керек (Инициализация) және бұл үшін Gradle-де арнайы плагин бар: “ Gradle Init Plugin ” (Init – Initialization деген сөздің қысқасы, есте сақтау оңай). Бұл плагинді пайдалану үшін пәрмен жолында пәрменді іске қосыңыз:

gradle init --type java-application

Сәтті аяқталғаннан кейін бізде Java жобасы болады. Енді редакциялау үшін жобамыздың құрастыру сценарийін ашайық. build.gradleҚұрастыру сценарийі қолданбаны құрастырудың нюанстарын сипаттайтын файл деп аталады . Сценарий құрастыру атауы осыдан. Бұл жобаны құрастыру сценарийі деп айта аламыз. Gradle - бұл әмбебап құрал, оның негізгі мүмкіндіктері плагиндермен кеңейтілген. Сондықтан, ең алдымен, «плагиндер» блогына назар аударайық:

plugins {
    id 'java'
    id 'application'
}

Әдепкі бойынша, Gradle, біз көрсеткен " " сәйкес --type java-application, кейбір негізгі плагиндер жинағын орнатты, яғни Gradle дистрибуциясына кіретін плагиндер. Егер сіз gradle.org веб- сайтындағы «Құжаттар» (яғни құжаттама) бөліміне өтсеңіз , «Анықтама» бөліміндегі тақырыптар тізімінде сол жақта « Негізгі плагиндер » бөлімін көреміз, яғни. осы өте негізгі плагиндердің сипаттамасы бар бөлім. Gradle біз үшін жасағандарды емес, дәл бізге қажет плагиндерді таңдайық. Құжаттамаға сәйкес, « Gradle Java Plugin » бастапқы codeты құрастыру сияқты Java codeымен негізгі операцияларды қамтамасыз етеді. Сондай-ақ, құжаттамаға сәйкес, « Gradle қолданбасының плагині » бізге «орындалатын JVM қолданбасымен» жұмыс істеуге арналған құралдармен қамтамасыз етеді, яғни. дербес қолданба ретінде іске қосуға болатын java қолданбасымен (мысалы, консольдік қолданба немесе өзінің пайдаланушы интерфейсі бар қолданба). Бізге «қолданба» плагинінің қажеті жоқ екен, өйткені... бізге дербес қолданба қажет емес, бізге веб-бағдарлама қажет. Оны жойайық. Сондай-ақ осы плагинге ғана белгілі «mainClassName» параметрі. Әрі қарай, Application Plugin құжаттамасына сілтеме берілген « Орау және тарату » бөлімінде Gradle War плагиніне сілтеме бар. Gradle War Plugin құжаттамада көрсетілгендей, соғыс пішімінде Java веб-қосымшаларын жасауға қолдау көрсетеді. WAR пішімі JAR мұрағатының орнына WAR мұрағаты жасалатынын білдіреді. Бізге керегі де осы сияқты. Сондай-ақ, құжаттамада айтылғандай, «Соғыс плагині Java плагинін кеңейтеді». Яғни, біз java плагинін соғыс плагинімен алмастыра аламыз. Осылайша, біздің плагин блогы сайып келгенде келесідей болады:

plugins {
    id 'war'
}

Сондай-ақ, «Gradle War Plugin» құжаттамасында плагин қосымша «Жоба орналасуын» қолданатыны айтылады. Layout ағылшын тілінен орын ретінде аударылған. Яғни, соғыс плагині әдепкі бойынша өз тапсырмалары үшін пайдаланатын файлдардың белгілі бір орнының болуын күтеді. Ол веб-бағдарлама файлдарын сақтау үшін келесі каталогты пайдаланады: src/main/webapp Плагиннің әрекеті келесідей сипатталған:

JAAS - Технологияға кіріспе (1 бөлім) - 4

Яғни, плагин веб-қосымшамыздың WAR мұрағатын құру кезінде осы орындағы файлдарды ескереді. Сонымен қатар, Gradle War Plugin құжаттамасында бұл каталог «мұрағаттың түбірі» болатынын айтады. Оның ішінде біз WEB-INF каталогын жасай аламыз және сол жерге web.xml файлын қоса аламыз. Бұл қандай файл? web.xml- бұл «орналастыру дескрипторы» немесе «орналастыру дескрипторы». Бұл веб-қосымшаны жұмыс істеу үшін конфигурациялауды сипаттайтын файл. Бұл файл қолданбамыздың қандай сұрауларды өңдейтінін, қауіпсіздік параметрлерін және т.б. көрсетеді. Негізінде ол JAR файлындағы манифест файлына біршама ұқсас (« Манифест файлдарымен жұмыс істеу: Негіздер » бөлімін қараңыз). Манифест файлы Java қолданбасымен (яғни JAR мұрағаты) қалай жұмыс істеу керектігін айтады, ал web.xml Java веб-қосымшасымен (яғни WAR мұрағаты) қалай жұмыс істеу керектігін айтады. «Орналастыру дескрипторы» ұғымының өзі өздігінен пайда болған жоқ, бірақ « Servlet API сипаттамасы» құжатында сипатталған.". Кез келген Java веб-бағдарламасы осы "Servlet API"-ге байланысты. Бұл API екенін түсіну маңызды, яғни бұл кейбір өзара әрекеттесу келісім-шартының сипаттамасы. Веб-қосымшалар тәуелсіз қолданбалар емес. Олар веб-serverде жұмыс істейді. , ол пайдаланушылармен желілік байланысты қамтамасыз етеді.Яғни, веб-server веб-қосымшаларға арналған «контейнердің» бір түрі.Бұл қисынды, өйткені біз веб-қосымшаның логикасын жазғымыз келеді, яғни пайдаланушы қандай беттерді және қалай көретінін жазғымыз келеді. олар пайдаланушының әрекетіне жауап беруі керек.Және біз пайдаланушыға хабарлама қалай жіберілетіні, ақпарат byteтары қалай тасымалданатыны және басқа да төмен деңгейлі және өте сапаны талап ететін нәрселер туралы code жазғымыз келмейді. веб-қосымшалардың барлығы әртүрлі, бірақ деректерді тасымалдау бірдей.Яғни, миллиондаған бағдарламашылар бір мақсат үшін codeты қайта-қайта жазуға тура келеді.Сондықтан веб-server пайдаланушының кейбір өзара әрекеттесуіне жауап береді. және деректер алмасу, ал веб-бағдарлама мен әзірлеуші сол деректерді жасауға жауапты. Және осы екі бөлікті қосу үшін, т. веб-server мен веб-бағдарлама үшін олардың өзара әрекеттесуі үшін келісімшарт қажет, яғни. олар мұны істеу үшін қандай ережелерді сақтайды? Келісімшартты қандай да бір түрде сипаттау үшін, веб-қосымша мен веб-server арасындағы өзара әрекеттесу қандай болуы керек, Servlet API ойлап табылды. Бір қызығы, Spring сияқты фреймворктерді пайдалансаңыз да, қақпақ астында әлі де Servlet API жұмыс істейді. Яғни, сіз Spring пайдаланасыз, ал Spring сіз үшін Servlet API-мен жұмыс істейді. Біздің веб-қосымшалар жобасы Servlet API-ге тәуелді болуы керек екен. Бұл жағдайда Servlet API тәуелділік болады. Біз білетіндей, Gradle сонымен қатар жобаның тәуелділіктерін декларативті түрде сипаттауға мүмкіндік береді. Плагиндер тәуелділіктерді қалай басқаруға болатынын сипаттайды. Мысалы, Java Gradle Plugin «testImplementation» тәуелділікті басқару әдісін ұсынады, ол мұндай тәуелділіктің тек сынақтар үшін қажет екенін айтады. Бірақ Gradle War Plugin «providedCompile» тәуелділікті басқару әдісін қосады, ол мұндай тәуелділік біздің веб-қосымшаның WAR мұрағатына қосылмайтынын айтады. Неліктен біз WAR мұрағатымызға Servlet API қолданбаймыз? Өйткені Servlet API веб-бағдарламаға веб-serverдің өзі арқылы беріледі. Егер веб-server Servlet API қамтамасыз етсе, онда server сервлет контейнері деп аталады. Сондықтан, бізге Servlet API қамтамасыз ету веб-serverдің жауапкершілігі болып табылады және ServletAPI-ді code құрастырылған кезде ғана қамтамасыз ету біздің жауапкершілігіміз. Сондықтан providedCompile. Осылайша, тәуелділіктер блогы келесідей болады:

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

Сонымен, web.xml файлына оралайық. Әдепкі бойынша, Gradle ешқандай орналастыру дескрипторын жасамайды, сондықтан біз мұны өзіміз жасауымыз керек. Каталог құрайық src/main/webapp/WEB-INF, сонда біз XML файлын жасаймыз деп аталатын web.xml. Енді «Java Servlet спецификациясының» өзін және « 14-БӨЛІМ орналастыру дескрипторы » тарауын ашайық . "14.3 Орналастыру дескрипторында" көрсетілгендей, Орналастыру дескрипторының XML құжаты http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd схемасы арқылы сипатталады . XML схемасы құжаттың қандай элементтерден тұруы мүмкін екенін және олар қандай ретпен көрінетінін сипаттайды. Қайсысы міндетті, қайсысы міндетті емес. Жалпы ол құжаттың құрылымын сипаттайды және XML құжатының дұрыс құрастырылғанын тексеруге мүмкіндік береді. Енді « 14.5 Мысалдар » тарауындағы мысалды қолданайық , бірақ схема 3.1 нұсқасы үшін көрсетілуі керек, яғни.

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

Біздің бос web.xmlкелесідей болады:

<?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>

Енді JAAS арқылы қорғайтын сервлетті сипаттап көрейік. Бұрын Gradle біз үшін App класын жасаған. Оны сервлетке айналдырайық. « Сервлет интерфейсінің 2-тарауындағы » спецификацияда айтылғандай , « Көптеген мақсаттар үшін әзірлеушілер өздерінің сервлеттерін іске асыру үшін HttpServlet кеңейтеді », яғни сыныпты сервлет ету үшін осы сыныпты келесіден мұралау қажет 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());
    }
}

Жоғарыда айтқанымыздай, Servlet API server мен веб-бағдарлама арасындағы келісім-шарт болып табылады. Бұл келісім-шарт бізге пайдаланушы serverмен байланысқан кезде server пайдаланушыдан нысан түріндегі сұрауды жасап HttpServletRequest, оны сервлетке жіберетінін сипаттауға мүмкіндік береді. HttpServletResponseСондай-ақ ол сервлет пайдаланушыға жауап жаза алатындай нысанмен қамтамасыз етеді . Сервлет іске қосылғаннан кейін server пайдаланушыға оның негізінде жауап бере алады HttpServletResponse. Яғни, сервлет пайдаланушымен тікелей байланыспайды, тек serverмен ғана байланысады. Сервер бізде сервлет бар екенін және оны қандай сұраулар үшін пайдалану керектігін білуі үшін serverге бұл туралы орналастыру дескрипторында айту керек:

<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>

Бұл жағдайда барлық сұраулар сыныпқа сәйкес келетін /secretат бойынша біздің бір сервлетке жіберілмейді . Жоғарыда айтқанымыздай, веб-қосымшаны тек веб-serverде орналастыруға болады. Веб-serverді бөлек орнатуға болады (оқшау). Бірақ осы шолудың мақсаттары үшін балама опция қолайлы - ендірілген serverде жұмыс істейді. Бұл server бағдарламалық түрде құрылып, іске қосылатынын білдіреді (плагин мұны біз үшін жасайды) және сонымен бірге біздің веб-қосымшамыз оған орналастырылады. Gradle құрастыру жүйесі " Gradle Gretty Plugin " плагинін мына мақсаттарда пайдалануға мүмкіндік береді :appjaas.App

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

Сонымен қатар, Gretty плагинінде жақсы құжаттама бар . Gretty плагині әртүрлі веб-serverлер арасында ауысуға мүмкіндік беретінінен бастайық. Бұл құжаттамада толығырақ сипатталған: " Сервлет контейнерлері арасында ауысу ". Tomcat-қа ауысайық, өйткені... ол ең танымалдардың бірі болып табылады, сонымен қатар жақсы құжаттама және көптеген мысалдар мен талданған мәселелер бар:

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

Енді біз «gradle appRun» іске қоса аламыз, содан кейін біздің веб-қосымшамыз http://localhost:8080/jaas/secret мекенжайында қолжетімді болады.

JAAS - Технологияға кіріспе (1 бөлім) - 5

Сервлет контейнерін Tomcat таңдағанын тексеру маңызды (№1 қараңыз) және веб-қосымшаның қай мекенжайда қолжетімді екенін тексеріңіз (№2 қараңыз).

JAAS - Технологияға кіріспе (1 бөлім) - 6

Аутентификация

Аутентификация параметрлері көбінесе екі бөліктен тұрады: server жағындағы параметрлер және осы serverде жұмыс істейтін веб-бағдарламаның жағындағы параметрлер. Веб-бағдарламаның қауіпсіздік параметрлері веб-serverдің қауіпсіздік параметрлерімен өзара әрекеттесуі мүмкін емес, егер басқа себепсіз веб-бағдарлама веб-serverмен өзара әрекеттесе алмайды. Біз Tomcat-қа бекер ауысқан жоқпыз, өйткені... Tomcat жақсы сипатталған архитектураға ие (« Apache Tomcat 8 Architecture » бөлімін қараңыз). Бұл архитектураның сипаттамасынан Tomcat веб-server ретінде веб-қосымшаны « Tomcat контекст » деп аталатын белгілі бір контекст ретінде көрсететіні анық. Бұл контекст әрбір веб-бағдарламаның басқа веб-бағдарламалардан оқшауланған өз параметрлеріне ие болуына мүмкіндік береді. Бұған қоса, веб-бағдарлама осы мәтінмәннің параметрлеріне әсер ете алады. Икемді және ыңғайлы. Тереңірек түсіну үшін « Tomcat контекстік контейнерлерін түсіну » мақаласын және Tomcat құжаттамасының « Контекстік контейнер » бөлімін оқуды ұсынамыз. Жоғарыда айтылғандай, біздің веб-бағдарлама қолданбамыздың Tomcat контекстіне /META-INF/context.xml. Біз әсер ете алатын маңызды параметрлердің бірі - қауіпсіздік аймақтары. Қауіпсіздік аймақтары – бұл «қауіпсіздік аймағының» бір түрі. Арнайы қауіпсіздік параметрлері көрсетілген аймақ. Сәйкесінше, қауіпсіздік аймағын пайдаланған кезде біз осы аймақ үшін анықталған қауіпсіздік параметрлерін қолданамыз. Қауіпсіздік аймақтары контейнер арқылы басқарылады, яғни. веб-server, біздің веб-қосымшамыз емес. Біз serverге тек біздің қолданбаға қандай қауіпсіздік ауқымын кеңейту керектігін айта аламыз. « Аумақтың құрамдас бөлігі » бөліміндегі Tomcat құжаттамасы аймақты пайдаланушылар және олардың аутентификацияны орындауға арналған рөлдері туралы деректер жинағы ретінде сипаттайды. Tomcat әртүрлі Security Realm іске асыру жиынтығын ұсынады, олардың бірі - " Jaas Realm ". Кішкене терминологияны түсінгеннен кейін, файлдағы Tomcat контекстін сипаттап көрейік /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— қолданба атауы. Tomcat бұл атауды файлда көрсетілген атаулармен сәйкестендіруге тырысады configFile. configFile- бұл «логин конфигурация файлы». Мұның мысалын JAAS құжаттамасынан көруге болады: " B Қосымшасы: Кіру конфигурацияларының мысалы ". Бұған қоса, бұл файлды ресурстарда бірінші іздейтіні маңызды. Сондықтан біздің веб-қосымшамыз бұл файлды өзі қамтамасыз ете алады. Атрибуттар userClassNamesжәне roleClassNamesпайдаланушының негізгісін көрсететін сыныптардың көрсеткішін қамтиды. JAAS «пайдаланушы» және «рөл» ұғымдарын екі түрлі ұғым ретінде бөледі java.security.Principal. Жоғарыдағы сыныптарға сипаттама берейік. Пайдаланушы директоры үшін ең қарапайым іске асыруды жасайық:

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

үшін дәл сол іске асыруды қайталаймыз RolePrincipal. Интерфейстен көріп отырғаныңыздай, Басшы үшін ең бастысы - Басты тұлғаны білдіретін кейбір атауды (немесе идентификаторды) сақтау және қайтару. Енді бізде Қауіпсіздік аймағы бар, бізде негізгі сыныптар бар. Файлды " " атрибутынан толтыру қалады configFile, aka login configuration file. Оның сипаттамасын Tomcat құжаттамасынан табуға болады: « The Realm Component ».

JAAS - Технологияға кіріспе (1 бөлім) - 7

Яғни, біз JAAS Login Config параметрін веб-қосымшамыздың ресурстарына орналастыра аламыз және Tomcat Context арқасында біз оны пайдалана аламыз. Бұл файл ClassLoader үшін ресурс ретінде қолжетімді болуы керек, сондықтан оның жолы келесідей болуы керек: \src\main\resources\jaas.config Осы файлдың мазмұнын орнатайық:

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

Айта кету керек, context.xmlбір атау осы жерде және ішінде қолданылады. Бұл қауіпсіздік аймағын LoginModuleмен салыстырады. Сонымен, Tomcat Context бізге қандай сыныптар жетекшілерді білдіретінін, сондай-ақ қандай LoginModule пайдалану керектігін айтты. Бізге тек осы LoginModule енгізу керек. LoginModule JAAS-тағы ең қызықты нәрселердің бірі болуы мүмкін. Ресми құжаттама LoginModule әзірлеуге көмектеседі: " Java аутентификация және авторизация қызметі (JAAS): LoginModule әзірлеуші нұсқаулығы ". Кіру модулін іске асырайық. Интерфейсті жүзеге асыратын класс жасайық LoginModule:

public class JaasLoginModule implements LoginModule {
}

Алдымен біз инициализация әдісін сипаттаймыз 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;
}

Бұл әдіс сақтайды Subject, біз оны әрі қарай аутентификациялаймыз және жетекшілер туралы ақпаратпен толтырамыз. CallbackHandlerБіз сондай-ақ бізге берілген болашақта пайдалану үшін сақтаймыз . Көмекпен CallbackHandlerбіз аутентификация тақырыбы туралы әртүрлі ақпаратты сәл кейінірек сұрай аламыз. Бұл туралы толығырақ CallbackHandlerқұжаттаманың сәйкес бөлімінде оқи аласыз: " JAAS анықтамалық нұсқаулығы: CallbackHandler ". loginСодан кейін аутентификация әдісі орындалады Subject. Бұл аутентификацияның бірінші кезеңі:

@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());
	}
}

loginБіз өзгертпеуіміз маңызды Subject. Мұндай өзгерістер тек растау әдісінде болуы керек commit. Әрі қарай, сәтті аутентификацияны растау әдісін сипаттауымыз керек:

@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;
}

loginӘдіс пен әдісті бөлу оғаш көрінуі мүмкін commit. Бірақ мәселе логин модульдерін біріктіруге болады. Сәтті аутентификация үшін бірнеше кіру модулінің сәтті жұмыс істеуі қажет болуы мүмкін. Барлық қажетті модульдер жұмыс істеген жағдайда ғана өзгертулерді сақтаңыз. Бұл аутентификацияның екінші кезеңі. abortжәне әдістерімен аяқтаймыз 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;
}

Әдіс abortаутентификацияның бірінші кезеңі сәтсіз болғанда шақырылады. Әдіс logoutжүйе жүйеден шыққан кезде шақырылады. Өзімізді іске асырып Login Module, оны конфигурациялағаннан кейін, енді біз нақтысын қолданғымыз келетінін Security Realmкөрсетуіміз керек : web.xmlLogin Config

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

Қауіпсіздік аймағының атын көрсеттік және аутентификация әдісін көрсеттік - BASIC. Бұл " 13.6 Аутентификация " бөлімінде Servlet API сипатталған аутентификация түрлерінің бірі . n қалды

Пікірлер

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