JAAS - Texnologiyaya Giriş (1-ci Hissə)

Giriş təhlükəsizliyi Java-da kifayət qədər uzun müddətdir həyata keçirilir və bu təhlükəsizliyi təmin edən arxitektura JAAS - Java Authentication and Authorization Service adlanır. Bu baxış autentifikasiyanın, avtorizasiyanın nə olduğunu və JAAS-ın bununla nə əlaqəsi olduğunun sirrini açmağa çalışacaq. JAAS-ın Servlet API ilə necə dost olduğu və münasibətlərində problemlərin olduğu yer.

Giriş

Bu icmalda mən veb proqram təhlükəsizliyi kimi bir mövzunu müzakirə etmək istərdim. Java təhlükəsizliyini təmin edən bir neçə texnologiyaya malikdir:

• " Java SE Platform Təhlükəsizlik Memarlığı ", haqqında daha ətraflı məlumatı Oracle-ın Bələdçisində oxumaq olar: " JavaTM SE Platforma Təhlükəsizlik Arxitekturası ". Bu arxitektura Java SE iş vaxtı mühitində Java proqramlarımızı necə qorumalı olduğumuzu təsvir edir. Amma bugünkü söhbətimizin mövzusu bu deyil.

• " Java Kriptoqrafiya Arxitekturası " verilənlərin şifrələnməsini təsvir edən Java Genişləndirilməsidir. JavaRush-da bu genişləndirmə haqqında daha çox məlumatı " Java Kriptoqrafiya Arxitekturası: İlk tanışlıq " icmalında və ya Oracle-ın Bələdçisində oxuya bilərsiniz: " Java Kriptoqrafiya Memarlığı (JCA) Referans Bələdçisi ".

Ancaq bugünkü söhbətimiz “Java Authentication and Authorization Service (JAAS)” adlanan başqa bir texnologiya haqqında olacaq. Doğrulama və icazə kimi vacib şeyləri təsvir edən odur. Buna daha ətraflı baxaq.

JAAS

JAAS Java SE-nin genişləndirilməsidir və Java Authentication and Authorization Service (JAAS) Referans Bələdçisində təsvir edilmişdir . Texnologiyanın adından da göründüyü kimi, JAAS autentifikasiya və avtorizasiyanın necə həyata keçirilməli olduğunu təsvir edir:

• " Authentication ": Yunan dilindən tərcümədə "authentikos" "real, orijinal" deməkdir. Yəni autentifikasiya həqiqilik sınağıdır. Kim təsdiqlənirsə, onlar həqiqətən kim olduqlarını deyirlər.

• " Authorization ": ingilis dilindən tərcümədə "icazə" deməkdir. Yəni avtorizasiya uğurlu autentifikasiyadan sonra həyata keçirilən giriş nəzarətidir.

Yəni, JAAS resursa kimin müraciət etdiyini müəyyən etmək və onun bu girişi əldə edib-etməməsinə dair qərar verməkdən ibarətdir. Həyatdan kiçik bir bənzətmə: yol boyu maşın sürürsən və müfəttiş səni saxlayır. Zəhmət olmasa sənədləri təqdim edin - autentifikasiya. Sənədlərlə avtomobil idarə edə bilərsiniz - icazə. Və ya, məsələn, bir mağazada spirt almaq istəyirsən. Birincisi, sizdən pasport tələb olunur - autentifikasiya. Sonra, yaşınıza əsaslanaraq, spirt almağa uyğun olub-olmamağınıza qərar verilir. Bu icazədir. Veb proqramlarında istifadəçi kimi daxil olmaq (istifadəçi adı və parolun daxil edilməsi) autentifikasiyadır. Hansı səhifələri aça biləcəyinizi müəyyən etmək icazə ilə müəyyən edilir. Burada “Java Doğrulama və Avtorizasiya Xidməti (JAAS)” bizə kömək edir. JAAS-ı nəzərdən keçirərkən, JAAS-ın təsvir etdiyi bir neçə əsas anlayışı anlamaq vacibdir: Mövzu, Prinsiplər, Etibarnamələr. Mövzu autentifikasiya mövzusudur. Yəni haqqın daşıyıcısı və ya sahibidir. Sənədlərdə Mövzu bəzi hərəkətləri yerinə yetirmək üçün sorğunun mənbəyi kimi müəyyən edilir. Mövzu və ya mənbə bir şəkildə təsvir edilməlidir və bu məqsədlə Principal istifadə olunur ki, bu da rus dilində bəzən əsas adlanır. Yəni, hər bir Müdir müəyyən bir baxımdan bir Subyektin təmsilidir. Daha aydın olması üçün bir misal verək: Müəyyən bir şəxs Subyektdir. Və aşağıdakılar Direktor kimi çıxış edə bilər:

• onun sürücülük vəsiqəsi bir şəxsin yol hərəkəti iştirakçısı kimi təmsil olunması
• onun pasportu, bir şəxsin öz ölkəsinin vətəndaşı kimi təmsilçisi kimi
• onun xarici pasportu, beynəlxalq münasibətlərin iştirakçısı kimi şəxsin nümayəndəsi kimi
• kitabxanada onun kitabxana kartı, kitabxanaya bağlı bir oxucu kimi bir şəxsin təmsili olaraq

Bundan əlavə, Subject-də ingilis dilində "şəxsiyyət" mənasını verən "Etibarnamə" dəsti var. Subyekt öz olduğunu belə təsdiqləyir. Məsələn, istifadəçinin parolu Etibarnamə ola bilər. Və ya istifadəçinin həqiqətən onun olduğunu təsdiq edə biləcəyi hər hansı bir obyekt. İndi JAAS-ın veb proqramlarında necə istifadə olunduğunu görək.

Veb tətbiqi

Beləliklə, bizə veb proqram lazımdır. Gradle avtomatik layihə qurma sistemi bizə onu yaratmağa kömək edəcək. Gradle proqramından istifadə sayəsində biz kiçik əmrləri yerinə yetirməklə Java layihəsini bizə lazım olan formatda yığa, avtomatik olaraq lazımi kataloq strukturunu yarada və s. Siz Gradle haqqında qısa icmalda oxuya bilərsiniz: " Gradle-a Qısa Giriş " və ya rəsmi sənədlərdə " Gradle Başlarkən ". Biz layihəni işə salmalıyıq (İnsiallaşdırma) və bu məqsədlə Gradle-in xüsusi plagini var: “ Gradle Init Plugin ” (İnit Initialization üçün qısadır, yadda saxlamaq asandır). Bu plaqini istifadə etmək üçün əmr satırında əmri işlədin:

gradle init --type java-application

Uğurlu başa çatdıqdan sonra Java layihəmiz olacaq. İndi layihəmizin quruluş skriptini redaktə üçün açaq. build.gradleQuraşdırma skripti proqramın qurulmasının nüanslarını təsvir edən fayldır . Beləliklə, ad, skript qurun. Bunun bir layihə qurma skripti olduğunu söyləyə bilərik. Gradle çox yönlü bir vasitədir, onun əsas imkanları plaginlərlə genişləndirilir. Buna görə də, ilk növbədə, “pluginlər” blokuna diqqət yetirək:

plugins {
    id 'java'
    id 'application'
}

Varsayılan olaraq, Gradle, qeyd etdiyimizə uyğun olaraq, " --type java-application", bəzi əsas plaginlər dəstini, yəni Gradle-in paylanmasına daxil olan plaginləri quraşdırdı. Əgər siz gradle.org saytındakı "Sənədlər" (yəni sənədlər) bölməsinə gedirsinizsə , o zaman "İstinad" bölməsindəki mövzular siyahısında solda " Əsas Plugins " bölməsini görürük, yəni. bu çox əsas plaginlərin təsviri ilə bölmə. Gradle-in bizim üçün yaratdığını deyil, bizə lazım olan plaginləri seçək. Sənədlərə əsasən, " Gradle Java Plugin " Java kodu ilə əsas əməliyyatları, məsələn, mənbə kodunu tərtib edir. Həmçinin, sənədlərə əsasən, " Gradle proqram plagini " bizə "icra edilə bilən JVM proqramı" ilə işləmək üçün alətlər təqdim edir, yəni. müstəqil proqram kimi işə salına bilən java proqramı ilə (məsələn, konsol proqramı və ya öz istifadəçi interfeysi olan proqram). Belə çıxır ki, bizə “tətbiq” plagininə ehtiyac yoxdur, çünki... bizə müstəqil proqram lazım deyil, bizə veb proqram lazımdır. Gəlin onu silək. Yalnız bu plaginə məlum olan “mainClassName” parametri kimi. Bundan əlavə, Tətbiq Plugin sənədlərinə keçidin təqdim edildiyi eyni " Qablaşdırma və paylama " bölməsində Gradle War Plugin-ə keçid var. Gradle War Plugin , sənədlərdə qeyd edildiyi kimi, müharibə formatında Java veb proqramlarının yaradılması üçün dəstək verir. WAR formatında o deməkdir ki, JAR arxivi əvəzinə WAR arxivi yaradılacaq. Deyəsən, bu bizə lazımdır. Həmçinin, sənədlərdə deyildiyi kimi, "Müharibə plagini Java plaginini genişləndirir". Yəni java plaginini war plugin ilə əvəz edə bilərik. Beləliklə, plagin blokumuz nəticədə belə görünəcək:

plugins {
    id 'war'
}

Həmçinin “Gradle War Plugin” üçün sənədlərdə deyilir ki, plaqinin əlavə “Layihə tərtibatı”ndan istifadə edir. Layout ingilis dilindən yer kimi tərcümə olunur. Yəni, müharibə plagini standart olaraq vəzifələri üçün istifadə edəcəyi müəyyən bir fayl yerinin mövcudluğunu gözləyir. Veb proqram fayllarını saxlamaq üçün aşağıdakı kataloqdan istifadə edəcək: src/main/webapp Pluginin davranışı aşağıdakı kimi təsvir edilmişdir: Yəni plagin veb proqramımızın WAR arxivini qurarkən bu yerdən olan faylları nəzərə alacaq. Bundan əlavə, Gradle War Plugin sənədlərində deyilir ki, bu kataloq "arxivin kökü" olacaq. Və artıq orada biz WEB-INF kataloqu yarada və ora web.xml faylını əlavə edə bilərik. Bu hansı fayldır? web.xml- bu, "Yerləşdirmə Deskriptoru" və ya "Yerləşdirmə Deskriptoru"dur. Bu, veb tətbiqimizi işləmək üçün necə konfiqurasiya edəcəyimizi təsvir edən bir fayldır. Bu fayl tətbiqimizin hansı sorğuları idarə edəcəyini, təhlükəsizlik parametrlərini və daha çoxunu müəyyən edir. Əsas etibarilə o, JAR faylından olan manifest faylına bir qədər bənzəyir (bax " Manifest faylları ilə işləmək: Əsaslar "). Manifest faylı Java Tətbiqi (yəni JAR arxivi) ilə necə işləməyi, web.xml isə Java Veb Tətbiqi (yəni WAR arxivi) ilə necə işləməyi izah edir. "Yerləşdirmə Deskriptoru" anlayışı öz-özünə yaranmadı, lakin " Servlet API Spesifikasiyası" sənədində təsvir edilmişdir.". İstənilən Java veb proqramı bu "Servlet API"-dən asılıdır. Bunun API olduğunu başa düşmək vacibdir - yəni bu, bəzi qarşılıqlı əlaqə müqaviləsinin təsviridir. Veb proqramlar müstəqil proqramlar deyil. Onlar veb serverdə işləyirlər. , istifadəçilərlə şəbəkə əlaqəsini təmin edən.Yəni veb server veb proqramlar üçün bir növ “konteyner”dir.Bu məntiqlidir, çünki biz veb proqramın məntiqini, yəni istifadəçinin hansı səhifələri görəcəyini və necə onlar istifadəçinin hərəkətlərinə reaksiya verməlidirlər.Və biz istifadəçiyə mesajın necə göndəriləcəyi, məlumatların baytlarının necə ötürüləcəyi və digər aşağı səviyyəli və çox keyfiyyət tələb edən şeylər üçün kod yazmaq istəmirik.Bundan əlavə, belə çıxır ki, veb proqramlar hamısı fərqlidir, lakin məlumatların ötürülməsi eynidir.Yəni bir milyon proqramçı eyni məqsəd üçün təkrar-təkrar kod yazmalı olacaq.Beləliklə, veb server istifadəçinin bəzi qarşılıqlı əlaqəsinə cavabdehdir. və məlumat mübadiləsi, veb proqram və tərtibatçı isə həmin məlumatların yaradılmasına cavabdehdir. Və bu iki hissəni birləşdirmək üçün, yəni. veb server və veb tətbiqetmədə, onların qarşılıqlı əlaqəsi üçün müqavilə lazımdır, yəni. bunu etmək üçün hansı qaydalara əməl edəcəklər? Müqaviləni bir şəkildə təsvir etmək üçün veb tətbiqi ilə veb server arasındakı qarşılıqlı əlaqənin necə görünməsi lazım olduğunu izah etmək üçün Servlet API icad edilmişdir. Maraqlıdır ki, Spring kimi çərçivələrdən istifadə etsəniz də, hələ də başlıq altında işləyən bir Servlet API var. Yəni siz Spring istifadə edirsiniz və Spring sizin üçün Servlet API ilə işləyir. Belə çıxır ki, bizim veb proqram layihəmiz Servlet API-dən asılı olmalıdır. Bu halda, Servlet API asılılıq olacaq. Bildiyimiz kimi, Gradle sizə layihə asılılıqlarını deklarativ şəkildə təsvir etməyə də imkan verir. Pluginlər asılılıqların necə idarə oluna biləcəyini təsvir edir. Məsələn, Java Gradle Plugin "testImplementation" asılılığın idarə edilməsi metodunu təqdim edir, bu metodda belə bir asılılığın yalnız testlər üçün lazım olduğunu bildirir. Lakin Gradle War Plugin, "providedCompile" asılılığının idarə edilməsi metodunu əlavə edir ki, belə bir asılılıq bizim veb proqramımızın WAR arxivinə daxil edilməyəcək. Nə üçün biz Servlet API-ni WAR arxivimizə daxil etmirik? Çünki Servlet API veb tətbiqimizə veb serverin özü tərəfindən təqdim olunacaq. Əgər veb server Servlet API təmin edirsə, o zaman server servlet konteyneri adlanır. Buna görə də, bizi Servlet API ilə təmin etmək veb serverin məsuliyyətidir və ServletAPI-ni yalnız kodun tərtib edildiyi vaxt təmin etmək bizim məsuliyyətimizdir. Buna görə də providedCompile. Beləliklə, asılılıqlar bloku belə görünəcək:

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

Beləliklə, web.xml faylına qayıdaq. Varsayılan olaraq, Gradle heç bir Yerləşdirmə Deskriptoru yaratmır, ona görə də bunu özümüz etməliyik. Gəlin bir kataloq yaradaq src/main/webapp/WEB-INFvə orada biz adlı XML faylı yaradaq web.xml. İndi gəlin "Java Servlet Spesifikasiyası"nın özünü və " CHAPTER 14 Deployment Descriptor " bölməsini açaq. "14.3 Yerləşdirmə Deskriptorunda" qeyd edildiyi kimi, Yerləşdirmə Deskriptorunun XML sənədi http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd sxemi ilə təsvir edilmişdir . XML sxemi sənədin hansı elementlərdən ibarət ola biləcəyini və onların hansı ardıcıllıqla görünməli olduğunu təsvir edir. Hansılar məcburidir, hansılar yoxdur. Ümumiyyətlə, o, sənədin strukturunu təsvir edir və XML sənədinin düzgün tərtib edilib-edilmədiyini yoxlamağa imkan verir. İndi " 14.5 Nümunələr " fəslindəki nümunədən istifadə edək , lakin sxem 3.1 versiyası üçün göstərilməlidir, yəni.

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

Boş olanımız web.xmlbelə görünəcək:

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

İndi JAAS istifadə edərək qoruyacağımız servleti təsvir edək. Əvvəllər Gradle bizim üçün App sinifini yaratmışdı. Gəlin onu servletə çevirək. " FƏSİL 2 Servlet İnterfeysi " ndə qeyd edildiyi kimi , " Əksər məqsədlər üçün Tərtibatçılar öz servletlərini həyata keçirmək üçün HttpServlet-i genişləndirəcəklər ", yəni sinfi servlet etmək üçün siz bu sinfi miras almalısınız 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());
    }
}

Dediyimiz kimi, Servlet API server və veb tətbiqimiz arasında müqavilədir. Bu müqavilə bizə təsvir etməyə imkan verir ki, istifadəçi serverlə əlaqə saxladıqda server istifadəçidən obyekt şəklində sorğu yaradacaq HttpServletRequestvə onu servletə ötürəcək. O, həmçinin servleti obyektlə təmin edəcək HttpServletResponseki, servlet istifadəçi üçün ona cavab yaza bilsin. Servlet işləməyi başa vurduqdan sonra server ona əsaslanan cavabı istifadəçiyə təqdim edə biləcək HttpServletResponse. Yəni servlet birbaşa istifadəçi ilə deyil, yalnız serverlə əlaqə saxlayır. Serverin servletimiz olduğunu və ondan hansı sorğular üçün istifadə edilməli olduğunu bilməsi üçün yerləşdirmə deskriptorunda bu barədə serverə məlumat verməliyik:

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

Bu halda, bütün sorğular sinifə uyğun gələn /secretadla bir servletimizə ünvanlanmayacaq . Daha əvvəl dediyimiz kimi, veb tətbiqi yalnız veb serverdə yerləşdirilə bilər. Veb server ayrıca quraşdırıla bilər (müstəqil). Ancaq bu baxışın məqsədləri üçün alternativ bir seçim uyğundur - quraşdırılmış serverdə işləmək. Bu o deməkdir ki, server proqramlı şəkildə yaradılacaq və işə salınacaq (plugin bunu bizim üçün edəcək) və eyni zamanda bizim veb proqramımız orada yerləşdiriləcək. Gradle qurma sistemi bu məqsədlər üçün " Gradle Gretty Plugin " plaginindən istifadə etməyə imkan verir:appjaas.App

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

Bundan əlavə, Gretty plagininin yaxşı sənədləri var . Gretty plagininin müxtəlif veb serverlər arasında keçid etməyə imkan verməsi ilə başlayaq. Bu, sənədlərdə daha ətraflı təsvir edilmişdir: " Servlet konteynerləri arasında keçid ". Gəlin Tomcat-a keçək, çünki... istifadədə ən populyarlardan biridir, həmçinin yaxşı sənədlərə və çoxlu nümunələrə və təhlil edilmiş problemlərə malikdir:

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

İndi biz "gradle appRun" proqramını işə sala bilərik və sonra veb proqramımız http://localhost:8080/jaas/secret ünvanında mövcud olacaq. Servlet konteynerinin Tomcat tərəfindən seçildiyini yoxlamaq (bax #1) və veb proqramımızın hansı ünvanda mövcud olduğunu yoxlamaq vacibdir (bax #2).

İdentifikasiyası

Doğrulama parametrləri çox vaxt iki hissədən ibarətdir: server tərəfindəki parametrlər və bu serverdə işləyən veb proqram tərəfindəki parametrlər. Veb tətbiqinin təhlükəsizlik parametrləri veb serverin təhlükəsizlik parametrləri ilə qarşılıqlı əlaqədə ola bilməz, əgər bundan başqa heç bir səbəbdən veb tətbiqi veb server ilə qarşılıqlı əlaqədə ola bilməzsə. Tomcat-a keçməyimiz əbəs deyildi, çünki... Tomcat yaxşı təsvir edilmiş arxitekturaya malikdir (bax " Apache Tomcat 8 Architecture "). Bu arxitekturanın təsvirindən aydın olur ki, Tomcat bir veb server olaraq veb tətbiqini “ Tomcat Kontekst ” adlanan müəyyən bir kontekst kimi təqdim edir. Bu kontekst hər bir veb proqrama digər veb proqramlardan təcrid olunmuş öz parametrlərinə malik olmağa imkan verir. Bundan əlavə, veb tətbiqi bu kontekstin parametrlərinə təsir göstərə bilər. Çevik və rahat. Daha dərindən başa düşmək üçün " Tomcat Kontekst Konteynerlərini Anlamaq " məqaləsini və Tomcat sənədləri bölməsini " Kontekst Konteyneri " ilə tanış etməyi tövsiyə edirik. Yuxarıda qeyd edildiyi kimi, veb proqramımız /META-INF/context.xml. Təsir edə biləcəyimiz çox vacib parametrlərdən biri də Təhlükəsizlik Aləmləridir. Security Realms bir növ “təhlükəsizlik sahəsidir”. Xüsusi təhlükəsizlik parametrlərinin göstərildiyi sahə. Müvafiq olaraq, Təhlükəsizlik Aləmindən istifadə edərkən biz bu Aləm üçün müəyyən edilmiş təhlükəsizlik parametrlərini tətbiq edirik. Təhlükəsizlik Realms bir konteyner tərəfindən idarə olunur, yəni. veb proqramımız deyil, veb server. Biz yalnız serverə tətbiqimizə hansı təhlükəsizlik sahəsinin genişləndirilməsi lazım olduğunu deyə bilərik. " Səltənət Komponenti " bölməsindəki Tomcat sənədləri səltənəti istifadəçilər və onların autentifikasiyanı həyata keçirmək üçün rolları haqqında məlumat toplusu kimi təsvir edir. Tomcat müxtəlif Təhlükəsizlik Realm tətbiqləri dəsti təqdim edir, bunlardan biri də " Jaas Realm "dır. Bir az terminologiyanı başa düşdükdən sonra faylda Tomcat Kontekstini təsvir edək /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- tətbiqin adı. Tomcat bu adı proqramda göstərilən adlarla uyğunlaşdırmağa çalışacaq configFile. configFile- bu "giriş konfiqurasiya faylıdır". Bunun nümunəsini JAAS sənədlərində görmək olar: " Əlavə B: Giriş Konfiqurasiyalarının Nümunəsi ". Bundan əlavə, bu faylın ilk növbədə resurslarda axtarılması vacibdir. Buna görə də bizim veb proqramımız bu faylı özü təmin edə bilər. Atributlar userClassNamesvə roleClassNamesistifadəçinin əsasını təmsil edən siniflərin göstəricisini ehtiva edir. JAAS "istifadəçi" və "rol" anlayışlarını iki fərqli anlayış kimi ayırır java.security.Principal. Yuxarıdakı sinifləri təsvir edək. İstifadəçi prinsipi üçün ən sadə tətbiqi yaradaq:

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

Üçün eyni tətbiqi təkrarlayacağıq RolePrincipal. İnterfeysdən göründüyü kimi, Principal üçün əsas şey Direktoru təmsil edən bəzi adı (və ya ID) saxlamaq və qaytarmaqdır. İndi bizim Təhlükəsizlik Aləmimiz var, əsas dərslərimiz var. Faylı " configFile" atributundan doldurmaq qalır, aka login configuration file. Onun təsviri Tomcat sənədlərində tapıla bilər: " The Realm Component ". Yəni biz JAAS Login Config parametrini veb tətbiqimizin resurslarına yerləşdirə bilərik və Tomcat Context sayəsində biz ondan istifadə edə biləcəyik. Bu fayl ClassLoader üçün resurs kimi mövcud olmalıdır, ona görə də onun yolu belə olmalıdır: \src\main\resources\jaas.config Gəlin bu faylın məzmununu təyin edək:

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

Qeyd etmək lazımdır ki, context.xmleyni ad burada və içərisində istifadə olunur. Bu, Təhlükəsizlik Sahəsini LoginModule ilə əlaqələndirir. Beləliklə, Tomcat Context bizə hansı siniflərin rəhbərləri təmsil etdiyini, həmçinin hansı LoginModule-dan istifadə edəcəyimizi söylədi. Etməli olduğumuz tək şey bu LoginModule-u həyata keçirməkdir. LoginModule bəlkə də JAAS-da ən maraqlı şeylərdən biridir. Rəsmi sənədlər LoginModule-nin hazırlanmasında bizə kömək edəcək: " Java Authentication and Authorization Service (JAAS): LoginModule Developer's Guide ". Giriş modulunu həyata keçirək. İnterfeys həyata keçirən bir sinif yaradaq LoginModule:

public class JaasLoginModule implements LoginModule {
}

Əvvəlcə işə salma üsulunu təsvir edirik 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 üsul yadda saxlayacaq Subject, biz onu daha sonra autentifikasiya edəcəyik və rəhbərlər haqqında məlumatla dolduracağıq. CallbackHandlerBizə verilən gələcək istifadə üçün də qənaət edəcəyik . Yardımla CallbackHandlerbir az sonra autentifikasiya mövzusu haqqında müxtəlif məlumatları tələb edə bilərik. Bu barədə ətraflı CallbackHandlersənədlərin müvafiq bölməsində oxuya bilərsiniz: " JAAS Reference Guide: CallbackHandler ". loginSonra, identifikasiya metodu icra olunur Subject. Bu autentifikasiyanın birinci mərhələsidir:

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

loginDəyişməməyimiz vacibdir Subject. Bu cür dəyişikliklər yalnız təsdiqləmə metodunda baş verməlidir commit. Sonra, uğurlu autentifikasiyanın təsdiqlənməsi metodunu təsvir etməliyik:

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

metodu ayırmaq qəribə görünə bilər loginvə commit. Amma məsələ ondadır ki, giriş modulları birləşdirilə bilər. Uğurlu autentifikasiya üçün bir neçə giriş modulunun uğurla işləməsi lazım ola bilər. Və yalnız bütün lazımi modullar işləmişdirsə, dəyişiklikləri qeyd edin. Bu autentifikasiyanın ikinci mərhələsidir. abortvə üsulları ilə bitirək 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;
}

Metod abortautentifikasiyanın birinci mərhələsi uğursuz olduqda çağırılır. Metod logoutsistem sistemdən çıxdıqda çağırılır. Özümüzü həyata keçirdikdən Login Modulevə konfiqurasiya etdikdən sonra, indi konkret birini istifadə etmək istədiyimizi Security Realmgöstərməliyik : web.xmlLogin Config

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

Biz Təhlükəsizlik Sahəmizin adını təyin etdik və Doğrulama Metodunu - BASIC-i təyin etdik. Bu, Servlet API-də " 13.6 Doğrulama " bölməsində təsvir edilən autentifikasiya növlərindən biridir . n qaldı