Zeppelin Shiro 인증을 기존 계정 DB와 연결하기

Zeppelin을 기존 플랫폼의 계정으로 로그인할 수 있도록 Shiro 인증을 연결한 적이 있습니다. 계정 정보를 별도 파일에 다시 적는 대신 DB에서 조회하고, 기존에 저장된 비밀번호 형식에 맞춰 비교해야 했습니다.

당시에는 JdbcRealm과 사용자 정의 CredentialsMatcher를 사용했습니다. 이 글은 기존 인증 형식과 연동한 구조를 정리한 기록입니다.

계정 조회와 비밀번호 비교 분리

Shiro의 Realm 은 사용자와 자격 증명 정보를 가져오는 역할을 합니다. JDBC Realm에서는 사용자 ID로 DB를 조회할 쿼리와 데이터 소스를 설정할 수 있습니다.

계정 정보를 가져온 다음 실제 입력값과 저장값을 비교하는 역할은 CredentialsMatcher가 맡았습니다. 기존 저장 형식을 이해하는 matcher를 연결해 로그인 결과를 반환하도록 구성했습니다.

Shiro의 CredentialsMatcher를 구현하고 doCredentialsMatch(AuthenticationToken, AuthenticationInfo)에서 비교 결과를 반환했습니다.

입력한 비밀번호는 token에서, DB가 제공한 저장값은 authentication info에서 읽었습니다. 이후 기존 플랫폼의 처리 방식으로 입력을 변환하고 저장값과 비교하는 구조였습니다.

당시 코드에는 AES로 변환한 값을 비교하는 구현이 있었습니다. AES는 복호화할 수 있는 대칭키 암호화이므로 단방향 비밀번호 해시와는 다릅니다. 기존 데이터 형식과 맞추기 위한 연동이었으며, 새 비밀번호 저장 방식을 설계하는 예제로 볼 것은 아닙니다.

shiro.ini에서는 사용자 정의 matcher를 생성하고, JDBC Realm의 credentialsMatcher에 연결했습니다. 데이터 소스와 인증 쿼리도 같은 Realm에 설정했습니다.

구성 관계는 다음과 같습니다.

text


로그인 요청
  → JDBC Realm에서 사용자 정보 조회
  → CredentialsMatcher에서 입력값과 저장값 비교
  → 인증 결과 반환

인증 처리에서는 입력 비밀번호나 암호화 키를 디버깅 로그로 출력하지 않아야 합니다. 계정 DB에 접근할 실행 설정과 비밀 값도 소스와 나눠 관리해야 합니다.

같은 DB와 비밀번호 비교 방식을 사용하면 기존 계정으로 Zeppelin에 로그인할 수 있습니다. 이것만으로 포털의 로그인 세션까지 자동으로 공유되는 것은 아닙니다.

한 번 로그인한 뒤 별도 인증 없이 이동하는 SSO를 제공하려면 세션이나 인증 토큰을 연결하는 별도 구성이 필요합니다. 당시 matcher와 JDBC Realm 설정은 계정 조회와 자격 증명 비교를 맞추기 위한 작업이었습니다.