Authentication

황상익·2024년 9월 13일

security

목록 보기
6/16

1. 인증 아키텍처

인증 (Authentication)

<인증 아키텍처>

인증 (Authentication)

Authentication
인증은 특정 자원에 접근하려는 사람의 신원 확인
사용자 인증은 일반적 방법은 사용자 이름과 비밀번호를 입력. 인증 수행, 신원을 알고 / 권한을 부여 → 인증이 선행 → 권한을 부여
Authentication은 사용자의 인증 정보를 저장하는 토큰 개념의 객체로 활용

구조

  • getPrincipal() ­ 인증 주체를 의미하며 인증 요청의 경우 사용자 이름을, 인증 후 에는 UserDetails 타입의 객체가 될 수 있다
    (로그인 → id & password를 여기에 저장)

  • getCredentials() - 인증 주체가 올바른 것을 증명하는 자격 증명으로서 대개 비밀번호를 의미한다 (password 저장 하지는 않음)

  • getAuthorities() ­- 인증 주체(principal)에게 부여된 권한을 나타낸다

  • getDetails() - 인증 요청에 대한 추가적인 세부사항을 저장한다.
    IP주소,인증서일련번호등이될수있다

  • isAuthenticated() -­ 인증 상태 반환 한다

  • setAuthenticated(boolean) -­ 인증 상태를 설정한다

  • principal → Java에 있는 객체 (Object type)

  • Authentication token 객체에 저장 → id, Password


2. SecurityContext, SecurityContextHolder

  • SecurityContext

Authentication 저장 - 현재 인증된 사용자의 Authenticaiton 객체를 저장
ThreadLocal 저장소 - SecurityContextHolder를 통해 접근 → ThreadLocal저장소를 사용해 각 스레드가 자신만의 보안 컨텍스트를 유지 / 다른 스레드의 값을 재생 → x , 자신만의 보안 context를 유지
애플리케이션 전반에 걸친 접근성 - 애플리케이션의 어느 곳에서난 접근 가능, 현재 사용자의 인증 상태나 권한을 확인

  • SecurityContextHolder
    SecurityContextHolder > ThreadLocal > SecurityContext > Authentication

SecurityContext 저장 - 현재 인증된 사용자의 Authentication 객체를 담고 있는 SecurityContext 객체를 저장
전략 패턴 사용 - 다양한 저장 전략을 지원하기 위해 SecurityContextHolderStrategy 인터페이스를 사용
기본 전략 - MODE_THREADLOCAL / Thread Local 저장소에 저장
전략 모드 직접 지정 - SecurityContextHolder.setStrategyName / 지정하고 싶은 문자열로 지정

  • SecurityContextHolder 저장 모드
    MODE_THREADLOCAL - 기본 모드로 각 스레드가 독립적 보안 컨텍스를 소유, 서버 환경에 적합
    MODE_INHERITABLETHREADLOCAL - 부모 스레드로 부터 자식 스레드로 보안 컨텍스트가 상속되며, 작업을 스레드간 분산 실행하는 경우 유용
    (부모 스레드가 존재하는 영역 내에서 별도 스레드 생성 → 자식 스레드 )
    MODE_GLOBAL - 단일 보안 컨텍스트 → 서버 환경에는 부적합
    (애플리케이션 하나에 모든 스레드 적용 / 인증의 값을 하나로 통일하기 때문에 → 보안에 적절하지 않음)

void clearContext(); // 현재 컨텍스트를 삭제한다
SecurityContext getContext(); // 현재 컨텍스트를 얻는다
SuppliergetDeferredContext() //현재컨텍스트를반환하는Supplier를얻는다
voidsetContext(SecurityContextcontext); //현재컨텍스트를저장한다
void setDeferredContext(Supplier deferredContext) // 현재 컨텍스트를 반환하는 Supplier 를 저장한다 (지연의 효과가 있음, 각 스레드에 남겨 놓고 필요시 → Supplier를 참조해서 선택해서 사용)

SecurityContext createEmptyContext(); // 새롭고 비어 있는 컨텍스트를 생성한다

  • SecurityContext 참조 삭제

SecurityContext 참조 - SecurityContexHolder.getContextHolderStrategy().getContext()
SecurityContext 삭제 - SecurityContexHolder.getContextHolderStrategy().clearContext()

  • SecurityContextHolder & SecurityContext 구조
    각각의 Thread Local에 Security를 저장하고 있음 / 서로간 공유 X
    Securitycontext도 자기 만에 authentication을 소유
    if thread pool 이면 → 여러 클라이언트에게 할당 될 수 있다. → 이미 데이터가 저장 되어 있기 때문에 동작에 오류가 날 가능성 있음 (반드시 초기화 해줘야 한다) ⇒ 동시성 관련 문제

+) 참고용
SecurityContextHolderStrategy 사용하기

SecurityContextHolderStrategy securityContextHolderStrategy = SecurityContextHolder.getContextHolderStrategy();
SecurityContext context = securityContextHolderStrategy.createEmptyContext(); context.setAuthentication(authentication); securityContextHolderStrategy.setContext(context);

기존 방식을 사용하면 여러 애플리케이션 컨텍스트가 SecurityContextHolderStrategy를 지정하려고 경쟁이 붙게 된다.

변경방식:
애플리케이션이 SecurityContext를 정적으로 접근하는 대신, SecurityContextHolderStrategy를 자동 주입. 각 애플리케이션 컨텍스트는 자신에게 적합한 보안 전략을 사용 할 수 있다.

Authentication
인증은 특정 자원에 접근하려는 사람의 신원 확인
사용자 인증은 일반적 방법은 사용자 이름과 비밀번호를 입력. 인증 수행, 신원을 알고 / 권한을 부여 → 인증이 선행 → 권한을 부여
Authentication은 사용자의 인증 정보를 저장하는 토큰 개념의 객체로 활용

구조

  • getPrincipal() ­ 인증 주체를 의미하며 인증 요청의 경우 사용자 이름을, 인증 후 에는 UserDetails 타입의 객체가 될 수 있다
    (로그인 → id & password를 여기에 저장)
  • getCredentials() - 인증 주체가 올바른 것을 증명하는 자격 증명으로서 대개 비밀번호를 의미한다 (password 저장 하지는 않음)
  • getAuthorities() ­- 인증 주체(principal)에게 부여된 권한을 나타낸다
  • getDetails() - 인증 요청에 대한 추가적인 세부사항을 저장한다.
    IP주소,인증서일련번호등이될수있다
  • isAuthenticated() -­ 인증 상태 반환 한다
  • setAuthenticated(boolean) -­ 인증 상태를 설정한다
  • principal → Java에 있는 객체 (Object type)
  • Authentication token 객체에 저장 → id, Password

SecurityContext, SecurityContextHolder

  • SecurityContext

Authentication 저장 - 현재 인증된 사용자의 Authenticaiton 객체를 저장
ThreadLocal 저장소 - SecurityContextHolder를 통해 접근 → ThreadLocal저장소를 사용해 각 스레드가 자신만의 보안 컨텍스트를 유지 / 다른 스레드의 값을 재생 → x , 자신만의 보안 context를 유지
애플리케이션 전반에 걸친 접근성 - 애플리케이션의 어느 곳에서난 접근 가능, 현재 사용자의 인증 상태나 권한을 확인

  • SecurityContextHolder
    SecurityContextHolder > ThreadLocal > SecurityContext > Authentication

SecurityContext 저장 - 현재 인증된 사용자의 Authentication 객체를 담고 있는 SecurityContext 객체를 저장
전략 패턴 사용 - 다양한 저장 전략을 지원하기 위해 SecurityContextHolderStrategy 인터페이스를 사용
기본 전략 - MODE_THREADLOCAL / Thread Local 저장소에 저장
전략 모드 직접 지정 - SecurityContextHolder.setStrategyName / 지정하고 싶은 문자열로 지정

  • SecurityContextHolder 저장 모드
    MODE_THREADLOCAL - 기본 모드로 각 스레드가 독립적 보안 컨텍스를 소유, 서버 환경에 적합
    MODE_INHERITABLETHREADLOCAL - 부모 스레드로 부터 자식 스레드로 보안 컨텍스트가 상속되며, 작업을 스레드간 분산 실행하는 경우 유용
    (부모 스레드가 존재하는 영역 내에서 별도 스레드 생성 → 자식 스레드 )
    MODE_GLOBAL - 단일 보안 컨텍스트 → 서버 환경에는 부적합
    (애플리케이션 하나에 모든 스레드 적용 / 인증의 값을 하나로 통일하기 때문에 → 보안에 적절하지 않음)

void clearContext(); // 현재 컨텍스트를 삭제한다
SecurityContext getContext(); // 현재 컨텍스트를 얻는다
SuppliergetDeferredContext() //현재컨텍스트를반환하는Supplier를얻는다
voidsetContext(SecurityContextcontext); //현재컨텍스트를저장한다
void setDeferredContext(Supplier deferredContext) // 현재 컨텍스트를 반환하는 Supplier 를 저장한다 (지연의 효과가 있음, 각 스레드에 남겨 놓고 필요시 → Supplier를 참조해서 선택해서 사용)

SecurityContext createEmptyContext(); // 새롭고 비어 있는 컨텍스트를 생성한다

  • SecurityContext 참조 삭제

SecurityContext 참조 - SecurityContexHolder.getContextHolderStrategy().getContext()
SecurityContext 삭제 - SecurityContexHolder.getContextHolderStrategy().clearContext()

  • SecurityContextHolder & SecurityContext 구조
    각각의 Thread Local에 Security를 저장하고 있음 / 서로간 공유 X
    Securitycontext도 자기 만에 authentication을 소유
    if thread pool 이면 → 여러 클라이언트에게 할당 될 수 있다. → 이미 데이터가 저장 되어 있기 때문에 동작에 오류가 날 가능성 있음 (반드시 초기화 해줘야 한다) ⇒ 동시성 관련 문제

+) 참고용
SecurityContextHolderStrategy 사용하기

SecurityContextHolderStrategy securityContextHolderStrategy = SecurityContextHolder.getContextHolderStrategy();
SecurityContext context = securityContextHolderStrategy.createEmptyContext(); context.setAuthentication(authentication); securityContextHolderStrategy.setContext(context);

기존 방식을 사용하면 여러 애플리케이션 컨텍스트가 SecurityContextHolderStrategy를 지정하려고 경쟁이 붙게 된다.

변경방식:
애플리케이션이 SecurityContext를 정적으로 접근하는 대신, SecurityContextHolderStrategy를 자동 주입. 각 애플리케이션 컨텍스트는 자신에게 적합한 보안 전략을 사용 할 수 있다.

profile
개발자를 향해 가는 중입니다~! 항상 겸손

0개의 댓글