JAAS - Introduction à la technologie (Partie 1)

La sécurité des accès est implémentée en Java depuis assez longtemps et l'architecture permettant d'assurer cette sécurité s'appelle JAAS - Java Authentication and Authorization Service. Cette revue tentera de percer le mystère de ce qu'est l'authentification, l'autorisation et ce que JAAS a à voir avec cela. Comment JAAS est ami avec l'API Servlet et où ils ont des problèmes dans leur relation.

Introduction

Dans cette revue, j'aimerais aborder un sujet tel que la sécurité des applications Web. Java dispose de plusieurs technologies qui assurent la sécurité :

• " Java SE Platform Security Architecture ", dont plus de détails peuvent être lus dans le Guide d'Oracle : " JavaTM SE Platform Security Architecture ". Cette architecture décrit comment nous devons sécuriser nos applications Java dans l'environnement d'exécution Java SE. Mais ce n’est pas le sujet de notre conversation d’aujourd’hui.

• " Java Cryptography Architecture " est une extension Java qui décrit le cryptage des données. Vous pouvez en savoir plus sur cette extension sur JavaRush dans la revue « Java Cryptography Architecture : First connaissance » ou dans le Guide d'Oracle : « Java Cryptography Architecture (JCA) Reference Guide ».

Mais notre conversation d’aujourd’hui portera sur une autre technologie, appelée « Java Authentication and Authorization Service (JAAS) ». C'est elle qui décrit des choses aussi importantes que l'authentification et l'autorisation. Regardons cela plus en détail.

JAAS

JAAS est une extension de Java SE et est décrit dans le Guide de référence du service d'authentification et d'autorisation Java (JAAS) . Comme le nom de la technologie l'indique, JAAS décrit comment l'authentification et l'autorisation doivent être effectuées :

• « Authentification » : Traduit du grec, « authentikos » signifie « réel, authentique ». Autrement dit, l'authentification est un test d'authenticité. Que celui qui est authentifié est vraiment celui qu’il prétend être.

• « Autorisation » : traduit de l'anglais signifie « autorisation ». Autrement dit, l'autorisation est un contrôle d'accès effectué après une authentification réussie.

Autrement dit, JAAS consiste à déterminer qui demande l'accès à une ressource et à prendre une décision quant à savoir s'il peut obtenir cet accès. Une petite analogie avec la vie : vous conduisez sur la route et un inspecteur vous arrête. Veuillez fournir des documents - authentification. Pouvez-vous conduire une voiture avec des documents - autorisation. Ou, par exemple, vous souhaitez acheter de l'alcool dans un magasin. Tout d'abord, on vous demande un passeport - authentification. Ensuite, en fonction de votre âge, il est décidé si vous êtes éligible à l'achat d'alcool. C'est une autorisation. Dans les applications Web, la connexion en tant qu'utilisateur (saisie d'un nom d'utilisateur et d'un mot de passe) constitue une authentification. Et la détermination des pages que vous pouvez ouvrir est déterminée par autorisation. C'est là que « le service d'authentification et d'autorisation Java (JAAS) » nous aide. Lorsque vous envisagez JAAS, il est important de comprendre plusieurs concepts clés décrits par JAAS : sujet, principes et informations d'identification. Le sujet est le sujet de l'authentification. C'est-à-dire qu'il est porteur ou titulaire de droits. Dans la documentation, le sujet est défini comme la source d'une demande d'exécution d'une action. Le sujet ou la source doit être décrit d'une manière ou d'une autre et à cette fin, on utilise le principal, qui en russe est aussi parfois appelé principal. Autrement dit, chaque Principal est une représentation d'un Sujet d'un certain point de vue. Pour que ce soit plus clair, donnons un exemple : une certaine personne est un sujet. Et les personnes suivantes peuvent agir en tant que directeurs :

• son permis de conduire comme représentation d'une personne en tant qu'usager de la route
• son passeport, en tant que représentation d'une personne en tant que citoyen de son pays
• son passeport étranger, en tant que représentation d'une personne en tant que participant aux relations internationales
• sa carte de bibliothèque dans la bibliothèque, comme représentation d'une personne en tant que lecteur attaché à la bibliothèque

De plus, le sujet dispose d'un ensemble de « Credential », qui signifie « identité » en anglais. C'est ainsi que le Sujet confirme qu'il est bien lui. Par exemple, le mot de passe de l'utilisateur peut être le Credential. Ou tout objet avec lequel l’utilisateur peut confirmer qu’il est bien lui. Voyons maintenant comment JAAS est utilisé dans les applications Web.

application Web

Nous avons donc besoin d'une application Web. Le système de création automatique de projets Gradle nous aidera à le créer. Grâce à l'utilisation de Gradle, nous pouvons, en exécutant de petites commandes, assembler un projet Java au format dont nous avons besoin, créer automatiquement la structure de répertoires nécessaire, et bien plus encore. Vous pouvez en savoir plus sur Gradle dans le bref aperçu : " Une brève introduction à Gradle " ou dans la documentation officielle " Gradle Getting Started ". Nous devons initialiser le projet (Initialisation), et pour cela Gradle dispose d'un plugin spécial : « Gradle Init Plugin » (Init est l'abréviation de Initialization, facile à retenir). Pour utiliser ce plugin, exécutez la commande sur la ligne de commande :

gradle init --type java-application

Après avoir réussi, nous aurons un projet Java. Ouvrons maintenant le script de construction de notre projet pour l'éditer. Un script de build est un fichier appelé build.gradle, qui décrit les nuances de la build de l'application. D'où le nom build script. On peut dire qu'il s'agit d'un script de construction de projet. Gradle est un outil très polyvalent dont les capacités de base sont étendues grâce à des plugins. Alors, tout d’abord, faisons attention au bloc « plugins » :

plugins {
    id 'java'
    id 'application'
}

Par défaut, Gradle, conformément à ce que nous avons spécifié " --type java-application", a mis en place un ensemble de certains plugins de base, c'est-à-dire les plugins inclus dans la distribution de Gradle elle-même. Si vous allez dans la section "Docs" (c'est-à-dire la documentation) sur le site gradle.org , alors à gauche dans la liste des sujets de la section "Référence", nous voyons la section " Core Plugins ", c'est-à-dire section avec une description de ces plugins très basiques. Choisissons exactement les plugins dont nous avons besoin, et non ceux que Gradle a générés pour nous. Selon la documentation, le « Gradle Java Plugin » fournit des opérations de base avec le code Java, telles que la compilation du code source. De plus, selon la documentation, le « plugin d'application Gradle » nous fournit des outils pour travailler avec « l'application JVM exécutable », c'est-à-dire avec une application Java pouvant être lancée en tant qu'application autonome (par exemple, une application console ou une application avec sa propre interface utilisateur). Il s'avère que nous n'avons pas besoin du plugin « application », car... nous n'avons pas besoin d'une application autonome, nous avons besoin d'une application Web. Supprimons-le. Ainsi que le paramètre « mainClassName », qui n'est connu que de ce plugin. De plus, dans la même section « Emballage et distribution » où le lien vers la documentation du plugin d'application a été fourni, il y a un lien vers le plugin Gradle War. Gradle War Plugin , comme indiqué dans la documentation, prend en charge la création d'applications Web Java au format war. Le format WAR signifie qu'au lieu d'une archive JAR, une archive WAR sera créée. Il semble que c'est ce dont nous avons besoin. De plus, comme le dit la documentation, "Le plugin War étend le plugin Java". Autrement dit, nous pouvons remplacer le plugin java par le plugin war. Par conséquent, notre bloc plugin ressemblera finalement à ceci :

plugins {
    id 'war'
}

Également dans la documentation du "Gradle War Plugin", il est indiqué que le plugin utilise un "Project Layout" supplémentaire. La mise en page est traduite de l'anglais par emplacement. Autrement dit, le plugin war s'attend par défaut à l'existence d'un certain emplacement de fichiers qu'il utilisera pour ses tâches. Il utilisera le répertoire suivant pour stocker les fichiers de l'application web : src/main/webapp Le comportement du plugin est décrit comme suit : Autrement dit, le plugin prendra en compte les fichiers de cet emplacement lors de la construction de l'archive WAR de notre application Web. De plus, la documentation du Gradle War Plugin indique que ce répertoire sera la "racine de l'archive". Et déjà dedans, nous pouvons créer un répertoire WEB-INF et y ajouter le fichier web.xml. De quel genre de fichier s'agit-il ? web.xml- il s'agit d'un « Descripteur de déploiement » ou « descripteur de déploiement ». Il s'agit d'un fichier qui décrit comment configurer notre application Web pour qu'elle fonctionne. Ce fichier spécifie les demandes que notre application traitera, les paramètres de sécurité et bien plus encore. À la base, il ressemble quelque peu à un fichier manifeste issu d'un fichier JAR (voir « Travailler avec des fichiers manifeste : les bases »). Le fichier Manifest indique comment travailler avec une application Java (c'est-à-dire une archive JAR) et le web.xml indique comment travailler avec une application Web Java (c'est-à-dire une archive WAR). Le concept même de « Descripteur de déploiement » n'est pas né de lui-même, mais est décrit dans le document « Spécification de l'API Servlet »". Toute application Web Java dépend de cette "API Servlet". Il est important de comprendre qu'il s'agit d'une API, c'est-à-dire qu'il s'agit d'une description d'un contrat d'interaction. Les applications Web ne sont pas des applications indépendantes. Elles s'exécutent sur un serveur Web. , qui assure la communication réseau avec les utilisateurs. Autrement dit, un serveur Web est une sorte de « conteneur » pour les applications Web. C'est logique, car nous voulons écrire la logique d'une application Web, c'est-à-dire quelles pages l'utilisateur verra et comment ils doivent réagir aux actions de l'utilisateur. Et nous ne voulons pas écrire de code sur la façon dont un message sera envoyé à l'utilisateur, comment les octets d'informations seront transférés et d'autres choses de bas niveau et très exigeantes en qualité. il s'avère que les applications Web sont toutes différentes, mais le transfert de données est le même. Autrement dit, un million de programmeurs devraient écrire encore et encore du code dans le même but. Le serveur Web est donc responsable d'une partie de l'interaction de l'utilisateur. et l'échange de données, et l'application Web et le développeur sont responsables de la génération de ces données. Et pour relier ces deux parties, c'est à dire. serveur Web et application Web, vous avez besoin d'un contrat pour leur interaction, c'est-à-dire quelles règles suivront-ils pour ce faire ? Afin de décrire d'une manière ou d'une autre le contrat, à quoi devrait ressembler l'interaction entre une application Web et un serveur Web, l'API Servlet a été inventée. Fait intéressant, même si vous utilisez des frameworks comme Spring, il existe toujours une API Servlet exécutée sous le capot. Autrement dit, vous utilisez Spring et Spring fonctionne avec l'API Servlet pour vous. Il s'avère que notre projet d'application web doit dépendre de l'API Servlet. Dans ce cas, l'API Servlet sera une dépendance. Comme nous le savons, Gradle permet également de décrire les dépendances du projet de manière déclarative. Les plugins décrivent comment les dépendances peuvent être gérées. Par exemple, le plugin Java Gradle introduit une méthode de gestion des dépendances « testImplementation », qui indique qu'une telle dépendance n'est nécessaire que pour les tests. Mais le plugin Gradle War ajoute une méthode de gestion des dépendances « providedCompile », qui dit qu'une telle dépendance ne sera pas incluse dans l'archive WAR de notre application web. Pourquoi n'incluons-nous pas l'API Servlet dans nos archives WAR ? Parce que l'API Servlet sera fournie à notre application Web par le serveur Web lui-même. Si un serveur Web fournit une API Servlet, le serveur est appelé conteneur de servlet. Par conséquent, il est de la responsabilité du serveur Web de nous fournir l'API Servlet, et il est de notre responsabilité de fournir l'API Servlet uniquement au moment de la compilation du code. C'est pourquoi providedCompile. Ainsi, le bloc de dépendances ressemblera à ceci :

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

Revenons donc au fichier web.xml. Par défaut, Gradle ne crée aucun descripteur de déploiement, nous devons donc le faire nous-mêmes. Créons un répertoire src/main/webapp/WEB-INFdans lequel nous créerons un fichier XML appelé web.xml. Ouvrons maintenant la "Spécification du servlet Java" elle-même et le chapitre " CHAPITRE 14 Descripteur de déploiement ". Comme indiqué dans « 14.3 Descripteur de déploiement », le document XML du descripteur de déploiement est décrit par le schéma http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd . Un schéma XML décrit de quels éléments un document peut être constitué et dans quel ordre ils doivent apparaître. Lesquels sont obligatoires et lesquels ne le sont pas. De manière générale, il décrit la structure du document et permet de vérifier si le document XML est correctement composé. Utilisons maintenant l'exemple du chapitre " 14.5 Exemples ", mais le schéma doit être spécifié pour la version 3.1, c'est-à-dire

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

Notre vide web.xmlressemblera à ceci :

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

Décrivons maintenant la servlet que nous allons protéger à l'aide de JAAS. Auparavant, Gradle générait la classe App pour nous. Transformons-le en servlet. Comme indiqué dans la spécification du " CHAPITRE 2 L'interface servlet ", que " Dans la plupart des cas, les développeurs étendront HttpServlet pour implémenter leurs servlets ", c'est-à-dire que pour faire d'une classe un servlet, vous devez hériter de cette classe deHttpServlet :

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

Comme nous l'avons dit, l'API Servlet est un contrat entre le serveur et notre application Web. Ce contrat permet de décrire que lorsqu'un utilisateur contacte le serveur, le serveur va générer une requête de l'utilisateur sous la forme d'un objet HttpServletRequestet la transmettre à la servlet. Il fournira également au servlet un objet HttpServletResponseafin que le servlet puisse y écrire une réponse pour l'utilisateur. Une fois l'exécution du servlet terminée, le serveur pourra fournir à l'utilisateur une réponse basée sur celle-ci HttpServletResponse. Autrement dit, la servlet ne communique pas directement avec l'utilisateur, mais uniquement avec le serveur. Pour que le serveur sache que nous avons un servlet et pour quelles requêtes il doit être utilisé, nous devons en informer le serveur dans le descripteur de déploiement :

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

Dans ce cas, toutes les requêtes /secretne seront pas adressées à notre seule servlet par son nom app, qui correspond à la classe jaas.App. Comme nous l'avons dit précédemment, une application web ne peut être déployée que sur un serveur web. Le serveur Web peut être installé séparément (autonome). Mais pour les besoins de cet examen, une option alternative convient : s'exécuter sur un serveur intégré. Cela signifie que le serveur sera créé et lancé par programme (le plugin le fera pour nous), et en même temps notre application Web y sera déployée. Le système de build Gradle vous permet d'utiliser le plugin " Gradle Gretty Plugin " à ces fins :

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

De plus, le plugin Gretty dispose d'une bonne documentation . Commençons par le fait que le plugin Gretty permet de basculer entre différents serveurs web. Ceci est décrit plus en détail dans la documentation : " Basculer entre les conteneurs de servlets ". Passons à Tomcat, parce que... c'est l'un des plus utilisés, et il possède également une bonne documentation et de nombreux exemples et problèmes analysés :

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

Nous pouvons maintenant exécuter "gradle appRun", puis notre application Web sera disponible sur http://localhost:8080/jaas/secret Il est important de vérifier que le conteneur de servlet est sélectionné par Tomcat (voir #1) et de vérifier à quelle adresse notre application web est disponible (voir #2).

Authentification

Les paramètres d'authentification se composent souvent de deux parties : les paramètres côté serveur et les paramètres côté application Web qui s'exécute sur ce serveur. Les paramètres de sécurité d'une application Web ne peuvent qu'interagir avec les paramètres de sécurité du serveur Web, ne serait-ce que pour la raison qu'une application Web ne peut qu'interagir avec le serveur Web. Ce n'est pas en vain que nous sommes passés à Tomcat, car... Tomcat a une architecture bien décrite (voir " Architecture Apache Tomcat 8 "). D'après la description de cette architecture, il ressort clairement que Tomcat, en tant que serveur Web, représente l'application Web comme un certain contexte, appelé « Contexte Tomcat ». Ce contexte permet à chaque application web d'avoir ses propres paramètres, isolés des autres applications web. De plus, l'application Web peut influencer les paramètres de ce contexte. Souple et pratique. Pour une compréhension plus approfondie, nous vous recommandons de lire l'article « Comprendre les conteneurs de contexte Tomcat » et la section de documentation Tomcat « Le conteneur de contexte ». Comme indiqué ci-dessus, notre application Web peut influencer le contexte Tomcat de notre application à l'aide d'un fichier /META-INF/context.xml. Et l’un des paramètres très importants sur lesquels nous pouvons influencer est celui des domaines de sécurité. Security Realms est une sorte de « zone de sécurité ». Zone pour laquelle des paramètres de sécurité spécifiques sont spécifiés. En conséquence, lors de l'utilisation d'un domaine de sécurité, nous appliquons les paramètres de sécurité définis pour ce domaine. Les domaines de sécurité sont gérés par un conteneur, c'est-à-dire serveur Web, pas notre application Web. Nous pouvons uniquement indiquer au serveur quelle étendue de sécurité doit être étendue à notre application. La documentation Tomcat dans la section « Le composant Realm » décrit un domaine comme une collection de données sur les utilisateurs et leurs rôles pour effectuer l'authentification. Tomcat fournit un ensemble d'implémentations différentes de Security Realm, dont l'une est le " Jaas Realm ". Après avoir compris un peu la terminologie, décrivons le contexte Tomcat dans le fichier/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- Nom de l'application. Tomcat essaiera de faire correspondre ce nom avec les noms spécifiés dans le fichier configFile. configFile- c'est le "fichier de configuration de connexion". Un exemple de ceci peut être vu dans la documentation JAAS : « Annexe B : Exemples de configurations de connexion ». De plus, il est important que ce fichier soit recherché en premier dans les ressources. Notre application web peut donc fournir elle-même ce fichier. Attributs userClassNameset roleClassNamescontiennent une indication des classes qui représentent le principal de l'utilisateur. JAAS sépare les concepts d'« utilisateur » et de « rôle » en deux concepts différents java.security.Principal. Décrivons les classes ci-dessus. Créons l'implémentation la plus simple pour l'utilisateur principal :

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

Nous répéterons exactement la même implémentation pour RolePrincipal. Comme vous pouvez le voir sur l'interface, l'essentiel pour le Principal est de stocker et de renvoyer un nom (ou un ID) qui représente le Principal. Maintenant, nous avons un domaine de sécurité, nous avons des classes principales. Il reste à remplir le fichier à partir de l' configFileattribut " ", alias login configuration file. Sa description se trouve dans la documentation Tomcat : " The Realm Component ". Autrement dit, nous pouvons placer le paramètre JAAS Login Config dans les ressources de notre application Web et grâce à Tomcat Context, nous pourrons l'utiliser. Ce fichier doit être disponible en tant que ressource pour ClassLoader, son chemin devrait donc ressembler à ceci : \src\main\resources\jaas.config Définissons le contenu de ce fichier :

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

Il convient de noter que context.xmlle même nom est utilisé ici et dans. Cela mappe le domaine de sécurité au LoginModule. Ainsi, Tomcat Context nous a indiqué quelles classes représentent les principaux, ainsi que quel LoginModule utiliser. Tout ce que nous avons à faire est d'implémenter ce LoginModule. LoginModule est peut-être l'une des choses les plus intéressantes de JAAS. La documentation officielle nous aidera à développer LoginModule : " Java Authentication and Authorization Service (JAAS) : LoginModule Developer's Guide ". Implémentons le module de connexion. Créons une classe qui implémente l'interfaceLoginModule :

public class JaasLoginModule implements LoginModule {
}

Nous décrivons d’abord la méthode d’initialisationLoginModule :

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

Cette méthode enregistrera les fichiers Subject, que nous authentifierons davantage et remplirons d'informations sur les principaux. Nous économiserons également pour une utilisation future CallbackHandler, ce qui nous est donné. Avec de l'aide, CallbackHandlernous pouvons demander diverses informations sur le sujet de l'authentification un peu plus tard. Vous pouvez en savoir plus à ce sujet CallbackHandlerdans la section correspondante de la documentation : « JAAS Reference Guide: CallbackHandler ». Ensuite, la méthode logind'authentification est exécutée Subject. Il s'agit de la première phase d'authentification :

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

Il est important que loginnous ne modifiions pas le Subject. De tels changements ne devraient se produire que dans la méthode de confirmation commit. Ensuite, nous devons décrire la méthode pour confirmer une authentification réussie :

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

Il peut paraître étrange de séparer la méthode loginet commit. Mais le fait est que les modules de connexion peuvent être combinés. Et pour une authentification réussie, il peut être nécessaire que plusieurs modules de connexion fonctionnent correctement. Et seulement si tous les modules nécessaires ont fonctionné, enregistrez les modifications. Il s'agit de la deuxième phase d'authentification. Terminons avec les méthodes abortet 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;
}

La méthode abortest appelée lorsque la première phase d'authentification échoue. La méthode logoutest appelée lorsque le système se déconnecte. Après avoir implémenté Login Moduleet configuré le nôtre Security Realm, nous devons maintenant indiquer web.xmlque nous voulons en utiliser un spécifiqueLogin Config :

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

Nous avons spécifié le nom de notre domaine de sécurité et spécifié la méthode d'authentification - BASIC. C'est l'un des types d'authentification décrits dans l'API Servlet dans la section « 13.6 Authentification ». Resté n