JAAS - Introduction à la technologie (Partie 2)

Suite de la première partie de l'article sur JAAS. Voyons s'il est possible d'utiliser uniquement des annotations pour JAAS et quels problèmes nous rencontrerons. Nous apprendrons dans cette partie quels outils API Servlet nous permettent de rendre le code plus universel. Et résumons ce que nous lisons.

Continuation

Dans la première partie de l'examen de la technologie JAAS (voir « JAAS - Introduction à la technologie (Partie 1) »), nous avons examiné le principal cas d'utilisation de JAAS et de l'API Servlet. Nous avons vu que le conteneur de servlets Tomcat gérait la sécurité de notre application web en utilisant l'architecture JAAS. Ayant connaissance de la « méthode d'authentification » et du « domaine de sécurité », le conteneur Tomcat lui-même nous a fourni l'implémentation nécessaire du mécanisme d'authentification et nous a lui-même fourni le CallbackHandler, nous venons de tout utiliser dans notre module de connexion. La seule chose importante à retenir est que le navigateur enregistre les données de login et de mot de passe transmises via l'authentification BASIC. Par conséquent, pour chaque nouvelle analyse à l'aide de Chrome, vous pouvez appuyer sur Ctrl+Shift+N pour ouvrir une nouvelle fenêtre afin de travailler en mode navigation privée.

Annotations

La configuration utilisant XML est depuis longtemps démodée. Par conséquent, il est important de dire qu'à partir de la version 3.0 de l'API Servlet, nous avons la possibilité de définir les paramètres du servlet à l'aide d'annotations, sans utiliser le fichier de descripteur de déploiement web.xml. Voyons comment la gestion de la sécurité changera si nous utilisons des annotations. Et est-il possible de mettre en œuvre les approches décrites ci-dessus à l'aide d'annotations ? La spécification Servlet API et sa section “ Annotations et pluggabilité ” nous aideront encore une fois à comprendre les annotations . Cette section indique qu'une déclaration de servlet web.xmlpeut être remplacée par une annotation @WebServlet. En conséquence, notre servlet ressemblera à ceci :

@WebServlet(name="app", urlPatterns = "/secret")
public class App extends HttpServlet {

Examinons ensuite le chapitre " 13.3 Sécurité programmatique ". Il dit que nous pouvons également déclarer une contrainte de sécurité via des annotations :

@WebServlet(name="app", urlPatterns = "/secret")
@ServletSecurity(httpMethodConstraints = {
        @HttpMethodConstraint(value = "GET", rolesAllowed = "admin")
})
public class App extends HttpServlet {

web.xmlIl ne reste plus qu'un seul pâté de maisons dans le nôtre - login-config. Le problème est qu’il se trouve qu’il n’existe aucun moyen de le remplacer facilement et simplement. En raison du lien étroit entre les paramètres de sécurité des applications Web et les paramètres de sécurité du serveur Web, il n'existe pas de moyen simple et universel de procéder, même par programmation. C'est l'un des problèmes liés à l'authentification à l'aide de JAAS et de l'API Servlet. En parlant du bloc login-config, il convient de comprendre qu'il s'agit d'une description déclarative des mécanismes d'authentification, c'est-à-dire mécanismes d’authentification. Il n'existe toujours pas de moyen simple et universel de le remplacer, car... le traitement web.xmls'effectue au plus profond des conteneurs de servlets. Par exemple, dans Tomcat, vous pouvez consulter la source ContextConfig.java . Par conséquent, même pour le conteneur de servlet Tomcat, il existe plusieurs options et elles sont toutes différentes. Par exemple, si nous utilisons le conteneur de servlet Embedded Tomcat (c'est-à-dire que nous élaborons un serveur Web à partir du code), vous pouvez en savoir plus sur ces options ici : « Tomcat intégré avec authentification de base via code ». De plus, un exemple général d'augmentation d'Embedde Tomcat peut être vu dans le guide de la plate-forme Heroku PaaS : « Créer une application Web Java à l'aide de Tomcat intégré ». Si Tomcat n'est pas utilisé en mode intégré, alors pour Tomcat, vous pouvez utiliser une approche couramment utilisée : les écouteurs d'événements. Dans Tomcat, il s'agit du " composant LifeCycle Listener ". Dans le même temps, il est important de comprendre que les conteneurs de servlets (dans notre cas Tomcat) peuvent avoir leurs propres chargeurs de classes et qu'il ne sera pas possible de simplement prendre et utiliser vos classes. Pour Tomcat, vous devez comprendre le " Class Loader HOW-TO ". Dans un autre conteneur de servlets appelé Undertow, cela peut être réalisé en utilisant " Servlet Extensions ". Comme vous pouvez le constater, certains ont prévu des mécanismes plus flexibles, tandis que d’autres ne l’ont pas fait. Comme vous pouvez le constater, il n’existe pas une seule option. Ils sont tous très différents. Est-il possible de faire quelque chose d'universel avec uniquement l'API Servlet et JAAS ? Sur Internet, vous pouvez trouver une proposition pour utiliser Servlet Filter pour effectuer une authentification sans blocage login-config. Considérons enfin cette option. Cela nous permettra de répéter le fonctionnement de JAAS.

Filtre d'authentification

Notre objectif est donc de nous débarrasser web.xmlcomplètement du fichier. Si nous nous en débarrassons, nous ne pourrons malheureusement plus utiliser la contrainte de sécurité, car leur traitement peut avoir lieu bien avant l'application des filtres de servlet. Il s’agit des frais que vous devez payer pour la « polyvalence » de l’utilisation des filtres. Ceux. nous devrons supprimer l'annotation @ServletSecurity, et toutes les vérifications que nous avons décrites précédemment dans la contrainte de sécurité devront être effectuées par programme. Comme vous pouvez le constater, cette option nous impose également de nombreuses restrictions désagréables. Tout d’abord, supprimons l’annotation @ServletSecurityde la ressource et le bloc login-configdu web.xml. Désormais, nous devrons nous-mêmes implémenter l’authentification de base. Ajoutons maintenant notre filtre :

@WebFilter("/*")
public class JaasFilter implements javax.servlet.Filter {

Jusqu'à présent, cela semble simple. Écrivons une méthode d'initialisation :

@Override
public void init(FilterConfig filterConfig) throws ServletException {
	String jaas_conf = filterConfig.getServletContext().getRealPath("/WEB-INF/jaas.config");
	System.getProperties().setProperty("java.security.auth.login.config",jaas_conf);
}

Comme vous pouvez le constater, nous sommes désormais obligés d'utiliser les outils JAAS de base pour rechercher le fichier de configuration jaas. Cela présente un gros inconvénient : s'il existe plusieurs applications, une application peut rompre l'authentification d'une autre. La manière dont vous pouvez généralement définir un fichier de configuration Jaas est décrite en détail dans la documentation JAAS : « Annexe A : Paramètres JAAS dans le fichier de propriétés de sécurité java.security ». Ensuite, nous décrirons la méthode de filtrage elle-même. Commençons par recevoir une requête HTTP :

@Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
	HttpServletRequest req = (HttpServletRequest) request;
	// Если в реквесте уже есть Principal - ничего не делаем
	if (req.getUserPrincipal() != null ) {
		chain.doFilter(request, response);
	}

Tout est simple ici. Si le principal est disponible, l'authentification est réussie. Ensuite, vous devez décrire les actions du filtre lorsque l'utilisateur n'a pas réussi l'authentification, c'est-à-dire il n'a pas encore été reconnu. Nous avons décrit précédemment la méthode d'authentification de base, BASIC. Parce que Puisque nous écrivons maintenant le filtre nous-mêmes, nous devrons comprendre comment fonctionne réellement l'authentification BASIC. Vous pouvez utiliser « MDN web docs : autorisation HTTP ». Et aussi « Comment fonctionne l'authentification HTTP ? » D'après la description du fonctionnement de l'authentification de base, il est clair que si le serveur souhaite effectuer une authentification BASIC et que l'utilisateur n'a pas fourni de données, le serveur envoie un en-tête spécial "WWW-Authenticate" et le code d'erreur 401. Créons un méthode interne pour cela :

private void requestNewAuthInResponse(ServletResponse response) throws IOException {
	HttpServletResponse resp = (HttpServletResponse) response;
	String value = "Basic realm=\"JaasLogin\"";
	resp.setHeader("WWW-Authenticate", value);
	resp.sendError(HttpServletResponse.SC_UNAUTHORIZED);
}

Utilisons maintenant cette méthode et ajoutons doFilterle bloc de code suivant à la méthode :

// Получаем security Header. А если его нет - запрашиваем
String secHeader = req.getHeader("authorization");
if (secHeader == null) {
	requestNewAuthInResponse(response);
}

Ajoutons maintenant une branche pour if, qui sera exécutée lorsque l'en-tête aura déjà été transmis :

// Проверяем аутентификацию
else {
	String authorization = secHeader.replace("Basic ", "");
	Base64.Decoder decoder = java.util.Base64.getDecoder();
	authorization = new String(decoder.decode(authorization));
	String[] loginData = authorization.split(":");
	try {
		if (loginData.length == 2) {
			req.login(loginData[0], loginData[1]);
			chain.doFilter(request, response);
		} else {
			requestNewAuthInResponse(response);
		}
	} catch (ServletException e) {
		requestNewAuthInResponse(response);
	}
}

Vous pouvez ajouter une autorisation à ce code, par exemple : req.isUserInRole("admin") Nous avons donc effectué une authentification avec vous à l'aide d'un filtre. D'une part, il y a beaucoup de code et de traitement manuel. D’un autre côté, il y a la polyvalence et l’indépendance du serveur.

Conclusion

Nous avons maintenant atteint la fin de cette revue. J'espère qu'il deviendra maintenant un peu plus clair ce qu'est JAAS, ce qu'est un sujet et ce que sont les principes. Les mots Security Realm et Login Config ne poseront plus de questions. De plus, nous savons désormais comment utiliser JAAS et l'API Servlet ensemble. De plus, nous avons découvert les goulots d'étranglement où les annotations dans l'API Servlet ne nous sauveront pas. Bien entendu, ce n’est pas tout. Par exemple, l'authentification en Java peut ne pas être uniquement BASIC. Vous pouvez découvrir d'autres types dans la spécification de l'API Servlet dans la section " 13.6 Authentification ". Il est difficile de trouver des informations détaillées sur JAAS sur Internet. Mais je peux recommander ce matériel :

• " Tout ce que JAAS : sécurité Java évolutive avec JAAS "

J'espère que les informations de cet examen seront utiles et compréhensibles. #Viacheslav