현업에서 써먹을수 있게 Spring Security의 커스터마이징 포인트를 잡자

지난번 글에서는 Spring Security의 아주아주 초간단 셋팅을 해봄으로써 Spring Security에서 제공되는 인증의 기능을 맛보게 되었고, 이것을 실제 프로젝트에서 써먹을수는 없다..라는 결론에 도달하며 좌절감을 얻었을 것이다. 그러나 그런 좌절감은 반대로 이걸 극복해볼려는 도전의지를 불태울 재료가 되기도 한다(응? 나만 그런가..) Spring Security 또한 사용자 확장성을 위한 여러가지 포인트를 제공해준다. 비단 Spring Security 뿐만 아니라 Spring Framework 등 SpringSource를 통해 나오는 프로젝트들은 사용자 확장성을 최대한 갖춰줄려고 해준다. 지금부터는 저번에 다루었던 Spring Security 초간단 셋팅을 생각해보며 우리가 현실적으로 맞닥뜨리는 프로젝트에 어떤 식으로 커스터마이징을 해야 할지를 정리해보도록 하자.

 

기억하겠지만 Spring Security에서 제공하는 초간단 로그인 화면..이거 그대로는 절대로 쓸수 없을것이라는데에 다들 공감할 것이다. 메인 화면, 사용자 서비스 화면 등..디자인 잘 되어 있는 화면만 보다가 갑자기 저런 썰렁한 화면을 접한다고 생각해보자. 정말 있을수 없는 일이다. 그렇기 땜에 로그인 화면을 우리가 원하는 로그인 화면으로 교체해주어야 한다.

 

이왕 로그인 화면이 얘기 나와서 하는 말인데 이 부분에 대해서 좀더 정리해보도록 하자. 썰렁한 디자인도 디자인이지만 우리가 사용하는 로그인 화면 형태는 매우 다양하게 있다. 저번 글에서 다루었던 로그인 전용의 화면이 있을수 있으며, 또한 메인 화면에 조그맣게 로그인 기능을 제공하는 그런 기능도 있을수 있다. 또 팝업 형태의 로그인 화면도 다뤄야 하는 상황이 올 수 있다. 즉 로그인 화면에 대한 항목을 잘 분석해 두면 우리가 원하는 어떤 로그인 화면도 Spring Security에서 이용할 수 있게 되는 것이다.

 

또한 로그인 화면에서 제공하는 에러 메시지들을 보자. 일단 영문이다. 또한 내가 출력하고자 하는 메시지가 아니다. 즉 이런 메시지도 내가 원하는 메시지 형태로 바꿔야 한다.

 

다음으로 다뤄야 할 것은 접근권한이 없을때 나오는 에러화면이다. 기본 셋팅으로 할 경우 Http Status Code를 수정함으로써 WAS가 제공하는 에러 화면을 보여주게 되어 있다. 그러나 일반적으로 이렇게 처리하지 않는다. 별도로 지정한 에러화면을 보여준다. 이런 에러 화면을 지정하는 방법도 알아야 할 것이다.

 

로그인 화면과 접근권한 에러 화면에 대해서는 정말 백번 양보해서 그냥 넘어가겠다 하더라도, 지금과 같은 인증절차는 두고 볼수는 없을 것이다. 사용자 인증을 하기 위해 사용자 정보를 어떻게 관리했는지 기억나는가? <user> 태그의 속성으로 관리했다. 테스트로 만들때는 그럴수 있다 해도 사용자가 100명, 1000명 늘어날텐데 그것을 일일이 XML의 태그로 관리한다면?  더군다나 웹사이트의 사용자란 가입과 탈퇴가 반복적으로 일어나는데 그것을 XML 설정으로 한다면? 그런 사이트를 누가 관리할려고 하겠는가? 끔직한 일이다. 기존에 우리가 늘 하듯이 DB로 이를 관리하도록 한다. 또한 패스워드는 암호화시켜서 관리해야 하는데 그 부분이 전혀 이루어지지 않고 있다. 이 부분도 진행해보도록 하겠다.

 

마지막으로 이 부분은 커스터마이징 포인트로 삼지 않을수도 있지만 일단 커스터마이징 한다고 하고 얘기해보겠다. 무엇이냐면 접근 경로에 따른 권한이다. 이전 글에서 보면 <intercept-url> 태그에 접근 경로에 대한 패턴과 이를 접근할 수 있는 권한을 설정한 부분이다. 사실 이 부분은 지금과 같이 해도 상관이 없다. 권한에 대한 접근 경로 설계를 잘 해두었다면 변동사항이 발생할 일이 극히 드물기 때문이다. 그러나 일단 무슨 연유가 되었든 이 부분에 대해 변경사항이 발생했다고 가정해보자. 굳이 예를 들자면 기존에 없었던 권한이 새로 추가가 되면서 이 권한에 따른 접근 경로를 다시 설정해야 한다고 생각해보자. 여러분들이 이런 저런 많은 사이트들을 만들었겠지만, 현업의 관리자란 프로그래머들이 아니다(SM 하시는 분들이 직접 하는 경우는 예외..) 자기가 관리하는 사이트에 열의가 있는 관리자..라 해도 설정파일은 잘 고칠려고 안한다. 문제가 생기면 자기 책임인지라..개인적으로 이런 경험을 좀 해본 경험이 있다. 설정 파일 수정해서 WAS 부팅하면 되는 건데도 직접 와서 해달라고 하는 경우를 많이 겪어봤기 때문이다(내가 겪은 상황은 이통사 프로젝트였고 관리자가 서버쪽을 아주 모르는 사람이 아니었으나 그래도 그렇게 부탁한다) 이런 부분을 만약 관리자 화면을 통해 관리되도록 해준다면? 관리자는 관리자 메뉴얼에 나와있는대로 셋팅해서 적용하면 끝나게 된다. 

 

이렇게 할려면 어떻게 해야 할까? 관리되는 곳이 XML이 아닌 DB와 메모리여야 한다는 얘기다. 즉 DB에 이를 저장하고 WAS 로딩시에 메모리에 로딩되었다가 수정사항이 발생하면 DB에 수정사항을 저장할뿐만 아니라 메모리에 로딩 된 것도 같이 수정되어야 한다. 왜 메모리에 로딩되어 있어야 하는가 하고 질문을 가질 사람이 있을수 있는데 생각해보자. 어떤 사용자가 인증을 거치고 이런저런 경로를 접근한다고 가정해보자. 그때마다 일일이 DB에 질의를 던질것인가? 그럴수는 없다 사용자가 접근하는 페이지마다 일일이 DB에 질의한다면 가뜩이나 게시판 등 여러가지 상황을 상정해서 만든 Connection Pool에 Connection이 남아나질 않게 된다. 심지어 DB를 사용하지 않는 페이지를 방문해도 이걸 체크하기 위해 DB를 조회해야 하는 상황이 온다. 자주 빈번하게 발생하는 상황이기 때문에 메모리에 올려놓음으로써 보다 빠르게 체크할수 있다(실제로 해보면 패턴 위주의 적용이기 때문에 많은 양이 메모리에 올라가지 않는다)

 

일단 모든 프로젝트에 공통적으로 적용되어야 할 커스터마이징 포인트를 다음과 같이 상정해보았다. 위에 좀 장황하게 설명했는데 도표로 정리해보겠다

 

 

커스터마이징 포인트	커스터마이징 내용
로그인	우리가 원하는 로그인 화면으로 교체
	다양한 로그인 화면을 제공
	로그인과 관련된 에러 메시지를 원하는 메시지로 교체
접근 권한 에러 화면	우리가 원하는 에러 화면으로 교체
사용자 인증 절차	DB를 이용한 사용자 인증 절차
	패스워드 암호화 관리
접근 경로에 따른 권한 체크	접근 경로에 따른 권한을 DB에서 관리
	이를 체크할때는 메모리에서 체크

다음 글 부터는 이런 커스터 마이징에 대해 설명해보도록 하겠다