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

관련기술 모음

Keycloak vs CAS 선택은

국내에서는 Springboot을 많이 쓰다보니 CAS를 많이 쓸 것 같지만
사용의 난해성 때문에 Keycloak이 더 많이 사용된다
Keycloak에서 커스터마이징 해서 추가기능은 구현할 수 있지만 약간의 문제가 있다
– 별도 인스턴스를 띄워야한다는 문제
– 기본지원되는 형태로 사용해야하는 문제
극한의 커스터마이징을 하려면… 그냥 따로 만드는게 낫다
서비스 초반에는 있는 그대로 쓰자….

CAS는 뭔가 실행하는 것도 매우 힘들고 라이브러리처럼 사용해야하는데 그것도 힘들다. 도큐먼트도 없고… 그냥 인증스펙 구현을 어떻게 했는지 참고하는 코드로 쓰기는 좋다
https://memo.polypia.net/archives/3783

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

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

Keycloak 사용후기

개인적인 경험으로 봤을 때 keycloak이 CAS보다 간단하다.
그냥 기본기능을 가지고 사용하기도 쉽고
추가기능 구현한달정도 보다보니 구조파악이 되고 좀 할만해졌다

JBoss기반으로 만들어져서 Spring생태계에 익숙한 개발자가 접근하기 쉽지는 않다
jas-rx 기반 resteasy, wildfly 서버, jboss의존성 관리 등등..
그냥 도큐먼트만 보고 하려면 rest api 호출하는것도 쉽지가 않다.(공식문서에 주소를 엉터리로 적어놔서 ㅋ)
keycloak 소스코드와 인터넷 질문답변을 잘 읽어봐야한다
그리고 샘플 확장코드들

  • 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

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와 비슷하지만 약간 다르다.

설정파일 수정

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

실행

화면수정

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

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

기능수정

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

트리거 설정

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

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

배포

리버스 프록시 사용

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

결론

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/

RubyOnRails 회원/권한 관리 Framework 목록

회원관리 솔루션

Devise

제일 많이 사용되는 솔루션. 특별한 이유가 없다면 이걸 쓰면 된다.
https://github.com/heartcombo/devise

Clearance

https://github.com/thoughtbot/clearance

CanCan

더 이상 업데이트가 되지 않고 있다.
https://github.com/ryanb/cancan

CanCanCan

Devise에 비하면 Star도 적고 특별히 차별화 되어있지 않다. Devise가 질렸다면 써볼수도 있겠지만…

권한관리 솔루션

PunchIt

Authlogic

https://github.com/binarylogic/authlogic
가장 최근 생긴 프로젝트로 업데이트 잘 되고 있는 것 같다

SpringSecurity 에서 사용자 정보 (받아오기)뽑아서 쓰기

스프링 시큐리티를 사용하다가 사용자 정보를 뽑아서 써야되는데 참 갑갑할때가 있다.

내가 만든 것도 아니라서 어디서 뽑아다가 써야될지도 잘 모르겠고

스프링 시큐리티 너무 복잡해서 어떻게 찾을지도 잘 모르겠고 그럴때가 많다.

google search keyword : spring security get current user details

http://stackoverflow.com/questions/248562/when-using-spring-security-what-is-the-proper-way-to-obtain-current-username-i

스택오버플로우가 글이 날라가지는 않을 것 같지만 혹시나 해서 그냥 퍼놔야겠다.

1. SpringSecurityContextHolder를 사용하는 방법

2. 뭔지 잘 모르겠는데 좋아보이는 방법 – 토큰을 집어오는것같다.

3. User는 아니지만 UserPrincipal을 가져오는 방법

 

 

ACL,Access Control List 접근 제어 목록

사용자별로 권한을 부여하고 그 권한을 바탕으로 접속 허용 여부를 결정하는 것을 말한다.

값은 보통 String을 사용한다.

 

guest, member, admin 세개의 권한이 있다.

사용자들은 위 권한중의 몇 가지(중복가능)의 권한을 가지고 있다.

권한은 사용자가 가진 최상위 권한을 우선 적용한다. 구현하기 나름이지만… member {student, teacher} 이런식으로 포함관계를 갖게 만들수도 있고 {minsu, dongsu}와 같이 수평 개념으로 만들수도 있다.

예1)

연습장에다가 다음의 사용자 이름을 적어본다

이건희, 이재용, {내이름}, 박정희

다음의 사용자가 있다고 가정하고 {guest, admin, member} 세개의 권한을 적당히 줘 본다.

예2)

그럼 다음 기능에 권한을 줘 보자

{사용자목록보기, 공지사항읽기, 공지사항댓글쓰기, 자유게시판 읽기}

(역시 구현하기 나름이지만 기능에 권한을 줄 수도 잇고 페이지에 줄 수도 있다. 도쿠위키의 경우는 페이지에 준다.)

 

이거 대충 보고 dokuwiki를 설치하고 ACL설정을 해 보면 곧 이해가 갈 것이다.

굳이 dokuwiki를 찝어서 말한것은…. 이게 설치하기 쉬우니까