Comment les conteneurs de servlet identifient-ils les demandes des utilisateurs authentifiés?

Question

Si j'ajoute un élément <security-constraint> pour certaines URL dans le fichier web.xml de mon application Web, mon conteneur de servlets (par exemple, Tomcat) protégera ces URL et redirigera les utilisateurs non authentifiés vers une page de connexion. Mais comment le conteneur de servlet identifie-t-il les requêtes provenant des utilisateurs authentifiés?

Est-ce qu'ils attendent:

• Un cookie dans la requête HTTP? Lequel?
• Un en-tête HTTP?
• authentification lors de la session (ID de session?)

ce que, en particulier, ne Tomcat rechercher dans une requête d'un utilisateur authentifié?

Voici une partie d'un fichier web.xml, conformément aux exemples trouvés dans les didacticiels courants. Qu'est-ce que le conteneur de servlet (et en particulier Tomcat) va chercher dans la requête pour l'identifier comme provenant d'un utilisateur authentifié?

<security-constraint> 
    <display-name>Restricted GET To Employees</display-name> 
    <web-resource-collection> 
    <web-resource-name>Restricted Access - Get Only</web-resource-name> 
    <url-pattern>/restricted/employee/*</url-pattern> 
    <http-method>GET</http-method> 
    </web-resource-collection> 
    <auth-constraint> 
    <role-name>Employee</role-name> 
    </auth-constraint> 
</security-constraint> 

<login-config> 
    <auth-method>FORM</auth-method> 
    <realm-name>MyRealm</realm-name> 
    <form-login-config> 
    <form-login-page>/login/loginForm.jsp</form-login-page> 
    <form-error-page>/login/loginError.jsp</form-error-page> 
    </form-login-config> 
</login-config> 

<security-role> 
    <role-name>Employee</role-name> 
</security-role> 

Answer 1

Je crois que le cookie JSESSIONID est utilisé dans le but d'identifier les clients, tels que définis dans le Servlet Specification (PDF):

session suivi par les cookies HTTP est le plus utilisé mécanisme de suivi de la session et doit être supporté par tous les conteneurs de servlet. Le conteneur envoie un cookie au client. Le client renverra alors le cookie au chaque demande suivante au serveur, associant sans ambiguïté la requête à une session . Le nom standard du cookie de suivi de session doit être JSESSIONID, qui doit être pris en charge par tous les conteneurs conformes à la version 3.0. Les conteneurs peuvent autoriser la personnalisation du nom du cookie de suivi de session à l'aide de la configuration spécifique au conteneur.

Vous cherchez la façon dont l'authentification se produit dans Tomcat, après avoir effectué une connexion, la méthode org.apache.catalina.authenticator.AuthenticatorBase#register(org.apache.catalina.connector.Request, javax.servlet.http.HttpServletResponse, java.security.Principal, java.lang.String, java.lang.String, java.lang.String, boolean, boolean) est appelée, qui met en cache les informations d'authentification, qui serait réutilisé par les demandes ultérieures de org.apache.catalina.authenticator.AuthenticatorBase#checkForCachedAuthentication pour permettre aux utilisateurs authentifiés de procéder, sans avoir à présenter informations d'identification à nouveau. Cela signifie que même si un utilisateur n'a pas besoin d'être authentifié pour avoir une session valide (identifiée par son cookie JSESSIONID), une fois qu'il se connecte, ses informations d'authentification sont mises en cache et liées à sa session, donc lorsque cet utilisateur crée une nouvelle session. requêtes, le serveur d'applications les reconnaît comme authentifiées et autorise l'accès aux ressources protégées.