4. 권한 확인하기.

앞에서 인증은 제대로 동작하지만, 인증 만으로는 보안을 할 수 없습니다. 사용자는 식별할 수 있지만, 해당 사용자가 요청에 대한 권한이 있는지는 별도로 확인을 해야 합니다. 이 일을 해줄 필터과 bean을 등록하겠습니다.

권한을 위해 Acegi에서 제공하는 필터는 FilterSecurityInterceptor입니다.
사용자 삽입 이미지FilterSecurityInterceptor에서는 앞에서 설저한 AuthenticationManager를 사용하며, 그 외에도 AccessDecisionManager와 objectDefinitionSource라는 속성을 설정합니다.

AuthentiactionManager를 사용하여 사용자 정보를 가져오고, ObjectDefinitionSource에 있는 설정과, AccessDecisionManager를 사용하여, 해당 사용자가 요청에 대한 권한이 있는지 확인합니다.

어떤 요청에 대한 필요한 권한을 설정해 놓은 것이 바로 ObejctDefinitionSource입니다. 위 그림의 빨간색 박스에 해당하며, /protected/로 시작하는 모든 요청은 ROLE_HEAD_OF_ENGINEERING 의 role을 가진 사용자에게만 허가합니다. 그것을 제외한 모든 요청은 IS_AUTHENTICATED_ANONYMOUSLY 라는 role이 사용 하도록 했는데, 이 것은 anonymous Filter를 등록했을 때 익명 사용자에게 부여한 권한이라고 생각하시면 됩니다. 나중에 더 자세히 살펴보겠습니다.

이렇게 설정한 상태에서 FilterChainProxy에 여기서 등록한 필터의 이름을 추가해 줍니다.

사용자 삽입 이미지

자 이 상태에서 바라는 것은 다음과 같습니다.
1. /**로 접속 했을 때는 익명 사용자로써, 화면이 보여집니다. 따라서 첫 페이지에 접속할 수 있으며, 로그인 페이지에도 접속할 수가 있습니다.
2. 로그인을 하지 않은 상태에서 /protected/**로 접속했을 때 예외가 발생할 것입니다. 해당 요청에 대한 권한이 없기 때문이죠.
3. ROLE_HEAD_OF_ENGINEERING role을 가진 사용자로 로그인을 한 상태에서라면, /protected/**로 접근 했을 때 화면을 볼 수 있습니다.

발생하는 예외는 다음과 같습니다.
사용자 삽입 이미지org.acegisecurity.AuthenticationCredentialsNotFoundException
필요한 사용자에 대한 정보가 Security Context 객체에 없기 때문입니다.

서버를 종료한 다음 다시 실행하면, 로그인 정보를 기억하지 못합니다. 사용자 정보를 계속해서 유지하려면 필터 하나만 등록하면 됩니다.