Keycloak 인증 솔루션 선택 – 그리고 ext개발

관련기술 모음

  • https://memo.polypia.net/archives/3821

Keycloak vs CAS 선택은

국내에서는 Springboot을 많이 쓰다보니 CAS를 많이 쓸 것 같지만
사용의 난해성 때문에 Keycloak이 더 많이 사용된다
(CAS는 딱 이정도만 해보고 포기 https://memo.polypia.net/archives/3783)

Keycloak을 서비스에 적용하려고 보면 약간의 문제가 있다

  • application 서버와 별도 인스턴스를 띄워야한다는 문제
  • 회원 디비가 application과 별도로 관리된다는 문제

해야하는 일

  • 로그인, 회원가입 화면 만들기 – 보통 테마만 추가
  • 커스텀 회원정보 수정화면/기능 만들기 application에 또는 keycloak 커스텀
  • 회원가입, 로그인 로그 저장
  • 회원가입, 로그인 이벤트 전달

어려운 부분

  • 회원디비를 application에 두고 연동해서 사용
    이건 매우 어렵다. 잘 안된다. 극한의 커스터마이징을 하려면… 그냥 따로 만드는게 낫다
    서비스 초반에는 있는 그대로 쓰자….
  • 디비를 공유
    캐시때문에 싱크가 안맞다
  • 그냥 무엇이건 커스터마이징…

간단하게 결론을 내면
뭘 쓰건 기본기능 그대로 쓸게 아니라면 사용이 쉽지는 않다.

초반에는 서비스를 오픈소스에 맞춰서 쓰자

Keycloak 사용후기

keycloak은 간편한 편이다.
그런데 서비스 개발용이 아니라 블로그, 위키 등 운영 용으로 만들어진게 아닐까?
개발자가 서비스를 개발할 때 사용하기는 불편하다.

(14버전쯤)추가기능 구현도 도큐먼트 대로 되지도 않고 엄청 복잡했는데
한달정도 보다보니 구조파악이 되고 좀 할만해졌다. 소스보고 알아서 분석해서 써야한다.
그냥 도큐먼트만 보고 하려면 rest api 호출하는것도 쉽지가 않다.(공식문서에 주소를 엉터리로 적어놔서 ㅋ)

keycloak 소스코드와 포럼의 질문답변을 잘 읽어봐야한다

JBoss 스타일로 만들어져서 Spring생태계에 익숙한 개발자가 접근하기 쉽지 않다
jas-rx 기반 resteasy, wildfly 서버, jboss의존성 관리 등등..

  • https://github.com/keycloak
  • https://github.com/ScriptonBasestar-io/keycloak-providers
  • https://github.com/thomasdarimont/keycloak-user-storage-provider-demo
  • https://www.baeldung.com/java-keycloak-custom-user-providers
  • https://github.com/thomasdarimont/keycloak-extension-playground
  • https://github.com/zonaut/keycloak-extensions

인증(로긔인)서비스 – IAM/SSO 관련기술

완제품

  • Keycloak
    https://github.com/keycloak/keycloak
  • Gluu
    https://gluu.org/docs/gluu-server/4.1/installation-guide/install-docker/
  • OpenAM, OpenDJ
    https://github.com/OpenIdentityPlatform/OpenAM
  • JOSSO
    http://www.josso.org/
    https://github.com/atricore/josso2
  • LemonLDAP
    https://lemonldap-ng.org/welcome/
    https://github.com/LemonLDAPNG/lemonldap-ng-docker
  • Shibbolet ldp
    https://wiki.shibboleth.net/confluence/display/DEV/Source+Code+Access
    https://github.com/Unicon/shibboleth-idp-dockerized
  • 389 Directory Server
  • CAS https://github.com/apereo/cas
  • GLAuth
  • RazDC
  • FreeIPA
    https://www.freeipa.org/page/Main_Page
  • https://github.com/jasny/SSO
  • https://github.com/heipei/nginx-sso
  • https://github.com/IdentityServer
  • https://github.com/freeipa/freeipa
  • https://github.com/wso2/product-is
  • https://github.com/authelia/authelia
  • WSO2 identity server
  • AmazonCognito

라이브러리

  • CAS
  • https://github.com/spring-projects/spring-security-saml
  • https://github.com/spring-projects/spring-security-oauth
  • https://github.com/spring-projects/spring-security-kerberos
  • https://github.com/samitpal/simple-sso
  • https://github.com/go-oauth2/oauth2
  • Apache Shiro
  • https://github.com/jcasbin/shiro-casbin
  • pac4j
  • Apache CFX https://cxf.apache.org/
  • Apache Fortress
  • geronimo.apache.org
  • https://casbin.org/
  • https://github.com/casbin/jcasbin
  • https://github.com/casbin/casbin
  • https://github.com/OpenConext/Mujina
  • https://github.com/pac4j/spring-webmvc-pac4j
  • https://github.com/Neloop/jaclp

프로토콜

  • OAuth
  • JWT
  • SAML
  • Kerberos
  • Radius
    https://www.gnu.org/software/radius/
  • CAS
  • Session
  • BasicAuth
  • LDAP
  • OpenID

REF

  • https://www.getkisi.com/blog/authentication-protocols-overview
  • https://en.wikipedia.org/wiki/Authentication_protocol
  • https://www.geeksforgeeks.org/types-of-authentication-protocols
  • https://developer.okta.com/docs/concepts/saml
  • https://en.wikipedia.org/wiki/Single_sign-on
  • SAML : https://bcho.tistory.com/755
  • https://www.baeldung.com/spring-security-cas-sso

CAS – 로컬실행/개발환경 만들기

뭔가 괜찮은 것 같으면서도 애매한 오픈소스 프로젝트…
복잡함 때문에 몇 번 사용하려다가 포기 했는데 이번에 인증서비스를 만들면서 다시 사용하려고 한다.

jasig CAS일 때 보고 apereo로 바뀐거 보고… 세번째 정도인 것 같다.
이전에는 기능을 축소해서 직접 개발했었는데

복합인증을 구현하려면 쓰는게 나을 것 같다

경쟁제품

유료 무료 다 포함해서 대강

무료

  • Keycloak
  • CAS
  • JOSSO
  • LemonLDAP
  • Shibbolet ldP
  • OpenAM
  • Gluu
  • https://freeradius.org/

유료

  • Auth0
  • AWS Cognito

기타

  • https://gist.github.com/bmaupin/6878fae9abcb63ef43f8ac9b9de8fafd
  • https://www.gluu.org/blog/gluu-versus-keycloak/

조금씩 특성이 다르긴 하다.

CAS 특징

  • 프로젝트가 굉장히 잘게 나눠져 있다.
    모듈형으로 가져다가 사용하라는 것 같은데…
    의존성이 복잡해서 그렇게 쓸 수가 없다
    도큐먼트는 사용법에 관한 것만 있고
  • 설치형으로 사용하려고 보면…
    cas-overlay-template 라는게 있기는 한데
    기본으로 지원되는 부분을 제외하면 설치형으로 쓸 수 있는건 아니고 거의 소스레벨에서 수정해서 써야만 한다.
  • 스프링을 매우 잘 쓴다. 나도 스프링 꽤 써봤다고 생각했는데 처음보는게 조금씩 보인다
  • Springboot autoconfigure 사이의 엄청난 충돌이 발생
    실행형으로 만들게 아니라면 그냥 없애야 하지 않을까

어쨌든 소스레벨에서 분석해서 사용해야 하고
필요한 부분만 뽑아쓰긴 힘들어 보인다

설치방법

소스

docker 컨테이너를 제공 해 주면 좋겠는데…. 커스텀을 해서 쓰라는 철학을 가지고 있는 애들이라 그런지 통짜로 제공 해 주지는 않는다.
그래도 쓰기 편하게 템플릿이 제공된다.

https://github.com/apereo/cas-overlay-template

이런것도 제공 해 주고 많이 발전했다.

아래 순서대로 치다보면 뭐가 뭔지 알 수 있을거다. README.md와 비슷하지만 약간 다르다.

git clone https://github.com/apereo/cas-overlay-template cas-server
cd cas-server
./gradlew clean build
./gradlew downloadShell runShell
./gradlew allDependencies

설정파일 수정

docker-compose 실행테스트를 해야되서 설정파일을 수정 해 준다

# /etc/cas/config/cas.properties

logging.config=file:/etc/cas/config/log4j2.xml

server.port=8080
server.ssl.enabled=false

실행

docker-compose up

화면수정

수정가능 항목의 목록을 얻는 명령어

./gradlew listTemplateViews

템플릿을 소스코드로 가져오는 명령어

./gradlew getResource -PresourceName=[여기뭐가들어갈까]

기능수정

이쪽 철학이 그런가보다. 디비를 직접 관리하거나 하지 않는다.
그럴거면 jpa 연동하기 쉽게 인터페이스를 달아주던가 하면 좋을텐데 그런건 또 안해놨다.

트리거 설정

각 기능이 실행될 때 마다 앞뒤로 트리거를 달 수 있다.
인터셉터
groovy

아직 안해봐서잘 모르겠지만 할 수 있다.

배포

리버스 프록시 사용

요즘 리버스 프록시 안쓰는 경우가 더 드물지 않을까

cas.server.name=https://domain.tld
cas.server.prefix=/

server.port=8080
server.ssl.enabled=false
cas.server.http.enabled=false
cas.server.httpProxy.enabled=true
cas.server.httpProxy.secure=true
cas.server.httpProxy.scheme=https
cas.server.httpProxy.protocol=HTTP/1.1

결론

overlay template 설치하려면 keycloak, gluu 등 다른 쉬운걸 쓰는게 나을것으로 보인다
인증방식은 어차피 다 표준프로토콜이 있어서 한두개 빼고는 다 비슷하게 제공된다

소스레벨에서 사용하려면 cas를 쓰는게 나을까… 그냥 만드는게 나을까
아직 시작단계라 정확하지는 않지만
이걸 쓰기보다는 필요한 부분 소스만 참고해서 따로 만들게 될 것 같다

REF

  • https://apereo.github.io/2019/01/07/cas61-gettingstarted-overlay/
  • https://apereo.github.io/cas/6.3.x/configuration/Configuration-Server-Management.html
  • https://apereo.github.io/2018/01/05/cas-deployment-with-proxy/

SSO(SingleSignOn) – Solution vs 직접개발

개요

요즘엔.. SSO 관련 개발은 거의 필수인데
막상개발하려면 여기저기 다 있는거 또 만드는 것 같은 생각이 들지만…
오픈소스나 뭐 갖다 쓰려고 하면 또 마땅한게 없다.

대안

OpenSource

JOSSO : 설치하면 실행된다. 쉽게 사용은 가능한데 커스터마이징도 쉬울까가 고민..
CAS : 코드가 매우 복잡.. 잘 이해가 안간다. 새로 만드는게 더 빠르지 않을까? 그냥 실행되는것도 아니라서 갖다쓰기도 편하지 않다.

상용Commercial

직접개발

관련기술

SAML : 삼를.. 잘 모르겠다.
http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/id_roles_providers_saml.html
OAuth : 오앗. 토큰받아다가 쓰는거. 많이 쓰니까 설명생략
GlobalCookie : 여러서버에서 동일한 네임의 쿠키를 바라본다. auth서버를 호출해야겠지
IP : 접속주소
MacAddress : 랜카드 주소기반
LDAP : 디렉토리 서비스 계층형으로 권한을 저장하는방식??/정도로 알고있는데..
Token : Stateless 호출에 사용. API에 많이 사용됨
등등…
다 지원되면 좋겠지만 다 하기는 힘들고 필요한것만 사용하는게 좋다.

~~~~~

위의 기술을 그대로 구현할수도 있고.. 유사하게 구현할수도 있고..라이브러리를 갖다쓸 수도 있고

이전에 쓸 때는 OAuth서버를 구현하고 OAuth(Like)방식으로 내부 SSO를 구현했는데…
좀 개선해보려면 어떻게 하는게 좋을지