인증 논리를 담당하는 부분은 AuthenticationProvider 이다. AuthenticationManager는 HTTP 요청을 수신하고 AuthenticationProvider에게 인증 책임을 위임한다. 이 단원에서는 인증 결과가 두 가지인 인증 프로세스를 살펴본다.요청하는 엔티티가 인증되지 않는다애플리케이션이 사용자를 인식하지 못해 권한 부여 프로세스에 위임하지 않고 요청을 거부한다. 일반적으로 이 경우 클라이언트에 HTTP 401 Unauthorized 응답이 반환된다.요청하는 엔티티가 인증된다요청자의 UserDetails 가 SecurityContext에 저장되어 애플리케이션이 이를 권한 부여에 이용할 수 있다.AuthenticationProvider의 이해어떠한 시나리오가 주어지더라도 구현..
PasswordEncoder 인터페이스 이해일반적으로 시스템은 암호를 그대로 저장하지 않고 해시를 사용해 저장한다. PasswordEncoder는 암호를 인코딩하고 인증 프로세스에서 암호가 유효한지 확인한다.upgradeEncoding 메서드는 false를 반환하도록 기본 구현이 되어 있는데 이를 true 를 반환하도록 재정의하면 인코딩된 암호를 보안 향상을 위해 다시 인코딩한다. 상황에 따라 재정의해서 사용할 수 있다.encode 와 matches 메서드는 기능적으로 밀접한 관계가 있어 이 둘을 재정의하려면 기능 면에서 항상 일치해야 한다. PasswordEncoder 로 인코딩된 암호가 주어진 암호와 같은지 PasswordEncoder로 확인할 수 있어야 한다.제공된 구현 선택스프링 시큐리티에서 이미..
먼저 요청이 들어오면 필터가 요청을 가로채고 인증 책임이 AuthenticationManager로 위임된다. 인증 논리 구현하는 AuthenticationProvider를 이용하는데 이 때 UserDetailsService에서 사용자를 찾고 PasswordEncoder 로 암호를 검증한다. 모든 인증이 끝나면 SecurityContext에 UserDetails가 저장된다.사용자 관리는 UserDetailsManager와 UserDetailsService를 사용한다. UserDetailsService 는 사용자 이름으로 사용자를 찾는 역할만 하고 UserDetailsManager 는 사용자의 삭제, 추가, 수정 작업을 수행한다.사용자는 애플리케이션 내에서 수행할 수 있는 작업을 나타내는 이용 권리의 집합을..
스프링이나 J2EE 컨테이너 환경에서 JPA를 사용하면 영속성과 트랜잭션을 대신 관리해주므로 편리하게 애플리케이션을 개발할 수 있다. 하지만, 컨테이너 환경에서 동작하는 JPA의 내부 동작 방식을 이해하지 못하면 문제가 발생했을 때 해결하기 쉽지 않다. 트랜잭션 범위의 영속성 컨텍스트 스프링이나 J2EE 컨테이너 환경에서는 컨테이너가 제공하는 전략을 따라야 한다. 스프링 컨테이너의 기본 전략 스프링 컨테이너는 트랜잭션 범위의 영속성 컨텍스트 전략을 사용한다. 말 그대로 트랜잭션과 영속성 컨텍스트의 생명주기가 같다라는 의미이다. 트랜잭션이 시작되면 영속성 컨텍스트가 생성되고 트랜잭션이 종료되면 영속성 컨텍스트가 종료된다. 같은 트랜잭션 안에서는 항상 같은 영속성 컨텍스트에 접근한다. 스프링 프레임워크를 사..
