스프링시큐리티인액션 5장 인증-1

인증공급자 authentication provider -> 핵심 기능 담당. 요청을 허용할지 결정

 

1.인증필터 -> 요청을 가로챈다. 가장 먼저 반응

2.인증 책임이 authentication manager에게 위임

3.authentication manager가 authentication provider를 이용

4.authentication provider는 userdetails service를 이용해 사용자 찾고 검증

5.인증결과가 필터에 반환

6.인증된 엔티티에 관한 세부정보가 보안 컨텍스트에 저장.

 

 

Security context란?

 

 

 

https://docs.spring.io/spring-security/reference/servlet/authentication/architecture.html

 

참고하면

 

시큐리티컨텍스트 홀더가 시큐리티의 중심이라고 소개하고 있음.

 

At the heart of Spring Security’s authentication model is the SecurityContextHolder

 

출처: <https://docs.spring.io/spring-security/reference/servlet/authentication/architecture.html>

 

 

6.인증된 엔티티에 관한 세부정보가 보안 컨텍스트에 저장.

->

그래서 정확하게 말하면 securitycontext에 인증된 정보가 저장되는 것이 아닌 SecurityContextHolder에 저장됨.

 

 

The SecurityContextHolder is where Spring Security stores the details of who is authenticated. Spring Security does not care how the SecurityContextHolder is populated. If it contains a value, it is used as the currently authenticated user.

 

SecurityContextHolder는 Spring Security가 누가 인증되었는지에 대한 세부 정보를 저장하는 곳입니다. Spring Security는 SecurityContextHolder가 어떻게 채워지는지 신경쓰지 않습니다. 값이 포함되어 있으면 현재 인증된 사용자로 사용됩니다

 

 

아래에 설명 잘 나와있음

https://catsbi.oopy.io/f9b0d83c-4775-47da-9c81-2261851fe0d0

 

 

Authentication provider에 대해서 들어가기전에 authentication이란?

 

 

아래는 Authentication  의 원형

 

public interface Authentication extends Principal, Serializable {

 

 

Collection<? extends GrantedAuthority> getAuthorities();

Object getCredentials();

Object getDetails();

Object getPrincipal();

boolean isAuthenticated();

void setAuthenticated(boolean isAuthenticated) throws IllegalArgumentException;

 

}

 

실제로 인증 논리를 책임지는 것은 authentication Provider

 

 

실제로 authenticationProvider를 통해 구현

 

 

 

@Component는 스프링에서 관리하는 컨텍스트에 포함되도록 표시.

 

 

loadUserByUsername를 통해 사용자가 있는지 파악

위의 보기는 암호대신 sso인증을 받는 예제

 

 

 

 

 

 

Security context?

주 역할은 authentication 객체 저장.

 

Security context관리자? Securitycontextholder

 

 

• SpringSecurity의 default는 MODE_THREADLOCAL

 

MODE_THREADLOCAL

• 해당 Thread에서만 사용가능한 SecurityContext를 가지고 있는 모드 이다.
• 자기 스레드의 정보만 접근가능하고 다른 스레드의 정보에는 접근불가능.
• Request요청 A,B,C가 있을경우 각 요청마다 스레드를 가지게 되며 다른 요청의 스레드에는 접근 불가.

• 생각해보면 내가 요청한 REQUEST말고 다른 사람의 요청 세션을 볼 수 있다면 문제가 되겠군….

MODE_INHERITABLETHREADLOCAL

• ThreadLocal에 있는 정보를 하위 Thread에 SecurityContext를 전파 하는 모드 이다.

MODE_GLOBAL

• 해당 application에서 모든 Thread에 같은 SecurityContext를 갖게 하는 모드 이다.
• 만약 보안컨텍스트를 모든 스레드에 공유하도록 사용한다면 이 방식을 사용

 

 

이 책에서 말하듯이

스프링 프레임워크를 사용하면 괜히 직접 인증을 구현해서 사용하면 안됨.

대부분 구현되어 있기 때문에 라이브러리 사용 권장.

 

나머지는 2부에서 토나와서 정리못하겠음...