와우 친구들 풍성충 아조씨야!

분명,화요일에 온다고 했는데, 왜 일요일에 왔냐구요? 아니 본가갔는데, 할게없어서 양심에 찔림. 그리고 왜인지 공부해야할 것 같아서, 어제 밤에 돌아왔습니다. 공부나하죠

자, 프로젝트나 한번 만들어보죠.

1. 첫번째, 프로젝트 시작

아 역시 인텔리제이는 너무좋아.

그, 몇몇 아시는 프로그래머 분들이 왜 시뻘건 테마 쓰냐고 눈 안아프냐? 그러시는데 이거 ㄹㅇ 개꿀인데? 이걸 모르시네

1. ERROR메시지가 콘솔창에 떠도 다 빨개서 동요감이 사라짐.
2. 소띠라 그런지 빨강색만 보면, 뭔가 들이받고 싶어짐. 그래서 모니터를 들이받을 수 는 없으니 뇌라도 빨리 굴려서 이걸 치우려고함. 결국, 빨리 일감을 해치울 수 있음 ㅇㅇ

아, 잠깐 문제가 있었어요~ 어찌되었든

의존성 추가 시켜주고 생성합시다

첫번째 설정은, 인텔리제이에서 그래들 빌드할 때 개꿀임 (그래들보다 더빠른?듯)

그리고 이런식으로 컨트롤러하나 만들어줍시다. (기본적인 설명은, 시큐리티가 아닌 스프링 강의를 들으셔야하니 스킵합니다.)

그리고, 인텔리제이는 저 옆에 api클릭하시면, 포스트맨이런거 굳이 열 필요없습니다.

뭐 어찌되엇든, 그냥 요청하시게 되면, 401 에러로 권한 없음이 반환됩니다. 인증을 위한, 올바른 자격 증명을 제공하지 않았기 때문이라서요. 자, 그러면 스프링 처음 start할때, 나왔던 패스워드로 자격증명을 하고 들가보겠습니다

그러면, Hello 가 잘 리턴됩니다.

2. 기본 구성

1. 인증 필터는 인증 요청을 관리자에게 위임하고, 응답을 바탕으로 보안 컨텍스트를 구성한다.
2. 인증 관리자는 인증 공급자를 이용해 인증을 처리한다.
3. 인증 공급자는 인증 논리를 구현한다.
4. 인증 공급자는 사용자 관리 책임을 구현하는 사용자 세부 정보 서비스를 인증 논리에 이용한다.
5. 인증 공급자는 암호 관리를 구현하는 암호 인코더를 인증 논리에 이용한다.
6. 보안 컨테스트는 인증 프로세스 후 인증 데이터를 유지한다.

자동으로 구성되는 빈에는 UserDetailsService, PasswordEncoder 등이 있는데, 사용자의 관한 세부 정보는 UserDetailsService 계약을 구현하는 객체가 관리한다. 이러한 기본 자격 증명에서 사용자 이름은 'user'이고, 기본 암호는 UUID 형식이며, 암호는 스프링 컨텍스트가 로드 될 때 자동으로 생성된다.

그 다음으로, PasswordEncoder의 경우에는 암호를 인코딩하고, 임호가 기존 인코딩과 일치하는지 확인하는 작업을 한다.

3. 기본 구성 재정의

프로그램상의 재정의의 뜻은 다 알거라 생각하니, 뭐 그냥 간단하게만 설명하자면, 해당 프로젝트가 원하는 방향, 혹은 서비스 방식에 맞게 기본값을 대체 혹은 추가 삭제 해서 써봅시다.

A. UserDetailsService 구성 요소 재정의

이러한 재정의는 집접 구현을 만들거나, 스프링 시큐리티에 있는 구현을 이용하는 2가지의 방식이 존재한다. 하지만, 아직은 직접구현이 아닌 InMemoryUserDetailsManager 라는 구현을 이용해서 진행 하겠습니다.

@Configuration 과 @Bean 어노테이션을 지정해줬습니다. (솔직히 저 안에 구문도 return new 로 한번에 뺄까싶다가...)
해당 코드로 실행시에, 더이상 암호가 출력되지 않습니다. 하지만, 사용자가 없고, PasswordEncoder가 없기에 엔드포인트에 접근이 불가합니다.

자, 그러면 위의 문제를 해결하기 위해서는 아래의 과정을 거쳐야 합니다.

1. 자격 증명(사용자 이름 및 암호)이 있는 사용자를 하나 이상 만든다.
2. 사용자를 UserDetailsService 에서 관리하도록 추가한다.
3. 주어진 암호를 UserDetailsService가 저장하고 관리하는 암호를 이용해 검증하는 PasswordEncoer 형식의 빈을 정의합니다.

위와 같이 설정 시, nappy 라는 아이디는 12345의 비밀번호를 가진 읽기 권한을 가진 회원이 생성된겁니다. 하지만 아직 PasswordEncoder는 없지요~ (기존의 UserDetailsService 를 이용시에는 자동으로 구성됩니다. 하지만, 저희는 재정의를 하고 있기에, 다시 선언해줘야 합니다)

이런식으로 말이죠. (아 근데, 저거 취소선 그어진 이유는 스프링 프레임워크 5버전 이후부터는 잘안씁니다. 그래도 일단은 책에서 이해를 위해 설명해놓은거니 수정하지 않고, 그대로 진행하겠습니다. 원래 그 코드 역사도 알아야 왜 나온지 알고, 왜 쓰는건지 아는거임) -> 제가 별생각없이 Mybatis 모르고 JPA 건너갔다가 대참사 겪어봐서 잘암

책에 더 자세한 설명이 있어서 첨부합니다.

NoOpPasswordEncoder(이하 NOPE) 인스턴스는 암호에 암호화나 해시를 적용하지 않고 일반 텍스트 처럼 처리한다. NOPE는 암호를 비교할 때 String 클래스의 기본 equals메서드로 간단한 문자열 비교만 한다. 해당 예제에서는 암호의 해싱 알고리즘에 신경쓰고 싶지 않을 때 좋은 옵션이다.

B. 엔드 포인트 권한 부여 구성 재정의

해당 장에서는 인증방식과 구성에 관해 간단하게만 설명한답니다. 참고하십쇼. (참고하라고 ㄹㅇㅋㅋ)

기본적으로 HTTPBasic 인증을 권한 부여 방법으로 이용하지만, 해당 인증은 대부분의 애플리케이션 아키텍처에 적합하지 않아용.이러한 변경을 위해. WebSecurityConfigurerAdapter 클래스를 확장하는 것부터 시작해봅시다.

참고로, WebSecurityConfigurerAdapter도 deprecated 되었으니, SecurityFilterChain Bean 등록을 통해 해결하시면 됩니다. (요즘은 기술이 휙휙 바뀐다.... )

자 어찌되었든 저건

이렇게 바꾸시면 동작함둥. 저기서 authenticated 를 permitAll 로 바꾸시면 인증권한없이도, 모든 엔드 포인트에 접근이 가능합니다. (일반적으로 비회원도 접근 가능한 곳을 열어주면 되겠지요)

3. 다른 방법으로 구성 설정

이번에는 UserDetailsService와 PasswordEncoder를 구성하는 다른 방법에 대해 소개한다.

비슷하게 UserDetailsService를 선언했지만, 차이점은 이제 재정의된 두 번째 메서드 안에서 로컬로 작업이 수행된다는 것이다. 그리고 AuthenticationManagerBuilder의 userDetailsService() 메서드를 호출해서 UserDetailsService 인스턴스를 등록했다.

만약, 이런식으로 작성했다면, 기능상 아무 문제 없다.

우리는 이걸 얼음이라고 부르기로 했어요. (삼다수바를 보면서)

예. 무슨 소리인지 알거라 생각합니다. 사회적 약속까지는 아니어도, 후임자나 다른 사람이 내 코드를 보면서 이해하기 쉽게 만들어주는게 중요합니다.

이러한 방식도 권장하지는 않지만, 인-메모리 사용자를 위한 구성하는 방법의 예시중 하나이다.

4. AuthenticationProvider 구현 재정의

위에서 본것처럼 스프링 시큐리티 구성 요소들은 상당히 유연해서 애플리케이션 아키텍쳐에 적용할 때 다양한 옵션이 선택 가능합니다. UserDetailsService 와 PasswordEncoder의 목적과 이를 구성하는 방식에 여러한 방법을 배웠으니, 이제 이들 구성 요소에 작업을 위임하는 AuthenticationProvider도 맞춤 구성하는 방법에 대해 배우자.

AuthenticationProvider는 인증 논리를 구현하고, 사용자 관리와 암호 관리를 각각 UserDetailsService 및 PasswordEncoder에 위임한다.

스프링 시큐리티 아키텍쳐에 반영된 책임은 유지하는 것이 좋다. 이 아키텍쳐는 세분화된 책임과 느슨하게 결합됐다.

이런식으로 구현이 가능하다.

5. 프로젝트에 여러 구성 클래스 이용

앞서 구현한 예제들에서는 하나의 구성 클래스만 사용했다. 하지만, 구성 클래스도 책임을 분리하는 것이 좋다. 구성이 복잡해질 수 있기 때문이다. 항상 하나의 클래스가 하나의 책임을 맡도록 하는 것이 바람직하다.

요약

1. 스프링 시큐리티를 애플리케이션의 종속성으로 추가하면 스프링 부트가 약간의 기본구성을 제공한다.
2. 인증과 권한 부여를 위한 기본 구성 요소인 UserDetailsService, PasswordEncoder, AuthenticationProvider 를 구현했다.
3. User 클래스로 사용자를 정의할 수 있다. 사용자는 이름, 암호, 권한을 가져야 한다. 권한은 사용자가 애플리케이션의 컨텍스트에서 수행할 수 있는 작업을 지정한다.
4. 스프링 시큐리티 UserDetailsService의 간단한 구현인 InMemoryUserDetailsManager를 제공한다. UserDetailsService의 인스턴스와 같은 사용자를 추가해서 애플리케이션의 메모리에서 사용자를 관리할 수 있다.
5. NoOpPasswordEncder는 PasswordEncoder 계약을 구현하며, 암호를 일반 텍스트로 처리한다. (운영단계에서는 적합 X)
6. AuthenticationProvider 계약을 이용해 애플리케이션의 맞추혐 인증 논리를 구현할 수 있다.
7. 구성을 작성하는 방법은 여러가지가 있지만, 한 애플리케이션에서는 한 방법을 선택하고 고수해야 코드를 깔끔하고,. 이해하기 쉽게 만들 수 있다.

응애... 이따 오후에 또 시간되면, 작성하고 아니면 그냥 코테 공부해야지...