[JAVA] Partie 2: Comprendre (approximativement) le flux de processus de la connexion OAuth 2.0 prise en charge par Spring Security 5

Basé sur l'application de démonstration créée la dernière fois dans "Essayez d'utiliser OAuth 2.0 Login pris en charge par Spring Security 5 avec Spring Boot" Je voudrais voir si Spring Security 5 réalise la connexion OAuth 2.0 dans le flux. (Cette fois, nous limiterons le flux de traitement à la granularité du filtre de servlet → Restez à l'écoute pour l'histoire de la classe utilisée dans chaque filtre de servlet pour le traitement!)

Version prérequise

Activer la journalisation du débogage Spring Security

Lors de l'examen du mécanisme de Spring Security, l'activation du journal de débogage de Spring Secuirty facilite la compréhension du comportement des filtres de sécurité de Spring Security.

src/main/resources/application.properties


logging.level.org.springframework.security=debug

Statut d'application du filtre de servlet

Lorsque vous démarrez l'application de démonstration, le journal suivant est généré et vous pouvez confirmer que le filtre de servlet de Spring Security (springSecurityFilterChain) est appliqué à toutes les demandes (/ *).

2017-11-23 21:40:39.451  INFO 66053 --- [ost-startStop-1] o.s.b.w.servlet.FilterRegistrationBean   : Mapping filter: 'characterEncodingFilter' to: [/*]
2017-11-23 21:40:39.451  INFO 66053 --- [ost-startStop-1] o.s.b.w.servlet.FilterRegistrationBean   : Mapping filter: 'hiddenHttpMethodFilter' to: [/*]
2017-11-23 21:40:39.451  INFO 66053 --- [ost-startStop-1] o.s.b.w.servlet.FilterRegistrationBean   : Mapping filter: 'httpPutFormContentFilter' to: [/*]
2017-11-23 21:40:39.451  INFO 66053 --- [ost-startStop-1] o.s.b.w.servlet.FilterRegistrationBean   : Mapping filter: 'requestContextFilter' to: [/*]
+2017-11-23 21:40:39.452  INFO 66053 --- [ost-startStop-1] .s.DelegatingFilterProxyRegistrationBean : Mapping filter: 'springSecurityFilterChain' to: [/*]

État de l'application de FilterChainProxy (springSecurityFilterChain)

Si vous démarrez l'application de démonstration avec le journal de débogage Spring Security activé, le journal suivant sera généré et vous pouvez vérifier l'état de l'application du filtre de sécurité Spring Security (en fait le filtre de servlet) pour chaque modèle de chemin. Je vais. (Bien qu'il soit cassé pour la lisibilité, il est en fait sorti sur une ligne)

2017-11-23 21:40:40.691  INFO 66053 --- [           main] o.s.s.web.DefaultSecurityFilterChain     : Creating filter chain: org.springframework.security.web.util.matcher.AnyRequestMatcher@1,
 [org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter@3cae7b8b,
 org.springframework.security.web.context.SecurityContextPersistenceFilter@20e6c4dc,
 org.springframework.security.web.header.HeaderWriterFilter@327c7bea,
 org.springframework.security.web.csrf.CsrfFilter@5246a3b3,
 org.springframework.security.web.authentication.logout.LogoutFilter@151db587,
 org.springframework.security.oauth2.client.web.OAuth2AuthorizationRequestRedirectFilter@26f7cdf8,
 org.springframework.security.oauth2.client.web.OAuth2LoginAuthenticationFilter@681adc8f,
 org.springframework.security.web.authentication.ui.DefaultLoginPageGeneratingFilter@4682eba5,
 org.springframework.security.web.savedrequest.RequestCacheAwareFilter@4d2a1da3,
 org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter@68c87fc3,
 org.springframework.security.web.authentication.AnonymousAuthenticationFilter@184dbacc, 
 org.springframework.security.web.session.SessionManagementFilter@6c65860d,
 org.springframework.security.web.access.ExceptionTranslationFilter@3f672204,
 org.springframework.security.web.access.intercept.FilterSecurityInterceptor@18eec010]

Présentation du filtre de sécurité

Permettez-moi de vous présenter brièvement le rôle de Security Filter (Servlet Filter) lié à cette entrée (OAuth 2.0 Login).

Security Filter La description
SecurityContextPersistenceFilter SecurityContext(Zone pour conserver les informations d'identification)Filtre de servlet qui fournit un mécanisme de partage entre les demandes. Le comportement par défaut est le partage entre les demandesHttpSessionUtiliser.
OAuth2AuthorizationRequestRedirectFilter OAuth 2.0(OpenID Connect 1.0)Point de terminaison d'autorisation du fournisseur(Endpoint pour obtenir l'autorisation d'accéder aux informations utilisateur du propriétaire de la ressource)Un filtre de servlet qui fournit un point de terminaison pour la redirection. Le comportement par défaut est "/oauth2/authorization/{registrationId}Est le chemin du point de terminaison.
OAuth2LoginAuthenticationFilter OAuth 2.0(OpenID Connect 1.0)Le point de terminaison pour se connecter à l'application de démonstration à l'aide du point de terminaison du jeton (point de terminaison pour obtenir le jeton d'accès) (le point de terminaison utilisé lors du retour à l'application de démonstration après autorisation du côté du fournisseur) Filtre de servlet à fournir. Le comportement par défaut est "/login/oauth2/code/{registrationId}Est le chemin du point de terminaison.
DefaultLoginPageGeneratingFilter Un filtre de servlet qui fournit un point de terminaison pour générer une page de connexion par défaut. Le comportement par défaut est "GET /loginEst le chemin du point de terminaison. Si la page de connexion est spécifiée, ce filtre de servlet ne sera pas appliqué.
ExceptionTranslationFilter Un filtre de servlet pour gérer les erreurs d'autorisation et fournir des réponses aux erreurs. Le comportement par défaut est de rediriger vers le point de terminaison pour afficher la page de connexion lorsque la connexion est requise, et de répondre «403 interdit» si vous êtes connecté (AccessDeniedHandlerPeut être personnalisé à n'importe quelle réponse d'erreur).
FilterSecurityInterceptor Un filtre de servlet qui effectue le traitement des autorisations en fonction de la stratégie d'accès spécifiée.

Note:

Dans cette entrée, je vais omettre le mécanisme de base de Spring Secuirty, donc si vous voulez connaître le mécanisme de base de Spring Security, veuillez lire @ opengl-8080's "[Spring Security Usage Memo Series](https: /) /qiita.com/opengl-8080/items/032ed0fa27a239bdc1cc) »est recommandé! !!

Comprendre le déroulement de "Demande d'affichage de l'écran d'index-> Affichage de l'écran de connexion"

Ici, nous allons regarder le fonctionnement lorsqu'une demande d'affichage d'une page sécurisée ("écran d'index") est faite sans connexion.

image.png

Flux de processus
Le propriétaire de la ressource fait une "demande d'affichage d'écran d'index" via l'agent utilisateur.(GET /)"Je fais.
FilterSecurityInterceptorEffectue le traitement d'autorisation pour la "demande d'affichage de l'écran d'index". Dans l'application de démonstration, la politique d'accès «authentifié» est définie pour «demande d'affichage de l'écran d'index», de sorte qu'une demande d'un agent utilisateur qui n'est pas connecté entraînera une erreur d'autorisation.
ExceptionTranslationFilterEst une erreur d'autorisation(AccessDeniedException)Et redirigez vers l'écran de connexion. Avant la redirection, mettez en cache les informations de demande qui ont provoqué une erreur d'autorisation (l'implémentation par défaut estHttpSessionEn le stockant dans (stocké dans), l'écran d'index peut être affiché après une connexion réussie.
L'agent utilisateur demande "Demande d'affichage de l'écran de connexion"(GET /login)"Je fais.
DefaultLoginPageGeneratingFilterRépond à l'écran de connexion pour se connecter via le fournisseur (GitHub dans l'application de démonstration).

Comprendre le flux de "Demande de connexion (demande d'affichage de l'écran d'autorisation) -> Affichage de l'écran d'autorisation"

Ici, voyons l'opération lorsqu'une demande d'affichage de l'écran d'autorisation fourni par le fournisseur est faite à partir de l'écran de connexion généré par DefaultLoginPageGeneratingFilter.

image.png

Flux de processus
Le propriétaire de la ressource appuie sur le lien affiché sur l'écran de connexion et clique sur «Demande d'affichage de l'écran d'autorisation (GET /oauth2/authorization/{registrationId})"Je fais. L'application de démonstration utilise GitHub comme fournisseur, doncregistrationIdEstgithubdevenir.
OAuth2AuthorizationRequestRedirectFilterLes informations d'enregistrement du client sont-elles(ClientRegistration)Reportez-vous et redirigez vers le point de terminaison d'autorisation fourni par le fournisseur.
GitHub affiche l'écran d'autorisation après avoir authentifié le propriétaire de la ressource.

Comprendre le flux de "Demande d'autorisation -> Affichage de l'écran d'index"

Ici, voyons l'opération lorsqu'une demande d'autorisation est effectuée sur l'écran d'autorisation de GitHub.

image.png

Flux de processus
Le propriétaire de la ressource est autorisé à se connecter à l'application de démonstration en utilisant les informations utilisateur du fournisseur en appuyant sur le "bouton d'autorisation" affiché sur l'écran d'autorisation.
GitHub attribue un code d'autorisation à la destination de transition (URL pour accéder au point de terminaison qui effectue le traitement d'authentification) spécifiée par l'application de démonstration et la redirige.
L'agent utilisateur est "Demande de traitement d'authentification (GET /login/oauth2/code/{registrationId})"Je fais. L'application de démonstration utilise GitHub comme fournisseur, doncregistrationIdEstgithubdevenir.
OAuth2LoginAuthenticationFilterFait une demande au point de terminaison de jeton fourni par le fournisseur et obtient le jeton d'accès correspondant au code d'autorisation reçu du fournisseur.
OAuth2LoginAuthenticationFilterUtilise le jeton d'accès obtenu du fournisseur pour faire une demande au point de terminaison des informations utilisateur et obtenir les informations utilisateur du propriétaire de la source.
OAuth2LoginAuthenticationFilterGénère des informations d'identification à l'aide de l'acquisition à partir de points de terminaison de jetons et de points de terminaison d'informations utilisateurSecurityContextHolderMis à. (Il sera authentifié ici)
OAuth2LoginAuthenticationFilterEffectue une "demande d'affichage d'écran d'index (redirection)" en se référant aux informations de demande mises en cache au moment d'une erreur d'autorisation.
SecurityContextPersistenceFilterGénérera les informations d'identification lorsque l'authentification est réussieSecurityContextHolderSortir deHttpSessionEnregistrer dans.
L'agent utilisateur demande "une demande d'affichage de l'écran d'index (GET /)"Je fais.
SecurityContextPersistenceFilterEstHttpSessionObtenez les informations d'identification deSecurityContextHolderMis à. En effectuant ce processus, les informations d'authentification peuvent être partagées entre les demandes (= l'état authentifié peut être conservé).
FilterSecurityInterceptorEffectue le traitement d'autorisation pour la "demande d'affichage de l'écran d'index". A ce stade, puisqu'il est dans l'état authentifié, l'autorisation est OK et le traitement ultérieur (traitement d'affichage d'écran d'index) est exécuté.
DemoControllerExécute un processus correspondant à la "demande d'affichage de l'écran d'index" et répond à l'écran d'index.

Résumé

Le mécanisme de connexion OAuth 2.0 fourni par Spring Security 5 est réalisé en ajoutant deux filtres de sécurité, ʻOAuth2AuthorizationRequestRedirectFilter et ʻOAuth2LoginAuthenticationFilter, au groupe de filtres de sécurité fourni avant Spring Security 4. Je pense que tu comprends.

ʻOAuth2AuthorizationRequestRedirectFilter est complètement le propre filtre de sécurité de OAuth 2.0 Login, mais ʻOAuth2LoginAuthenticationFilter joue le même rôle que ʻUsernamePasswordAuthenticationFilter dans l'authentification par formulaire. ʻUsernamePasswordAuthenticationFilter utilise le "nom d'utilisateur" et le "mot de passe" entrés sur l'écran de connexion pour le traitement d'authentification, tandis que ʻOAuth2LoginAuthenticationFilter` utilise le "code d'autorisation" émis par le fournisseur (serveur d'autorisation) pour le traitement de l'authentification. La différence entre ces deux filtres de sécurité (filtres d'authentification) est que

La prochaine fois, je voudrais présenter le type de classes que ʻOAuth2AuthorizationRequestRedirectFilter et ʻOAuth2LoginAuthenticationFilter utilisent pour le traitement.

Site de référence

Recommended Posts

Partie 2: Comprendre (approximativement) le flux de processus de la connexion OAuth 2.0 prise en charge par Spring Security 5
Partie 3: Comprendre (en profondeur) le flux de processus de la connexion OAuth 2.0 prise en charge par Spring Security 5
Partie 4: Personnalisez le comportement de la connexion OAuth 2.0 prise en charge par Spring Security 5
Partie 1: Essayez d'utiliser la connexion OAuth 2.0 prise en charge par Spring Security 5 avec Spring Boot
Expérimentons le flux d'octroi de code d'autorisation avec Spring Security OAuth-Part 1: Review of OAuth 2.0
Je veux comprendre le flux des paramètres de demande de traitement Spring
Implémentation de la fonction de connexion par Spring Security (securityConfig)
Jusqu'à l'utilisation de Spring Data et JPA Part 2
Jusqu'à l'utilisation de Spring Data et JPA Part 1
À peu près le flux de développement d'applications Web avec Rails.
Contrôlez le flux de traitement Spring Batch avec JavaConfig.
L'histoire de la montée de Spring Boot de la série 1.5 à la série 2.1 part2
Connectez-vous avec HttpServletRequest # login dans Spring Security dans l'environnement Servlet 3.x