안녕! 스프링 시큐리티
설정보다 관습
모든 구성을 직접 작성하는 대신 미리 준비된 구성에 자신의 구현과 일치하지 않는 부분만 재정의
2.1. 첫 번째 프로젝트 시작
스프링 부트, 스프링 시큐리티를 추가만하고 실행하면 콘솔에 패스워드가 출력된다.
HTTP Basic으로 로그인할 수 있다.
사용자이름:암호
형식으로 된 문자열을 Base64 인코딩한다.Base64는 단순히 전송의 편의를 위해 적용한 인코딩일 뿐 암호화나 해싱 방법이 아니므로 전송 중에 가로채면 누구나 볼 수 있다.
따라서 HTTP Basic 인증은 기밀을 위해 이용하지 않는다.
2.2. 기본 구성이란?
인증 필터가 요청을 가로챈다.
인증 책임이 인증 관리자에 위임된다.
인증 관리자는 인증 로직을 구현하는 인증 공급자를 이용한다.
인증 공급자는 사용자 세부 정보 서비스로 사용자를 찾고 암호 인코더로 암호를 검증한다.
인증 결과가 필터에 반환된다.
인증된 엔티티에 관한 세부 정보가 보안 컨텍스트에 저장된다.
UserDetailsService
사용자 세부 정보를 관리한다.
기본 구현은 내부 메모리에 기본 자격 증명을 등록하는 일만 한다.
스프링 컨텍스트가 로드될 때 UUID 형식의 암호가 생성된다.
메모리에만 보관하므로 운영으로는 적합하지 않다.
PasswordEncoder
기본 구현에서는 암호를 일반 텍스트로 관리하고 인코딩하지 않는다.
UserDetailsService를 대체하려면 PasswordEncoder도 지정해야 한다.
AuthenticationProvider
인증 논리를 정의한다.
사용자와 암호의 관리를 위임한다.
HTTP vs HTTPS
실제 애플리케이션에서는 HTTPS를 통해서만 통신해야 한다.
HTTPS는 보안의 아주 작은 부분일뿐 적용한다고 완벽하게 통신이 보호되지 않으므로 항상 보안에 주의를 기울여야 한다.
2.3. 기본 구성 재정의
2.3.1. UserDetailsService 구성 요소 재정의
InMemoryUserDetailsManager 구현을 이용한다.
메모리에 자격 증명을 저장해서 요청 인증 때 사용할 수 있게 한다.
빈을 만들어 등록하면 더 이상 콘솔에 자동으로 암호가 출력되지 않는다.
UserDetailsService를 새로운 빈으로 등록했으므로 PasswordEncoder도 새로 만들어야 한다.
2.3.2. 엔드포인트 권한 부여 구성 재정의
예제에서는
WebSecurityConfigurerAdapter
를 사용하고 있으나 시큐리티 5.7부터 deprecated 되었다.모든 요청에 인증이 필요하도록 한다.
2.3.4. AuthenticationProvider 구현 재정의
인증 로직은 AuthenticationProvider 인터페이스를 구현한다.
2.3.5. 프로젝트에 여러 구성 클래스 이용
구성 클래스의 책임을 분리한다.
Last updated
Was this helpful?