[Spring] 스프링 시큐리티(Security)

스프링 시큐리티(Security)란?
스프링(Spring) 기반의 웹애플리케이션의 인증(Authenticate)과 권한(Authorize)을
담당하는 스프링의 하위 프레임 워크

 

그럼 스프링 시큐리티의 작동 원리는 어떻게 될까?

그 전에 우선 스프링의 작동원리를 알아보자.

스프링의 동작 원리

1. 사용자로부터 web.xml을 통해 요청이 들어온다.
2. 보통은 localhost:8080을 통해 사용자와 스프링서버와 연결을 한다.
3. Dispatcher Servlet은 8080포트를 통해 들어온 요청을 받아 IoC컨테이너안에 있는 스프링 빈을 검사하여 함수를 제공한다.
4. Controller라고 사용자의 요청을 url을 통해 받아서 Service에게 요청처리를 부탁한다.
5. 사용자의 요청을 받은 서비스는 Repository라고 하는 DB와 연결을 담당하는 곳에서 사용자가 요청한 정보를 DB로부터 받아온다.
6. Repository는 DB의 CRUD작업을 알아서 처리할 수 있다.

간단하게 위의 과정을 통해 스프링이 작동을 하게 된다.

 

여기서 가장 중요한 역할을 하는 것은 Dispatcher Servlet이라고 생각한다.

즉, 사용자의 요청이 들어왔을 때 시작이 Dispatcher Servlet이고, 끝도 Dispatcher Servlet 라고 생각한다.

 

그럼 Dispatcher Servlet의 작동 과정을 자세히 보자.

Dispatcher Servlet의 작동원리

Dispatcher Servlet은 아까 독자가 말한 거처럼 사용자의 요청이 들어왔을 때 처음과 끝을 담당한다고 했다.

먼저 사용자가 http형태로 요청이 들어오면 Dispatcher Servlet이 가장 먼저 해당 요청을 받아서 GetMapping,PostMapping와 같이 요청한 url Controller가 있는지 확인한다. 

만약 있다면 controller에서 반환한 결과를 Handler Adapter를 호출하여 MV(ModelandView)형태로 반환한다.

반환된 MV를 받은 Dispatcher Servlet은 ViewResolver를 호출하여서 맞는 view를 다시 Dispatcher Servlet에 전달해준다.그럼 Dispatcher Servlet은 ViewResolver를 통해 받은 view를 사용자에게 보여준다.

 

이게 바로 스프링의 동작원리를 설명한 것이다.

사용자 요청

controller에서 사용자 요청과 맞는 url매핑

View

사용자 요청 localhost:8080/home -> Dispatcher Servlet에서 사용자가 요청한 url controller과 있는지 확인

 -> 있다면 ViewResolver을 통해 home.html View를 Dispatcher Servlet에게 반환 -> 사용자에게 home.html 전달

이런식으로 작동하게 된다.

 

지금까지 왜 시큐리티를 설명하면서 갑자기 스프링의 동작원리에 대해 설명하는지 궁금해하는 사람이 있을 것이다.

스프링 시큐리티 동작원리

위의 사진처럼 스프링 시큐리티는 사용자가 요청한 url이 Dispatcher Servlet에 도달하기 전에 스프링 시큐리티 Filter가 

낚아채기 때문이다.

보통 스프링 시큐리티는 사용자가 로그인을 한 경우 작동을 한다.

스프링 시큐리티 동작 원리

1. https요청이 사용자로부터 들어오고 form을 통해 로그인을 시도하면 AuthenticationFilter가 요청을 받는다.
   ※ AuthenticationFilter란? 
   사용자로부터 요청이 들어오면 요청에 대한 인증과 인가를 도와주는 부분이다.
2. 요청을 받은 AuthenticationFilter은 UsernamePasswordAuthenticationToken을 생성한다.
3. UsernamePasswordAuthenticationToken을 통해 인증용 객체를 생성하여서 AuthenticationFilter에게 전달한다.
4. Authentication Manager는 AuthenticationFilter에게 받은 객체를 이용하여 Authentication Manager의 유일한 구현체인
   ProviderManager가 AuthenticationProvider의 목록을 전달받아 사용자가 입력한 ID, PW가 맞는지 안맞는지 확인한다.
5. 4번의 과정을 할 때 필요한 것이 UserDetailsService이다.

public interface UserDetailsService {
	UserDetails loadUserByUsername(String username) throws UsernameNotFoundException;
}

위의 UserDetailsService 인터페이스의 메소드는 loadUserByUsername이 있다.

loadUserByUsername메소드의 파라미터인 username은 사용자가 입력한 username으로 loadUserByUsername메소드의

인자로 넘겨서 UserDetails형으로 가져오게 된다.

<UserDetails란?>

사용자의 정보를 담는 인터페이스라고 할 수 있다.

public class PrincipalDetails implements UserDetails {

    private User user;
    public PrincipalDetails(User user) {
        this.user=user;
    }

    @Override
    public Collection<? extends GrantedAuthority> getAuthorities() { //권한 처리
        List<GrantedAuthority> authorities=new ArrayList<>();
        authorities.add(new SimpleGrantedAuthority("USER"));
        return authorities;
    }

    @Override
    public String getPassword() {
        return user.getPw();
    }

    @Override
    public String getUsername() {
        return user.getEmail(); //저자는 이메일로 로그인을 하기 때문에 email을 받아온다.
    }

    @Override
    public boolean isAccountNonExpired() {
        return true;
    }

    @Override
    public boolean isAccountNonLocked() {
        return true;
    }

    @Override
    public boolean isCredentialsNonExpired() {
        return true;
    }

    @Override
    public boolean isEnabled() {
        return true;
    }
}​

6. 이렇게 UserDetails형으로 가져온 사용자 정보가 사용자가 입력한 정보와 일치하면 Authentication 참조를 리턴한다.

7.  Authentication참조를 리턴받았다는 것은 인증이 완료되었다는 것이므로 사용자가 입력한 사용자의 정보를 
    SecurityContextHolder에 담은 후 AuthenticationSuccessHandle를 실행함으로써 로그인이 된다.

 

Sercurity용어

• 인증(Authentication) : 해당 사용자가 본인인지 확인하는 절차
• 인가(Authorization) : 인증된 사용자가 요청한 자원에 접근 가능한지 결정하는 절차

인가(Authorization)는 권한을 의미하는데 인증된 사용자라도 관리자와 사용자가 접근하는 페이지가 다르듯이 

웹을 요청할 때 권한에 따라 다른 요청을 받을 수 있게 해준다.

 

또한 시큐리티는 위의 방법처럼 세션을 이용하는 방법과 JWT토큰을 이용하는 방식과 타 플랫폼에 저장된 사용자의 정보를 이용하는 Oauth방식이 있다.