forcs iam part 2
OpenSSO 를 베이스로 하는 프로젝트이다. 2005 년 부터 시작되었고 OpenDJ(LDAP서버) 연계등이 처음부터 고려되어 구성 잘 되어있다. 하지만, 제품이 무겁고 튜닝을 위해서는 높은 학습이 필요하다는 단점이 존재한다.
CDDL-1.0 라이센스
| 복제, 배포, 수정의 권한 허용 | O |
|---|---|
| 배포시 라이선스 사본 첨부 | O |
| 저작권고지시사항 또는 Attribution 고지사항유지 | O |
| 배포시 소스코드 제공의무(Reciprocity)와 범위 | FILE |
| 조합저작물(Lager Work)작성 및 타라이선스 배포 허용 | O |
| 수정 시 수정내용 고지 | O |
| 명시적 특허라이선스의 허용 | O |
| 라이선시가 특허소송 제기시 라이선스 종료 | O |
| 이름, 상표, 상호에 대한 사용제한 | O |
| 보증의 부인 | O |
| 책임의 제한 | O |
- 주요 특징
최초개발자의 부여사항과 기여자의 부여사항을 분리
승소당사자에 대해 변호사 수임료 청구권 인정(제9조)
기여자의 독창적인 창작이며, 관련 권한을 가지고 있다는 내용의 선언(제3조2항)
준거법 선택가능
- 배포시 의무사항
원본 및 수정코드를 CDDL에 의해 배포
배포시 CDDL 라이선스 사본 첨부
수정코드에 대한 소스코드를 합리적인 방식으로 제공
저작권 등 권리관련 사항, 라이선스관련 사항 등의 고지사항을 제거하거나 변경할 수 없음
수정한 경우, 수정코드의 기여자임을 밝히는 고지를 포함
- 아파치 라이센스
RedHat(JBoss) 계열의 제품이다. JBoss진영에서 하던 유사 프로젝트, PicketLink와 2015년 3월에 합병되었다. JBoss 관련 기술에 적응이 되었다면 쉽게 시작 가능하다.
-
공식적으로 도커 지원
-
아파치 라이센스
2009년 부터 시작한 프로젝트로 Sun의 OpenSSO(현재 OpenAM)으로 개발이 되었다가, Shibboleth IDP를 사용하는 등 많은 변화가 있었고 현재는 oAuth2.0을 지원하다.
- MIT 라이센스
포시에스 IAM 의 요구조건을 다시 리뷰해보면
-
유저 프로파일 스키마에 테넌트 정보가 있어야 함.
-
유저의 특수한 상태값을 JSON 또는 Attritube 값으로 발급되는 토큰에 값을 넣을 수 있어야 함. 토큰에 값을 넣을 수 없다면 인증서버가 가지고 있는 토큰 프로퍼티에 값을 기억시켜야 함.
-
리프레쉬 토큰의 기능을 지원.
-
모바일 디바이스 인증 플로우 지원(옵션)
-
토큰을 기반으로 인증을 수행하는 리소스 서버(포시에스에서는 리소스 래퍼)
OpenAM 또는 SSO 오픈소스가 제공하는 기능으로 포시에스 인증서버를 구성한다고 가정할 때 각 솔루션의 수행 여부를 표로 나타내본다.
| / | OpenAM SSO | OpenAM Oauth2 | Custom Build Oauth2 |
|---|---|---|---|
| 유저 프로파일 스키마 제어 | O | X | O |
| 토큰에 프로퍼티 삽입 | O | X | O |
| 리프레쉬 토큰 | X | O | O |
| 모바일 디바이스 인증 플로우 | X | O | O |
| 3th party 확장성 | X | O | O |
| 토큰 기반 리소스 서버 | X | O | O |
| Jwt Oauth 클라이언트 인증 | X | O | O |
| Jwt Oauth 유저 인증 | X | X | O |
OpenAM SSO 와 OpenAM Oauth2 은 동일한 username / password 기반의 데이터 소스를 공유한다는 점 이외에는, 토큰의 운용방식에서 크게 차이를 보인다. OpenAM SSO 의 토큰은 세션토큰이고, 이 세션토큰에 커스텀 프로퍼티를 update 할 수 있는 구조이다. OpenAM Oauth2 의 토큰은 Oauth2 표준스펙에 따른 access_token 이다.
두가지 방식의 토큰간에 상호간의 연결고리는 없다. 따라서 OpenAM Oauth2 를 사용하고자 한다면 OpenAM SSO 의 유저 매니지먼트 기능까지만 사용을 하고, OpenAM SSO 의 토큰발급 체계는 사용할 수가 없다.
만일 OpenAM SSO 의 유저 매니지먼트와 토큰발급 체계까지 사용할 경우, OpenAM Oauth2 를 사용할 수 없으며, 이경우는 단순히 통합인증 기능만을 수행하는 어플리케이션이 된다.
OpenAM SSO 는 전형적인 SSO 서버 수행 방식이다. 이 방식은 유저 프로파일의 자유도를 보장하고, 발급된 토큰의 상태값을 변경시키는 것이 가능하다. 유저는 subject 라고 불리우며 username / password 가 기본구성이다.
인증서버의 가장 기본인 유저정보를 넣기 위해서라도 꼭 필요하며, OpenAM Oauth2 를 사용하더라도 OpenAM SSO 유저 매니지먼트 기능은 베이스가 되어야 한다. 유저정보의 추가/업데이트는 어드민 계정으로 로그인하여 어드민 세션토큰을 발급받아 처리할 수 있다. 유저정보는 OpenDJ ldap 데이터베이스에 적재된다.
유저 세션토큰을 발급받기 위해서는 username / password 를 post 로 전송하면 세션 토큰을 받을 수 있다. 세션토큰 은 매회 로그인마다 계속 새로 발급되며, 이전 로그인에서 발급받은 토큰 또한 계속 유효하다. 세션토큰을 데이터 적재 용도로 쓰고자 할 경우 토큰 프로퍼티의 변경이 가능하다. 토큰에 종속적이지 않는 범용적인 유저 프로파일에서 정보를 다루고 싶다면 유저 매니지먼트 API 로 접근하여야 한다.
추후의 리소스 서버의 구성은 범용적인 아키텍처 설계를 할 수 없으며 OpenSSO 에 종속적인 설계로 가게 된다. 추가적인 튜닝이 이루어지지 않은 상태에서는 rest api 로서만 위의 과정을 구현해야 하고, 이에 따라 발생하는 네트워크 트랜잭션의 횟수를 줄일 수 있는 방안으로 두가지 튜닝방안이 있다.
-
OpenDJ 스키마 변경
-
Jar 어플리케이션을 제작하여 OpenAM Lib 에 등록 (Login 이후 처리에 대한 컨트롤이 가능)
유저 등록과정은 OpenAM SSO 의 유저 매니지먼트를 사용한다.
이후 인증 플로우는 Oauth 2.0 표준 처리방식과 동일하다. 단, 토큰이 Oauth access token 방식이기 때문에 토큰을 데이터 처리 방안의 일환으로 사용할 수 없다. 토큰에 데이터를 기술하기 위한 Jwt 토큰 은 클라이언트 API 인증 처리를 위한 플로우에서만 가능하며, 유저 인증 처리로는 지원하지 않는다.