When is the AuthenticationEntryPoint triggered in Servlet Authentication Architecture?

https://kodong8774.tistory.com/189

Servlet Authentication Architecture

 

 

In the article above,

I didn't properly explain "when is the authenticationEntryPoint triggered in Servlet Authentication Architecture?".

So, in this article, I will deep dive into this.

 

 

Before getting into it, we should know the two main scenario. 

1. Login attempt with credentials submitted 

• is handled by AbstractAuthenticationProcessingFilter
  (e.g. UsernamePasswordAuthenticationFilter)

2. Accessing a protected resource without being authenticated 

• is handled by ExceptionTranslationFilter, and this filter calls AuthenticationEntryPoint

So, the first scenario doesn't use the AuthenticationEntryPoint, but second scenario does. 

 

 

Now, we're going to talk about the three types of request 

🟩 Request 1 : user submits login credentials (login)

1. ex) user sends a request (POST /login (username/password))

(SecurityContextHolder is empty at this time)

 

2. That request matches the login RequestMatcher (POST /login),

and UsernamePasswordAuthenticationFilter extracts credentials and makes Authenticaiton (in this flow, it's UsernamePasswordAuthenticationToken). 

And the UsernamePasswordAuthenticationFilter calls AuthenticationManager, and that token is passed to a specific Provider (in this context, it's DaoAuthenticationProvider).

And this Provider performs a authentication.

 

3. If it's success, it returns authenticated Authentication. 

And the UsernamePasswordAuthenticationFilter perform this, 

SecurityContextHolder.getContext().setAuthentication(auth)

(Setting the authenticated Authentication in the SecurityContextHolder)

 

Now SecurityContextHolder contains an authenticated Authentication!

 

4. So, in the end of request,

SecurityContextPersistenceFilter saves SecurityContext in the HttpSession, and sends JSESSIONID cookie to browser, and clears SecurityContextHolder. 

 

If I summarize this flow,

1. Request (sent)

2. UsernamePasswordAuthenticationFilter : creates Authentication (And passes into AuthenticaitonManager).
 
3. AuthenticationManager -> AuthentionProvider : performs authentication.

4. UsernamePasswordAuthenticationFilter : saves the authenticated Authentication into the SecurityContext -> sets SecurityContextHolder.

5. SecurityContextPersistenceFilter saves SecurityContext in the HttpSession and sends JSESSION cookie to the browser and clears SecurityContextHoler.

 

 

🟩 Request 2 : user tries to access protected resource (not logged in)

1. The request is sent. 

 

2. SecurityContextHolder exists, but its context is empty. 

So, SecurityContextPersistenceFilter loads SecurityContext from session. 

But, no Session or no SecurityContext inside the Session. 

( And of course, in that request, there is no Session-id, so SecurityContextPersistenceFilter can not find the matching SecurityContext.)

So, it just leaves SecurityContextHolder empty. 

 

3. AuthorizationFilter checks whether there is Authentication in the SecurityContext in the SecurityContextHolder. 

--> SecurityContextHolder.getContext().getAuthentication() 

Of course, it's empty. There is no Authentication. 

So, the AuthorizationFilter throws AuthenticationException. 

 

4. When the AuthorizationFilter throws the AuthenticationException, 

ExceptionTranslationFilter catches that exception and calls AuthenticationEntryPoint. 

 

5. Finally, SecurityContextHolder is cleared. 

 

If I summarize this flow,

1. Request (Sent)

2. SecurityContextPersistenceFilter : loads SecurityContext for session.
—> But, No Session and No SecurityContext inside the Session.
—> SecurityContextHolder EMPTY

3. AuthorizationFilter : checks Authentication is in SecurityContext
(—> SecurityContextHolder.getContext().getAuthentication())
—> Of course, it’s empty. —> throws AuthenticationException

4. ExceptionTranslatoinFilter : catches that exception and calls AuthenticationEntryPoint
5. Finally, SecurityContextHolder is cleared.

 

🟩 Request 3 : user accesses protected resource (after logged in)

 

Before explain this kind of request, we should know first what the "the request after logged in".

That means, user has cookie with Session-id(JSESSIONID) matching with the WebApplication's Session.

 

1. A client sends a request.

 

2. SecurityContextPersistenceFilter reads the JSESSIONSID inside the request, and

loads a Session that matches the Session-id, and loads a SecurityContext from that Session,

and loads a Authentication from that SecurityContext,

and!!!!! (finally..) puts that Authentication into SecurityContextHolder. 

 

Therefore, SecurityContextHolder has authenticated Authentication before authorization runs.

 

3. So, AuthorizationFilter sees that authenticated user, and checks roles. 

If it's allowed, controller runs!,

If it's not, AccessDeniedHandler runs! (403).

 

4. At the end of request, SecurityContextHolder is cleared again.

 

If I summarize this flow,

1. Request (Sent)

2. SecurityContextPersistenceFilter : loads matching Authenticion in the SecurityContext. 
--> SecurityContextHolder has authenticated Authentication!

3. AuthorizationFilter : checks the role of the Authentication (which is in the SecurityContext in the SecurityContextHolder). 
- If it's allowed controller runs.
- If it's not, AccessDeniedhandler runs. (403)

5. Finally, SecurityContextHolder is cleared.

 

 

 

But! I kept saying, 

at the last stage, SecurityContextHolder is cleard. 

And i didn't explain what the SecurityContextPersistenceFilter does.

 

So, I will organize these next article!!! 😁