JavaRush /Java блогу /Random-KY /JAAS - Технологияга киришүү (1-бөлүк)

Деңгээл

28 February 2021
41 views
0 comments

JAAS - Технологияга киришүү (1-бөлүк)

Мүмкүнчүлүк коопсуздугу Java-да көптөн бери ишке ашырылып келет жана бул коопсуздукту камсыз кылуу архитектурасы JAAS - Java аутентификация жана авторизация кызматы деп аталат. Бул карап чыгуу аутентификация, авторизация деген эмне экенин жана ага JAASтин кандай тиешеси бар экендигинин сырын ачууга аракет кылат. JAAS кандайча Servlet API менен дос жана алардын мамилесинде көйгөйлөр бар.

Киришүү

Бул кароодо мен веб-тиркемелердин коопсуздугу сыяктуу теманы талкуулагым келет. Java коопсуздукту камсыз кылган бир нече технологияларга ээ:

" Java SE Platform Security Architecture ", бул тууралуу кененирээк маалыматты Oracle колдонмосунан окуса болот: " JavaTM SE Platform Security Architecture ". Бул архитектура биз Java SE иштөө чөйрөсүндө биздин Java тиркемелерибизди кантип коргошубуз керектигин сүрөттөйт. Бирок бул биздин бүгүнкү сүйлөшүүбүздүн темасы эмес.
" Java Cryptography Architecture " бул маалыматтарды шифрлөөсүн сүрөттөгөн Java кеңейтүүсү. Бул кеңейтүү жөнүндө көбүрөөк JavaRush боюнча " Java криптографиясынын архитектурасы: Биринчи таанышуу " кароосунан же Oracle колдонмосунан окуй аласыз: " Java Cryptography Architecture (JCA) Reference Guide ".

Бирок биздин бүгүнкү маегибиз "Java Authentication and Authorization Service (JAAS)" деп аталган дагы бир технология жөнүндө болмокчу. Бул аутентификация жана авторизация сыяктуу маанилүү нерселерди сүрөттөйт. Муну кененирээк карап көрөлү.

JAAS

JAAS Java SE кеңейтүүсү жана Java Аутентификация жана Authorизация Кызматында (JAAS) маалымдама колдонмосунда сүрөттөлгөн . Технологиянын аты айтып тургандай, JAAS аутентификация жана авторизация кантип аткарылышы керектигин сүрөттөйт:

" Аутентификация ": Грек тorнен которгондо "authentikos" "чыныгы, чыныгы" дегенди билдирет. Башкача айтканда, аутентификация – аныктыгын текшерүү. Аныктыгы текшерorп жаткандардын баары алар ким экенин айтышат.
" Authorization ": англис тorнен которгондо "уруксат" дегенди билдирет. Башкача айтканда, авторизация ийгorктүү аутентификациядан кийин аткарылган мүмкүндүктү башкаруу.

Башкача айтканда, JAAS бул ресурска кирүү мүмкүнчүлүгүн сураган ким экенин аныктоо жана ал бул мүмкүнчүлүктү ала алабы же жокпу деген чечимди кабыл алуу жөнүндө. Жашоодон кичинекей окшоштук: сиз жолдо баратасыз, инспектор токтотуп койду. Сураныч, documentтерди бериңиз - аутентификация. Сиз documentтери менен унаа айдай аласызбы - уруксат. Же, мисалы, сиз дүкөндөн спирт ичимдиктерин сатып алгыңыз келет. Биринчиден, сизден паспорт талап кылынат - аутентификация. Андан кийин, жашыңызга жараша, алкоголдук ичимдиктерди сатып алууга укугуңуз бар же жокпу, чечилет. Бул уруксат. Веб тиркемелеринде колдонуучу катары кирүү (колдонуучунун атын жана сырсөзүн киргизүү) аутентификация болуп саналат. Жана кайсы баракчаларды ача аларыңызды аныктоо авторизация менен аныкталат. Бул жерде "Java аутентификация жана авторизация кызматы (JAAS)" бизге жардам берет. JAASти карап жатканда, JAAS сүрөттөгөн бир нече негизги түшүнүктөрдү түшүнүү маанилүү: Предмет, Негиздер, Ишенимдүү маалыматтар. Субъект аутентификациянын предмети болуп саналат. Башкача айтканда, ал укуктун ээси же ээси. Документте, Субъект кандайдыр бир иш-аракетти аткаруу үчүн суроо-талаптын булагы катары аныкталат. Предмет же булак кандайдыр бир жол менен сүрөттөлүшү керек жана бул үчүн Принцип колдонулат, ал орус тorнде да кээде башкы деп аталат. Башкача айтканда, ар бир Принцип белгилүү бир көз караштан алганда субъекттин өкүлчүлүгү болуп саналат. Түшүнүктүү болуш үчүн бир мисал келтирели: Белгилүү бир адам Субъект. Ал эми төмөндөгүлөр Директордун милдетин аткара алышат:

анын айдоочулук күбөлүгү жол кыймылынын катышуучусу катары адамдын өкүлү катары
анын паспорту, өз өлкөсүнүн жараны катары адамдын өкүлү катары
анын чет өлкөлүк паспорту, эл аралык мамилелердин катышуучусу катары адамдын өкүлү катары
китепканада анын китепкана картасы, китепканага тиркелген окурман катары адамдын өкүлү катары

Мындан тышкары, Subject англис тorнен которгондо "өздүк" дегенди билдирген "Ишенимдүү маалымат" топтомун камтыйт. Бул Субъект өзүнүн ал экенин тастыктайт. Мисалы, колдонуучунун сырсөзү Credential болушу мүмкүн. Же колдонуучу чындап эле ал экенин тастыктай турган кандайдыр бир an object. Келгиле, эми JAAS веб-тиркемелерде кандайча колдонулганын карап көрөлү.

JAAS - Технологияга киришүү (1-бөлүк) - 3

Веб колдонмо

Ошентип, бизге веб-тиркеме керек. Gradle автоматтык долбоор куруу системасы бизге аны түзүүгө жардам берет. Gradleди колдонуунун аркасында биз кичинекей буйруктарды аткаруу менен Java долбоорун өзүбүзгө керектүү форматта чогулта алабыз, керектүү каталог түзүмүн автоматтык түрдө түзө алабыз жана башка көп нерселер. Сиз Gradle жөнүндө кененирээк кыскача баяндамадан окуй аласыз: " Градлга кыскача киришүү " же расмий documentацияда " Gradle Баштоо ". Биз долбоорду инициализациялашыбыз керек (Инициализация) жана бул үчүн Gradle атайын плагини бар: “ Gradle Init Plugin ” (Init Initialization үчүн кыска, эстеп калуу оңой). Бул плагинди колдонуу үчүн, буйрук сабында буйрукту иштетиңиз:

gradle init --type java-application

Ийгorктүү аяктагандан кийин бизде Java долбоору болот. Эми редакциялоо үчүн долбоорубуздун куруу сценарийин ачалы. build.gradleКуруу скрипти - бул колдонмонун түзүлүшүнүн нюанстарын сүрөттөгөн файл . Демек, аты, скрипт куруу. Бул долбоорду куруу сценарийи деп айта алабыз. Gradle - бул ар тараптуу курал, анын негизги мүмкүнчүлүктөрү плагиндер менен кеңейтилген. Ошондуктан, биринчи кезекте, "плагиндер" блогуна көңүл буралы:

plugins {
    id 'java'
    id 'application'
}

Демейки боюнча, Gradle, биз белгилеген " " ылайык --type java-application, кээ бир негизги плагиндердин топтомун орнотту, башкача айтканда, Gradle дистрибуциясына кирген плагиндер. Эгер сиз gradle.org веб-сайтындагы "Документтер" (б.а. documentация) бөлүмүнө кирсеңиз , анда "Шилтеме" бөлүмүндөгү темалардын тизмесинде сол жакта " Негизги плагиндер " бөлүмүн көрөбүз, б.а. бул абдан негизги плагиндердин сүрөттөлүшү менен бөлүм. Келгиле, Gradle биз үчүн жараткан плагиндерди эмес, бизге керектүү плагиндерди тандайлы. Документтерге ылайык, " Gradle Java Plugin " Java codeу менен баштапкы codeду түзүү сыяктуу негизги операцияларды камсыз кылат. Ошондой эле, documentацияга ылайык, " Gradle тиркеме плагини " бизге "аткарылуучу JVM тиркемеси" менен иштөө үчүн куралдар менен камсыз кылат, б.а. өз алдынча тиркеме катары ишке кирүүчү java тиркемеси менен (мисалы, консолдук тиркеме же өзүнүн UI бар тиркеме). Көрсө, бизге "колдонмо" плагининин кереги жок экен, анткени... бизге өз алдынча колдонмонун кереги жок, бизге веб колдонмо керек. Аны жок кылалы. Ошондой эле бул плагинге гана белгилүү болгон "mainClassName" жөндөөлөрү. Андан ары, ошол эле " Таңгактоо жана бөлүштүрүү " бөлүмүндө Колдонмо плагининин documentтерине шилтеме берилген, Gradle War Pluginге шилтеме бар. Gradle War Plugin , documentацияда айтылгандай, согуш форматында Java веб тиркемелерин түзүүгө колдоо көрсөтөт. WAR форматында JAR архивинин ордуна WAR архиви түзүлөт дегенди билдирет. Бул бизге керек окшойт. Ошондой эле, documentацияда айтылгандай, "Согуш плагини Java плагинин кеңейтет". Башкача айтканда, биз java плагинин согуш плагинине алмаштыра алабыз. Ошентип, биздин плагин блогубуз акыры мындай болот:

plugins {
    id 'war'
}

Ошондой эле "Gradle War Plugin" үчүн documentтерде бул плагин кошумча "Долбоор макетин" колдонот деп айтылат. Макет англис тorнен жайгашкан жер деп которулган. Башкача айтканда, согуш плагини демейки боюнча өз милдеттери үчүн колдоно турган файлдардын белгилүү бир жайгашкан жеринин болушун күтөт. Ал веб-тиркеме файлдарын сактоо үчүн төмөнкү каталогду колдонот: src/main/webapp Плагиндин жүрүм-туруму төмөнкүчө сүрөттөлөт:

JAAS - Технологияга киришүү (1-бөлүк) - 4

Башкача айтканда, плагин биздин веб-тиркеменин WAR архивин түзүүдө ушул жерден файлдарды эске алат. Мындан тышкары, Gradle War Plugin documentтеринде бул каталог "архивдин тамыры" болорун айтат. Ал эми буга чейин биз WEB-INF каталогун түзүп, ошол жерге web.xml файлын кошо алабыз. Бул кандай файл? web.xml- бул "Орнотуу дескриптору" же "жайгаруу дескриптору". Бул биздин веб тиркемени кантип иштөө үчүн конфигурациялоону сүрөттөгөн файл. Бул файл биздин колдонмобуздун кандай суроо-талаптарды аткара турганын, коопсуздук жөндөөлөрүн жана башка көптөгөн нерселерди көрсөтөт. Негизи, ал JAR файлындагы манифест файлына бир аз окшош (" Манифест файлдары менен иштөө: Негиздерди " караңыз). Манифест файлы Java Тиркемеси (б.а. JAR архиви) менен кантип иштөө керектигин айтат, ал эми web.xml Java веб тиркемеси (б.а. WAR архиви) менен кантип иштөө керектигин айтат. "Орнотуу Дескриптору" түшүнүгү өзүнөн өзү пайда болгон эмес, бирок documentте сүрөттөлгөн " Servlet API Specification"". Каалаган Java веб-тиркемеси ушул "Servlet API"ден көз каранды. Бул API экенин түшүнүү керек, башкача айтканда, бул кээ бир өз ара аракеттенүү келишиминин сүрөттөлүшү. Веб колдонмолору көз карандысыз тиркемелер эмес. Алар веб-serverде иштешет. , бул колдонуучулар менен тармактык байланышты камсыз кылат. Башкача айтканда, веб-server веб тиркемелери үчүн кандайдыр бир "контейнер" болуп саналат. Бул логикалуу, анткени биз веб-тиркеме логикасын жазгыбыз келет, б.а. колдонуучу кандай барактарды көрөт жана кантип алар колдонуучунун аракеттерине жооп бериши керек.Ал эми биз билдирүү колдонуучуга кантип жөнөтүлө тургандыгы, маалымат byteтары кандайча бериле тургандыгы жана башка төмөн деңгээлдеги жана өтө сапатты талап кылган нерселер үчүн code жазгыбыз келбейт. веб-тиркемелердин баары ар кандай экени көрүнүп турат, бирок маалыматтарды берүү бирдей.Б.а., бир миллион программисттер бир эле максат үчүн кайра-кайра code жазууга туура келет. жана маалымат алмашуу, ал эми веб-тиркеме жана иштеп чыгуучу ал маалыматтарды түзүү үчүн жооптуу. Ал эми бул эки бөлүктү бириктирүү үчүн, б.а. веб-server жана веб-тиркеме, сизге алардын өз ара аракеттенүүсү үчүн келишим керек, б.а. бул үчүн алар кандай эрежелерди карманышат? Келишимди кандайдыр бир түрдө сүрөттөп берүү үчүн, веб-тиркеме менен веб-serverдин ортосундагы өз ара аракеттенүү кандай болушу керек, Servlet API ойлоп табылган. Кызыктуусу, сиз Spring сыяктуу алHowтарды колдонсоңуз да, капоттун астында дагы эле Servlet API иштейт. Башкача айтканда, сиз Жазды колдоносуз, ал эми Жаз сиз үчүн Servlet API менен иштейт. Биздин веб-тиркеме долбоору Servlet API'ге көз каранды болушу керек экен. Бул учурда, Servlet API көз каранды болот. Белгилүү болгондой, Gradle ошондой эле долбоордун көз карандылыгын декларативдик түрдө сүрөттөөгө мүмкүнчүлүк берет. Плагиндер көз карандылыкты кантип башкарса болорун сүрөттөйт. Мисалы, Java Gradle Plugin "testImplementation" көз карандылыкты башкаруу ыкмасын киргизет, анда мындай көз карандылык тесттер үчүн гана керек деп айтылат. Бирок Gradle War Plugin көз карандылыкты башкаруу ыкмасын "providedCompile" кошот, анда мындай көз карандылык биздин веб тиркеменин WAR архивине киргизилбейт деп айтылат. Эмне үчүн биз WAR архивибизге Servlet API киргизбейбиз? Анткени Servlet API биздин веб-тиркемеге веб-serverдин өзү тарабынан берилет. Эгерде веб-server Сервлет API менен камсыз кылса, анда server сервлет контейнери деп аталат. Ошондуктан, бизге Сервлет API менен камсыз кылуу веб-serverдин милдети, ал эми СервлетAPIди 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 documentи http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd схемасы менен сүрөттөлөт . XML схемасы document кандай элементтерден турушу мүмкүн экенин жана алар кандай тартипте пайда болушу керектигин сүрөттөйт. Кайсылары милдеттүү, кайсылары милдеттүү эмес. Жалпысынан алганда, ал documentтин түзүмүн сүрөттөйт жана XML documentинин туура түзүлгөнүн текшерүүгө мүмкүндүк берет. Эми " 14.5 Мисалдар " бөлүмүндөгү мисалды колдонолу , бирок схема 3.1 versionсы үчүн көрсөтүлүшү керек, б.а.

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 колдонуучудан an object түрүндөгү суроо-талапты жаратып HttpServletRequest, аны сервлетке өткөрүп берерин сүрөттөөгө мүмкүндүк берет. Ал ошондой эле сервлетти an object менен камсыздайт HttpServletResponse, андыктан сервлет ага колдонуучу үчүн жооп жаза алат. Сервлет иштеп бүткөндөн кийин, server анын негизинде колдонуучуга жооп бере алат HttpServletResponse. Башкача айтканда, сервлет колдонуучу менен түз байланышта эмес, server менен гана байланышат. Сервер бизде сервлет бар экенин жана ал кандай суроо-талаптар үчүн колдонулушу керек экенин бorши үчүн, бул тууралуу 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 плагининин жакшы documentтери бар . Gretty плагини ар кандай веб-serverлердин ортосунда которуштурууга мүмкүндүк бере турганынан баштайлы. Бул documentацияда кененирээк сүрөттөлгөн: " Сервлет контейнерлеринин ортосунда которулуу ". Келгиле, Tomcat'ка которулалы, анткени... бул колдонуудагы эң популярдуулардын бири, ошондой эле жакшы documentтер жана көптөгөн мисалдар жана талданган көйгөйлөр бар:

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

Эми биз "gradle appRun" иштете алабыз, андан кийин биздин веб тиркеме http://localhost:8080/jaas/secret дарегинде жеткorктүү болот

JAAS - Технологияга киришүү (1-бөлүк) - 5

Сервлет контейнери Tomcat тарабынан тандалганын текшерүү маанилүү (№1 караңыз) жана биздин веб тиркеме кайсы даректе жеткorктүү экенин текшерүү (#2 караңыз).

JAAS - Технологияга киришүү (1-бөлүк) - 6

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

Аутентификация орнотуулары көбүнчө эки бөлүктөн турат: server тарабындагы орнотуулар жана ушул serverде иштеген веб-тиркеме тараптагы орнотуулар. Веб тиркемесинин коопсуздук жөндөөлөрү веб-serverдин коопсуздук орнотуулары менен өз ара аракеттениши мүмкүн, эгерде башка себепсиз веб-тиркеме веб-server менен өз ара аракеттене албаса. Биз бекеринен Tomcatка өткөн жокпуз, анткени... Tomcat жакшы сүрөттөлгөн архитектурага ээ (" Apache Tomcat 8 Архитектурасын " караңыз). Бул архитектуранын сүрөттөлүшүнөн көрүнүп тургандай, Tomcat веб-server катары веб-тиркемени белгилүү бир контекст катары көрсөтөт, ал " Tomcat Контекст " деп аталат. Бул контекст ар бир веб-тиркеме башка веб-тиркемелерден обочолонгон өзүнүн жөндөөлөрүнө ээ болууга мүмкүндүк берет. Кошумча, веб-тиркеме бул контексттин жөндөөлөрүнө таасир этиши мүмкүн. Ийкемдүү жана ыңгайлуу. Тереңирээк түшүнүү үчүн " Tomcat контексттик контейнерлерин түшүнүү " макаласын жана Tomcat documentациясынын " Контексттик контейнер " бөлүмүн окууну сунуштайбыз . Жогоруда айтылгандай, биздин веб тиркеме /META-INF/context.xml. Жана биз таасир эте ала турган эң маанилүү орнотуулардын бири - Коопсуздук чөйрөсү. Коопсуздук чөйрөсү "коопсуздук аймагынын" бир түрү. Атайын коопсуздук жөндөөлөрү көрсөтүлгөн аймак. Демек, Коопсуздук чөйрөсүн колдонууда биз бул чөйрө үчүн аныкталган коопсуздук орнотууларын колдонобуз. Коопсуздук чөйрөлөрү контейнер тарабынан башкарылат, б.а. веб-server, биздин веб тиркеме эмес. Колдонмобузга кайсы коопсуздук чөйрөсүн кеңейтүү керектигин serverге гана айта алабыз. Tomcat documentациясы " Регитим компоненти " бөлүмүндө Realm колдонуучулар жана алардын аутентификацияны аткаруу үчүн ролдору жөнүндө маалыматтардын жыйындысы катары сүрөттөйт. 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 documentациясынан көрүүгө болот: " Тиркеме В: Кирүү конфигурацияларынын мисалы ". Кошумчалай кетсек, бул файлды ресурстардан биринчи издөө керек. Ошондуктан, биздин веб-тиркеме бул файлды өзү камсыздай алат. Атрибуттар 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. Интерфейстен көрүнүп тургандай, Директор үчүн эң негизгиси - бул директорду билдирген кандайдыр бир аталышты (же ID) сактоо жана кайтаруу. Азыр бизде Коопсуздук чөйрөсү бар, бизде башкы класстар бар. Бул файлды " configFile" атрибутунан толтуруу үчүн калды, ака login configuration file. Анын сүрөттөлүшүн Tomcat documentациясынан тапса болот: " Realm Component ".

JAAS - Технологияга киришүү (1-бөлүк) - 7

Башкача айтканда, биз JAAS Login Config жөндөөсүн веб-тиркеменин ресурстарына жайгаштыра алабыз жана Tomcat Контексттин аркасында биз аны колдоно алабыз. Бул файл ClassLoader үчүн булак катары жеткorктүү болушу керек, андыктан анын жолу төмөнкүдөй болушу керек: \src\main\resources\jaas.config Келгиле, бул файлдын мазмунун орнотобуз:

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

context.xmlБул жерде жана бир эле ат колдонулганын белгилей кетүү керек . Бул Коопсуздук чөйрөсүн LoginModule менен картага түшүрөт. Ошентип, Tomcat Context бизге кайсы класстар жетекчилерди билдирерин, ошондой эле кайсы LoginModule колдонуу керектигин айтып берди. Биз эмне кылышыбыз керек, бул LoginModule ишке ашыруу болуп саналат. LoginModule , балким, JAASтеги эң кызыктуу нерселердин бири. Расмий documentтер LoginModuleди иштеп чыгууга жардам берет: " Java Authentication and Authorization Service (JAAS): LoginModule Developer's Guide ". Кирүү модулун ишке ашыралы. Келгиле, интерфейсти ишке ашырган класс түзөлү 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биз бир аздан кийин аутентификация предмети жөнүндө ар кандай маалыматты сурай алабыз. Бул тууралуу кененирээк CallbackHandlerdocumentациянын тиешелүү бөлүмүнөн окуй аласыз: " JAAS Reference Guide: 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. Андан кийин, биз ийгorктүү аутентификацияны ырастоо ыкмасын сүрөттөшүбүз керек:

@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Бул ыкманы жана бөлүү кызыктай сезorши мүмкүн commit. Бирок кеп логин модулдарын айкалыштырса болот. Жана ийгorктүү аутентификация үчүн бир нече кирүү модулдары ийгorктүү иштеши үчүн зарыл болушу мүмкүн. Жана бардык керектүү модулдар иштеген болсо, анда өзгөртүүлөрдү сактаңыз. Бул аутентификациянын экинчи этабы. 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 сүрөттөлгөн аутентификациянын түрлөрүнүн бири . Калды н

Комментарийлер

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