발표 개요
사내 인증 서버 프로젝트를 소개하며, Keycloak을 왜 도입했는지부터 어떤 기능을 커스터마이징했고 어떤 이슈가 있었는지까지 다루겠다고 연다. 인증에 관심 있는 청중이 참고할 내용을 담았다고 안내한다.
한 번 로그인으로 여러 서비스를 쓰는 SSO의 개념과, 사내에 CAS·아파치 기반 외부 솔루션이 공존하며 인증을 공유하지 못해 이중 로그인이 생기던 문제를 설명한다. 이를 해결할 새 SSO가 필요해진 맥락을 짚는다.
여러 오픈소스 아이덴티티 서버를 후보로 비교하고, 팀이 자바를 쓰고 운영 시 분리 판단이 쉬우며 커뮤니티(깃허브 스타)가 월등한 Keycloak을 대중적 SSO로 판단해 채택한 근거를 정리한다.
Keycloak의 Realm과 Client 단위 설정을 설명하고, 계정 정보가 다른 외부 저장소에 있어도 비교·인증할 수 있도록 User Storage SPI 모듈을 직접 개발해 기존 로그인 로직을 재활용한 구조를 다룬다.
기본 아이디 외에 로그인 아이디로도 로그인, 계정 임시 잠금(브루트포스 방지)의 시간 제약 개선 등을 인증 SPI로 구현하고, 인증 플로우의 Forms를 커스텀 모듈로 대체한다. 테마 기능으로 기존과 동일한 로그인 페이지를 렐름·클라이언트별로 재현한다.
연동 방식을 OIDC로 정했으나 레거시가 SAML을 요구해 같은 브라우저에서 두 방식을 함께 써야 했고, 아파치의 mod_auth_openidc를 CentOS 6에 설치하며 디펜던시·make install로 크게 고생한 과정을 이야기한다.
단일 서버는 잘 되지만 다중 서버 구성에서 인증 모듈이 서버마다 세션을 따로 가져 인증이 실패하는 차이점을 설명한다. 인증 서버 간 세션 정보를 공유하도록 구성한 해결과, 프로토콜·정책적 제약도 짚는다.
Keycloak이 분기 단위로 빠르게 버전을 올려, 이미 퍼진 서비스와 SPI 커스터마이징 탓에 업그레이드마다 충분한 검증이 필요한 부담을 이야기한다. 최신성·안정성·유지보수가 늘 대립한다는 교훈으로 마무리한다.