JAAS - Introduzione alla tecnologia (Parte 1)

La sicurezza dell'accesso è stata implementata in Java già da molto tempo e l'architettura per fornire questa sicurezza si chiama JAAS - Java Authentication and Authorization Service. Questa recensione cercherà di svelare il mistero di cosa sia l'autenticazione, l'autorizzazione e cosa abbia a che fare JAAS con essa. In che modo JAAS è amico dell'API Servlet e dove hanno problemi nella loro relazione.

introduzione

In questa recensione vorrei discutere un argomento come la sicurezza delle applicazioni web. Java dispone di diverse tecnologie che garantiscono la sicurezza:

• " Java SE Platform Security Architecture ", maggiori dettagli possono essere letti nella Guida di Oracle: " JavaTM SE Platform Security Architecture ". Questa architettura descrive come dobbiamo proteggere le nostre applicazioni Java nell'ambiente runtime Java SE. Ma non è questo l’argomento della nostra conversazione oggi.

• " Java Cryptography Architecture " è un'estensione Java che descrive la crittografia dei dati. Puoi leggere di più su questa estensione su JavaRush nella recensione " Java Cryptography Architecture: First conoscence " o nella Guida di Oracle: " Java Cryptography Architecture (JCA) Reference Guide ".

Ma la nostra conversazione di oggi riguarderà un'altra tecnologia, chiamata "Java Authentication and Authorization Service (JAAS)". È lei che descrive cose importanti come l'autenticazione e l'autorizzazione. Diamo un'occhiata a questo in modo più dettagliato.

JAAS

JAAS è un'estensione di Java SE ed è descritta nella Guida di riferimento Java Authentication and Authorization Service (JAAS) . Come suggerisce il nome della tecnologia, JAAS descrive come dovrebbero essere eseguite l'autenticazione e l'autorizzazione:

• " Autenticazione ": Tradotto dal greco, "authentikos" significa "reale, genuino". Cioè, l'autenticazione è una prova di autenticità. Che chiunque venga autenticato è veramente chi dice di essere.

• " Autorizzazione ": tradotto dall'inglese significa "permesso". Cioè, l'autorizzazione è il controllo dell'accesso eseguito dopo l'autenticazione riuscita.

Cioè, JAAS consiste nel determinare chi richiede l'accesso a una risorsa e nel decidere se può ottenere tale accesso. Una piccola analogia dalla vita: stai guidando lungo la strada e un ispettore ti ferma. Si prega di fornire documenti - autenticazione. Puoi guidare un'auto con documenti - autorizzazione. Oppure, ad esempio, vuoi comprare alcolici in un negozio. Per prima cosa ti viene richiesto il passaporto: l'autenticazione. Successivamente, in base alla tua età, verrà deciso se sei idoneo ad acquistare alcolici. Questa è l'autorizzazione. Nelle applicazioni web, l'accesso come utente (immettendo nome utente e password) costituisce l'autenticazione. E determinare quali pagine puoi aprire è determinato dall'autorizzazione. È qui che ci viene in aiuto “Java Authentication and Authorization Service (JAAS)”. Quando si considera JAAS, è importante comprendere diversi concetti chiave descritti da JAAS: oggetto, entità, credenziali. L'oggetto è l'oggetto dell'autenticazione. Cioè, è portatore o detentore di diritti. Nella documentazione, Oggetto è definito come l'origine di una richiesta per eseguire un'azione. L'argomento o la fonte deve essere in qualche modo descritto e per questo scopo viene utilizzato Principal, che in russo a volte viene chiamato anche principale. Cioè ogni Principale è una rappresentazione di un Soggetto da un certo punto di vista. Per renderlo più chiaro, facciamo un esempio: una certa persona è un Soggetto. E possono agire come Principali:

• la sua patente di guida come rappresentazione di una persona come utente della strada
• il suo passaporto, come rappresentazione di una persona come cittadino del suo paese
• il suo passaporto straniero, come rappresentazione di una persona come partecipante alle relazioni internazionali
• la sua tessera della biblioteca nella biblioteca, come rappresentazione di una persona come lettore collegata alla biblioteca

Inoltre, il Soggetto ha una serie di "Credenziali", che significa "identità" in inglese. È così che il Soggetto conferma di essere lui. Ad esempio, la password dell'utente può essere la credenziale. Oppure qualsiasi oggetto con cui l'utente possa confermare di essere davvero lui. Vediamo ora come viene utilizzato JAAS nelle applicazioni web.

applicazione web

Quindi, abbiamo bisogno di un'applicazione web. Il sistema di creazione automatica del progetto Gradle ci aiuterà a crearlo. Grazie all'utilizzo di Gradle potremo, eseguendo piccoli comandi, assemblare un progetto Java nel formato di cui abbiamo bisogno, creare automaticamente la struttura di directory necessaria e molto altro ancora. Puoi leggere ulteriori informazioni su Gradle nella breve panoramica: " A Brief Introduction to Gradle " o nella documentazione ufficiale " Gradle Getting Started ". Dobbiamo inizializzare il progetto (Initialization), e per questo scopo Gradle ha un plugin speciale: “ Gradle Init Plugin ” (Init è l'abbreviazione di Inizializzazione, facile da ricordare). Per utilizzare questo plugin, esegui il comando sulla riga di comando:

gradle init --type java-application

Dopo il completamento con successo, avremo un progetto Java. Apriamo ora lo script di build del nostro progetto per la modifica. Uno script di build è un file chiamato build.gradle, che descrive le sfumature della build dell'applicazione. Da qui il nome, build script. Possiamo dire che questo è uno script di creazione del progetto. Gradle è uno strumento davvero versatile, le cui funzionalità di base sono ampliate con i plugin. Quindi prestiamo innanzitutto attenzione al blocco “plugins”:

plugins {
    id 'java'
    id 'application'
}

Di default Gradle, in accordo con quanto specificato " --type java-application", ha predisposto un insieme di alcuni plugin core, cioè quei plugin che sono inclusi nella distribuzione di Gradle stessa. Se vai alla sezione "Docs" (ovvero documentazione) sul sito Web gradle.org , a sinistra nell'elenco degli argomenti nella sezione "Riferimento" vediamo la sezione " Plugin core ", ad es. sezione con una descrizione di questi plugin di base. Scegliamo esattamente i plugin di cui abbiamo bisogno e non quelli che Gradle ha generato per noi. Secondo la documentazione, il " Gradle Java Plugin " fornisce operazioni di base con il codice Java, come la compilazione del codice sorgente. Inoltre, secondo la documentazione, il " plugin dell'applicazione Gradle " ci fornisce gli strumenti per lavorare con l '"applicazione JVM eseguibile", ad es. con un'applicazione Java che può essere avviata come applicazione autonoma (ad esempio, un'applicazione console o un'applicazione con la propria interfaccia utente). Si scopre che non abbiamo bisogno del plugin "applicazione", perché... non abbiamo bisogno di un'app autonoma, abbiamo bisogno di un'app Web. Eliminiamolo. Così come l'impostazione “mainClassName”, nota solo a questo plugin. Inoltre, nella stessa sezione " Packaging e distribuzione " in cui è stato fornito il collegamento alla documentazione del plugin dell'applicazione, è presente un collegamento al plugin Gradle War. Gradle War Plugin , come indicato nella documentazione, fornisce il supporto per la creazione di applicazioni web Java in formato war. Nel formato WAR significa che invece di un archivio JAR, verrà creato un archivio WAR. Sembra che questo sia ciò di cui abbiamo bisogno. Inoltre, come dice la documentazione, "Il plugin War estende il plugin Java". Cioè possiamo sostituire il plugin Java con il plugin war. Pertanto, il nostro blocco plugin alla fine sarà simile a questo:

plugins {
    id 'war'
}

Anche nella documentazione del "Gradle War Plugin" si dice che il plugin utilizza un "Layout del progetto" aggiuntivo. Il layout è tradotto dall'inglese come posizione. Cioè, il plugin war per impostazione predefinita prevede l'esistenza di una determinata posizione di file che utilizzerà per i suoi compiti. Utilizzerà la seguente directory per archiviare i file dell'applicazione web: src/main/webapp Il comportamento del plugin è descritto come segue: Cioè, il plugin prenderà in considerazione i file da questa posizione durante la creazione dell'archivio WAR della nostra applicazione web. Inoltre, la documentazione del plugin Gradle War afferma che questa directory sarà la "radice dell'archivio". E già al suo interno possiamo creare una directory WEB-INF e aggiungere lì il file web.xml. Che tipo di file è questo? web.xml- questo è un "descrittore di distribuzione" o "descrittore di distribuzione". Questo è un file che descrive come configurare la nostra applicazione web affinché funzioni. Questo file specifica quali richieste gestirà la nostra applicazione, le impostazioni di sicurezza e molto altro. Fondamentalmente, è in qualche modo simile a un file manifest di un file JAR (vedere " Lavorare con i file manifest: nozioni di base "). Il file Manifest spiega come lavorare con un'applicazione Java (ovvero un archivio JAR) e web.xml spiega come lavorare con un'applicazione Web Java (ovvero un archivio WAR). Il concetto stesso di "descrittore di distribuzione" non è nato da solo, ma è descritto nel documento " Specifica API Servlet"". Qualsiasi applicazione Web Java dipende da questa "API Servlet". È importante capire che questa è un'API, ovvero è una descrizione di un contratto di interazione. Le applicazioni Web non sono applicazioni indipendenti. Funzionano su un server Web , che fornisce la comunicazione di rete con gli utenti. Cioè, un server web è una sorta di "contenitore" per applicazioni web. Questo è logico, perché vogliamo scrivere la logica di un'applicazione web, ad es. quali pagine vedrà l'utente e come dovrebbero reagire alle azioni dell'utente. E non vogliamo scrivere codice per come verrà inviato un messaggio all'utente, come verranno trasferiti i byte di informazioni e altre cose di basso livello e che richiedono molta qualità. Inoltre, si scopre che le applicazioni web sono tutte diverse, ma il trasferimento dei dati è lo stesso. Cioè, un milione di programmatori dovrebbero scrivere codice per lo stesso scopo più e più volte. Quindi il server web è responsabile di parte dell'interazione dell'utente e lo scambio di dati, e l'applicazione web e lo sviluppatore sono responsabili della generazione di tali dati. E per collegare queste due parti, ad es. server web e applicazione web, è necessario un contratto per la loro interazione, ad es. quali regole seguiranno per farlo? Per descrivere in qualche modo il contratto, come dovrebbe essere l'interazione tra un'applicazione web e un server web, è stata inventata l'API Servlet. È interessante notare che, anche se utilizzi framework come Spring, c'è ancora un'API Servlet in esecuzione sotto il cofano. Cioè, usi Spring e Spring funziona con l'API Servlet per te. Risulta che il nostro progetto di applicazione web deve dipendere dall'API Servlet. In questo caso, l'API Servlet sarà una dipendenza. Come sappiamo, Gradle consente anche di descrivere le dipendenze del progetto in modo dichiarativo. I plugin descrivono come possono essere gestite le dipendenze. Ad esempio, il plugin Java Gradle introduce un metodo di gestione delle dipendenze "testImplementation", che afferma che tale dipendenza è necessaria solo per i test. Ma il plugin Gradle War aggiunge un metodo di gestione delle dipendenze “providedCompile”, che dice che tale dipendenza non sarà inclusa nell'archivio WAR della nostra applicazione web. Perché non includiamo l'API Servlet nel nostro archivio WAR? Perché l'API Servlet verrà fornita alla nostra applicazione web dal server web stesso. Se un server Web fornisce un'API Servlet, il server viene chiamato contenitore servlet. Pertanto, è responsabilità del server web fornirci la Servlet API, ed è nostra responsabilità fornire la ServletAPI solo al momento della compilazione del codice. Ecco perché providedCompile. Pertanto, il blocco delle dipendenze sarà simile al seguente:

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

Torniamo quindi al file web.xml. Per impostazione predefinita, Gradle non crea alcun descrittore di distribuzione, quindi dobbiamo farlo noi stessi. Creiamo una directory src/main/webapp/WEB-INFe in essa creeremo un file XML chiamato web.xml. Ora apriamo la "Specifica servlet Java" stessa e il capitolo " CAPITOLO 14 Deployment Descriptor ". Come indicato in "14.3 Deployment Descriptor", il documento XML del Deployment Descriptor è descritto dallo schema http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd . Uno schema XML descrive di quali elementi può essere costituito un documento e in quale ordine dovrebbero apparire. Quali sono obbligatori e quali no. In generale descrive la struttura del documento e permette di verificare se il documento XML è composto correttamente. Usiamo ora l'esempio dal capitolo " 14.5 Esempi ", ma lo schema deve essere specificato per la versione 3.1, cioè

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

Il nostro vuoto web.xmlsarà simile a questo:

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

Descriviamo ora la servlet che proteggeremo utilizzando JAAS. In precedenza, Gradle generava per noi la classe App. Trasformiamolo in un servlet. Come affermato nelle specifiche nel " CAPITOLO 2 L'interfaccia Servlet ", che " Per la maggior parte degli scopi, gli sviluppatori estenderanno HttpServlet per implementare i loro servlet ", ovvero, per rendere una classe una servlet, è necessario ereditare questa classe da 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());
    }
}

Come abbiamo detto, la Servlet API è un contratto tra il server e la nostra applicazione web. Questo contratto ci consente di descrivere che quando un utente contatta il server, il server genererà una richiesta da parte dell'utente sotto forma di oggetto HttpServletRequeste la trasmetterà al servlet. Fornirà inoltre al servlet un oggetto HttpServletResponsein modo che il servlet possa scrivere una risposta per l'utente. Una volta che la servlet ha terminato l'esecuzione, il server sarà in grado di fornire all'utente una risposta basata su di essa HttpServletResponse. Cioè la servlet non comunica direttamente con l'utente, ma solo con il server. Affinché il server sappia che abbiamo una servlet e per quali richieste deve essere utilizzata, dobbiamo comunicarlo al server nel descrittore di distribuzione:

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

In questo caso, tutte le richieste /secretnon verranno indirizzate alla nostra servlet per nome app, che corrisponde alla classe jaas.App. Come abbiamo detto prima, un'applicazione web può essere distribuita solo su un server web. Il web server può essere installato separatamente (standalone). Ma ai fini di questa recensione, è adatta un'opzione alternativa: l'esecuzione su un server incorporato. Ciò significa che il server verrà creato e avviato in modo programmatico (il plugin lo farà per noi) e allo stesso tempo la nostra applicazione web verrà distribuita su di esso. Il sistema di compilazione Gradle ti consente di utilizzare il plugin " Gradle Gretty Plugin " per questi scopi:

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

Inoltre, il plugin Gretty ha una buona documentazione . Cominciamo dal fatto che il plugin Gretty ti consente di passare da un server web all'altro. Ciò è descritto più dettagliatamente nella documentazione: " Commutazione tra servlet container ". Passiamo a Tomcat, perché... è uno dei più popolari in uso e ha anche una buona documentazione e molti esempi e problemi analizzati:

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

Ora possiamo eseguire "gradle appRun" e la nostra applicazione web sarà disponibile su http://localhost:8080/jaas/secret È importante verificare che il contenitore servlet sia selezionato da Tomcat (vedi #1) e verificare a quale indirizzo è disponibile la nostra applicazione web (vedi #2).

Autenticazione

Le impostazioni di autenticazione sono spesso costituite da due parti: impostazioni sul lato server e impostazioni sul lato dell'applicazione web che viene eseguita su questo server. Le impostazioni di sicurezza di un'applicazione web non possono non interagire con le impostazioni di sicurezza del server web, se non altro perché un'applicazione web non può non interagire con il server web. Non è stato invano che siamo passati a Tomcat, perché... Tomcat ha un'architettura ben descritta (vedere " Architettura Apache Tomcat 8 "). Dalla descrizione di questa architettura è chiaro che Tomcat, in quanto server web, rappresenta l'applicazione web come un determinato contesto, che viene chiamato “ Tomcat Context ”. Questo contesto consente a ciascuna applicazione Web di avere le proprie impostazioni, isolate dalle altre applicazioni Web. Inoltre, l'applicazione web può influenzare le impostazioni di questo contesto. Flessibile e conveniente. Per una comprensione più approfondita, consigliamo di leggere l'articolo " Understanding Tomcat Context Containers " e la sezione della documentazione di Tomcat " The Context Container ". Come affermato in precedenza, la nostra applicazione Web può influenzare il contesto Tomcat della nostra applicazione utilizzando un file /META-INF/context.xml. E una delle impostazioni molto importanti che possiamo influenzare è Security Realms. Security Realms è una sorta di “area di sicurezza”. Un'area per la quale sono specificate impostazioni di sicurezza specifiche. Di conseguenza, quando si utilizza un ambito di sicurezza, applichiamo le impostazioni di sicurezza definite per questo ambito. Gli ambiti di sicurezza sono gestiti da un contenitore, ovvero server web, non la nostra applicazione web. Possiamo solo dire al server quale ambito di sicurezza deve essere esteso alla nostra applicazione. La documentazione di Tomcat nella sezione " Il componente Realm " descrive un Realm come una raccolta di dati sugli utenti e sui loro ruoli per eseguire l'autenticazione. Tomcat fornisce una serie di diverse implementazioni di Security Realm, una delle quali è " Jaas Realm ". Dopo aver compreso un po' la terminologia, descriviamo il contesto Tomcat nel file /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- Nome dell'applicazione. Tomcat proverà a far corrispondere questo nome ai nomi specificati nel file configFile. configFile- questo è il "file di configurazione di accesso". Un esempio di ciò può essere visto nella documentazione JAAS: " Appendice B: Esempi di configurazioni di accesso ". Inoltre, è importante che questo file venga cercato prima nelle risorse. Pertanto, la nostra applicazione Web può fornire autonomamente questo file. Gli attributi userClassNamese roleClassNamescontengono l'indicazione delle classi che rappresentano il principale dell'utente. JAAS separa i concetti di "utente" e "ruolo" come due concetti diversi java.security.Principal. Descriviamo le classi di cui sopra. Creiamo l'implementazione più semplice per l'entità utente:

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

Ripeteremo esattamente la stessa implementazione per RolePrincipal. Come puoi vedere dall'interfaccia, la cosa principale per Principal è memorizzare e restituire un nome (o ID) che rappresenti il ​​Principal. Ora, abbiamo un regno della sicurezza, abbiamo classi principali. Resta da riempire il file dall'attributo " configFile", ovvero login configuration file. La sua descrizione può essere trovata nella documentazione di Tomcat: " The Realm Component ". Possiamo cioè inserire l'impostazione JAAS Login Config nelle risorse della nostra applicazione web e grazie a Tomcat Context potremo utilizzarla. Questo file deve essere disponibile come risorsa per ClassLoader, quindi il suo percorso dovrebbe essere così: \src\main\resources\jaas.config Impostiamo il contenuto di questo file:

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

Vale la pena notare che context.xmlqui e in è usato lo stesso nome. Questo associa l'ambito di sicurezza al LoginModule. Quindi, Tomcat Context ci ha detto quali classi rappresentano i principali e quale LoginModule utilizzare. Tutto quello che dobbiamo fare è implementare questo LoginModule. LoginModule è forse una delle cose più interessanti di JAAS. La documentazione ufficiale ci aiuterà nello sviluppo di LoginModule: " Java Authentication and Authorization Service (JAAS): LoginModule Developer's Guide ". Implementiamo il modulo di login. Creiamo una classe che implementa l'interfaccia LoginModule:

public class JaasLoginModule implements LoginModule {
}

Per prima cosa descriviamo il metodo di inizializzazione 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;
}

Questo metodo salverà i file Subject, che autenticheremo ulteriormente e riempiremo con le informazioni sui principali. Salveremo anche per un uso futuro CallbackHandler, che ci viene dato. Con l'aiuto CallbackHandlerpossiamo richiedere un po' più tardi varie informazioni sull'oggetto dell'autenticazione. Puoi leggere ulteriori informazioni a riguardo CallbackHandlernella sezione corrispondente della documentazione: " JAAS Reference Guide: CallbackHandler ". Successivamente viene eseguito il metodo logindi autenticazione Subject. Questa è la prima fase dell'autenticazione:

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

È importante loginnon modificare il file Subject. Tali modifiche dovrebbero verificarsi solo nel metodo di conferma commit. Successivamente, dobbiamo descrivere il metodo per confermare l'avvenuta autenticazione:

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

Può sembrare strano separare il metodo logine commit. Ma il punto è che i moduli di accesso possono essere combinati. E per un'autenticazione riuscita potrebbe essere necessario che diversi moduli di accesso funzionino correttamente. E solo se tutti i moduli necessari hanno funzionato, salva le modifiche. Questa è la seconda fase dell'autenticazione. Concludiamo con i metodi aborte 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;
}

Il metodo abortviene chiamato quando la prima fase di autenticazione fallisce. Il metodo logoutviene chiamato quando il sistema si disconnette. Dopo aver implementato il nostro Login Modulee averlo configurato Security Realm, ora dobbiamo indicare web.xmlil fatto che vogliamo utilizzarne uno specifico Login Config:

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

Abbiamo specificato il nome del nostro ambito di sicurezza e specificato il metodo di autenticazione: BASIC. Questo è uno dei tipi di autenticazione descritti nell'API Servlet nella sezione " 13.6 Autenticazione ". Rimasto n