Spring Security의 DB 사용 버전 테이블 정의

지난 글에서는 Spring Security의 커스터마이징 포인트로 잡았던 로그인 화면에 대해 정리해보았다. 이번 글에서는 Spring Security의 커스터마이징 포인트로 잡았던 DB를 이용한 로그인과 권한 관리을 구현하기 위한 DB 스키마에 대한 내용을 설명하도록 하겠다.

 

일단 예제 스키마이기 때문에 엉성하게 설계했다. 그러나 이해와 설명하는데 있어서 지장은 없을 정도이다. 각 테이블과 컬럼 관계는 따로 설명은 안하겠으나 컬럼의 설명만으로 이 컬럼이 어떤 테이블의 어떤 컬럼값을 이용하겠다 정도는 암시가 충분히 될 것이다(한마디로 요약하자면 ER 다이어그램 수준의 표현까지는 안하겠다는 의미임..귀차나서..) 그리고 Spring Security에서 제공하는 문서의 부록을 보면 Spring Security에서 사용하는 테이블 스키마 내용이 있다. 이것도 참고삼아 보길 권한다. 사용했던 DB는 Oracle이어서 앞으로 사용할 쿼리도 일반적으로 Oracle용 쿼리를 사용할 것이다. 

 

테이블 이름	MEMBERINFO
테이블 설명	회원 정보 테이블
컬럼 이름	데이터 타입	설명
ID	VARCHAR2(50)	로그인 아이디
PASSWORD	VARCHAR2(300)	로그인 비밀번호(암호화 된 값이 들어감)
NAME	VARCHAR2(30)	회원 이름

 

테이블 이름	AUTHORITY
테이블 설명	권한 정보 테이블
컬럼 이름	데이터 타입	설명
AUTHORITY	VARCHAR2(50)	권한 코드
AUTHORITY_NAME	VARCHAR2(50)	권한 이름(권한 설명)

테이블 이름	MEMBER_AUTHORITY
테이블 설명	회원-권한 테이블
컬럼 이름	데이터 타입	설명
ID	VARCHAR2(50)	로그인 아이디
AUTHORITY	VARCHAR2(50)	권한 코드

테이블 이름	GROUPS
테이블 설명	권한 그룹 테이블
컬럼 이름	데이터 타입	설명
ID	NUMBER	권한 그룹 ID
GROUP_NAME	VARCHAR2(50)	권한 그룹명

테이블 이름	GROUPS_MEMBER
테이블 설명	권한 그룹별 사용자 테이블
컬럼 이름	데이터 타입	설명
GROUP_ID	NUMBER	권한 그룹 ID
MEMBER_ID	VARCHAR2(50)	로그인 ID

 

테이블 이름	GROUPS_AUTHORITY
테이블 설명	권한 그룹별 소유 권한 테이블
컬럼 이름	데이터 타입	설명
GROUP_ID	NUMBER	권한 그룹 ID
AUTHORITY	VARCHAR2(50)	권한 코드

테이블 이름	SECURED_RESOURCE
테이블 설명	리소스 테이블
컬럼 이름	데이터 타입	설명
RESOURCE_ID	VARCHAR2(10)	리소스 ID
RESOURCE_NAME	VARCHAR2(50)	리소스 이름
RESOURCE_PATTERN	VARCHAR2(100)	리소스 패턴
RESOURCE_TYPE	VARCHAR2(10)	리소스 타입(url : URL, method : Method)
SORT_ORDER	NUMBER	순서

 

테이블 이름	SECURED_RESOURCE_AUTHORITY
테이블 설명	리소스에 따른 접근 권한 테이블
컬럼 이름	데이터 타입	설명
RESOURCE_ID	VARCHAR2(10)	리소스 ID
AUTHORITY	VARCHAR2(50)	권한 코드
NAME	VARCHAR2(30)	회원 이름

 

 

이 테이블들에 대한 관계를 대강 설명하자면 회원, 권한, 리소스 이렇게 3가지의 테이블이 각각 관계(회원-권한, 리소스-권한)을 갖는다고 보면 된다. 즉 회원이 어떤 권한을 갖고 있는지 조회하고 접근하고자 하는 리소스에 허용된 권한이 어떤것인지를 확인하여 그것들을 서로 매치시켜 일치하는지 아닌지로 판단하는 개념이다.

 

리소스에 대해 설명하자면 Spring Security가 접근 제어를 할 수 있는 것은 접근 URL 패턴만 있는 것이 아니다. 자바의 메소드 단위로 접근 권한을 체크하여 그에 따라 동작할수도 있으며 Spring의 AOP 작업 또한 접근 권한을 체크해서 동작할 수 있도록 할 수 있다. 이런 URL, 자바 메소드, AOP 코드등을 하나의 리소스로 보고 관리하는 것이다.

 

Spring Security 관련 레퍼런스 문서를 보면 URL과 자바 메소드에 대한 접근 제어만 설명되어 있고 AOP에 대한 부분은 없다. 이 부분은 전자정부 프레임워크 세미나에서 발표자분이 만드신 자료에 있는 부분이다. 이 테이블 스키마 또한 그 자료를 기반으로 만든 것임을 밝혀둔다.

또한 앞으로 계속 설명하면서 다뤄지는 리소스에 대한 것은 URL 패턴만 다룰려고 한다. 이렇게 설계한 것은 차후 확장성을 대비해서 설계한 것 뿐이다.

 

위에 글상자에 언급했지만 리소스는 URL 패턴만 다룰려고 한다. 우리가 만드는 사이트들의 관리자..란 사람들은 웹페이지를 잘 이용하는 사람들이지 직접적으로 코드를 보고 이해하는 수준의 사람들이 아니다. 메소드 패턴을 적용한다고 가정해보자. a.b.c 패키지의 TestD클래스의 addMember 라는 메소드에 권한 설정을 한다고 생각하면 a.b.c.TestID.addMember 이런 식으로 패턴을 적용할 것이다. 이런 패턴을 적용해야겠다..라고 사이트 관리자가 생각할 정도라면 그 관리자는 코드를 보고 직접 이해할 수준의 관리자..라는 의미이다. 그런 관리자가 어디 있겠는가? 굳이 메소드 패턴으로 제어해야 한다면 개발자가 초반에 셋팅을 해주고 그 후엔 잘 건드려지지 않을 것이다. URL 패턴도 마찬가지로 생각할 수 있으나 URL 패턴은 자바 메소드 패턴과는 달리 사이트 관리자 수준이라면 접근이 가능한 패턴(자바를 몰라도 이해할수 있는 패턴)인데다가 새로운 권한이 생겨서 특정 URL 패턴에 적용하거나 특정 URL 패턴에서 특정 권한을 제거해야 하는 상황은 빈번하게 발생할수 있는 상황이기 때문에 이렇게 DB에서 관리할 수 있도록 개념을 잡은 것이다.

 

이상으로 다음과 같이 Database 부분에 대한 설명을 마치도록 하겠다. 다음으로 Spring Security를 커스터마이징 해서 적용하는데 있어 필수로 이해해야 할 사항 중에 사용자와 권한 개념에 대한 설명과 컨셉을 설명하도록 하겠다(여기서 다룰수도 있으나 그럴 경우 글이 길어질뿐 아니라 글에 대해 서로 다른 주제를 다루게 되다보니 다음글로 넘기게 되었다)