Spring 정리/Spring Security (16) 썸네일형 리스트형 AuthToken 사용하기 이전에는 Session으로 구성했지만, 이제는 JWT 토큰을 사용하여 시큐리티를 구성한다. 핵심은 Bearer Token을 Client에 주도록 설정하는 것이며, 로그인할 때 Token을 검사하는 것이다. @Override protected void configure(HttpSecurity http) throws Exception { JWTLoginFilter loginFilter = new JWTLoginFilter(authenticationManager(), spUserService); JWTCheckFilter checkFilter = new JWTCheckFilter(authenticationManager(), spUserService); http .csrf().disable() .sessionM.. JWT 토큰 서버에서 인증된 사용자가 인증을 유지해주는 방법은 보통 세션을 사용한다. 서버 세션을 사용하면 인증된 사용자는 매우 편리하게 서비스를 이용할 수 있고, 대부분 웹 애플리케이션 서버가 세션을 지원하기 때문에 편리하다. 하지만, 서버를 여러대 둘 경우(scale out), 같은 사용자가 서로 다른 도메인의 데이터를 요청할 경우, (SSO)에는 세션을 유지하기 위한 비용이 매우 커진다. MSA는 각 서비스별로 각각의 서버를 가지고 있다. 한쪽에서 로그인을 하면 다른 쪽에서도 연속성 있게 로그인 정보를 유지해야 한다. 세션을 사용하는 경우 서버는 request 사용자에 대해 서버에 저장된 세션을 구분해서 인식해야 한다. 여러대의 서버라면 세션을 공유하거나 복사하거나 하는 전략이 필요하다. 따라서,. 서버에 사용.. 임시권한 부여하기 임시권한 부여를 확인하기 위해서, SecurityInterceptor의 내부 작동방식을 다시 한번 짚어보고, 임시권한을 추가해야 할 위치를 확인한다. FilterSecurityInterceptor, MethodSecurityInterceptor 2개의 Interceptor는 각각 invoke 메서드가 작동한다. public Object invoke(MethodInvocation mi) throws Throwable { InterceptorStatusToken token = super.beforeInvocation(mi); Object result; try { result = mi.proceed(); } finally { super.finallyInvocation(token); } return super... @Secured 기반 권한체크 기존에는 Expression 기반의 어노테이션을 이용한 권한체크를 하였다. 기존에는 시큐리티가 @Secured로 구축된 것이 많다. 이 권한 체크들도 내부를 분석해볼만한 가치가 있다. CustomVoter도 Secured 기반으로 만들어본다. 어노테이션을 커스텀하게 만드는 것도 추가한다. SecurityInterceptor는 filter와 method 2곳에 위치하는데, AbstractSecurityInteceptor에 공통코드가 들어가있다. Filter에서 필요한 권한 검사의 내용은 MetadataSource에 있다. (Method에 필요한 것도 Method만의 MetadataSource에 있다.) MetadataSource안에 에노테이션으로 권한을 마킹한 정보들을 configAttribute라고 한다.. 메서드 후처리 메서드 후처리는 메서드가 결과를 리턴한 다음에 리턴된 객체를 사용자가 접근할 수 있는지 검사한다. 권한은 메서드쪽에서 MethodSecurityInterceptor를 통해서 검사한다. MethodSecurityInterceptor 에서 중요한 멤버는 아래 세가지다. AccessDecisionManager : @Secured 나 @PreAuthorize, @PreFilter 를 처리한다. (사전체크) AfterInvocationManager : @PostAuthorize, @PostFilter 를 처리한다. (사후체크) RunAsManager : 임시권한을 부여한다. AccessDecisionManager 는 Voter가 필요하여 AccessDecisionVoter가 다양한 Voter를 가지고 있지만, A.. 권한위원회 voter 일반적으로 권한은 AccessDecisionManager이 담당하며, 역할은 인증이 완료된 사용자가 리소스에 접근하려고 할때 해당 요청을 허용할것인지 판단하는 인터페이스이다. AccessDecisionManager의 decide()만 구현하면 끝이난다. 꼭 Voter기반으로 할 필요는 없지만 Voter를 많이 사용하기 때문에 해당 방식의 원리를 알고 있는 것이 좋다. 인터페이스 구현체는 3가지를 제공한다. AccessDecisionManger 권한 위원회는 - AffirmativeBase :여러 Voter중에 하나라도 허용되면 허용된다. (기본설정) - ConsensesBased : 다수결 - UnaminousBased : 만장일치 3가지의 종류를 가지고 있다. public void decide(Auth.. 스프링 시큐리티의 권한(Authorization) AOP는 관심사가 같은 코드들끼리 묶는 역할을 한다. 서로 섞지 않고 분리한다. IT초기에는 스파게티 코드들이 많았는데 권한, 트랜잭션 코드들이 비지니스 로직과 모두 묶여 있었기 때문이다. 좋은 설계를 위해 트랜잭션, 로그, 권한처리 등등을 비지니스 로직에서 분리하는 고민이 있었고 그 결과 AOP 기술이 탄생하였다. 공통의 관심사를 어떻게 분리하는가? PointCut을 통해서 advice를 삽입한다. 코드를 서로 분리해두는데, 비지니스 로직의 적절한 곳에 권한, 로그 ,트랜잭션 커밋 등이 적용될 수 있도록 진입점을 가리켜 두는 것이다. SecurityFilterChain당 1개의 AccessDecisionManager가 있으며 Method 권한 판정은 하나의 Global 위원회에서 처리한다. 스프링 시큐.. 권한체크 오류처리 Interceptor 권한검사는 2곳에서 가능하다. FilterSecurityInterceptor 혹은 MethodSecurityInterceptor 이며 각각 필터, 메서드에서 검사한다. 해당 검사기능들이 Filter에 있는지 Method에 있는지에 따라서 작동하는 시점이 달라지는 것이다. 2가지 Interceptor의 역할과 차이점을 알아본다. *FilterSecurityInterceptor AccessDecisionManger는 권한검사를 하며 매우 중요한 역할이다. 그 아래에 AccessVoter들이 위원회를 소집해서 조사 및 투표를 하고 들어갈 수 있으면 투표를 하고 통과하지 못하면 AccessDenied를 한다. request .antMatchers("/").permitAll() .antMat.. 이전 1 2 다음
