안녕하세요.

devops, se 관점에서 Keycloak을 운영할때 필요한 것들을 알아본다.

1. IAM 관리시 알아야할것들

1-1) 계정 생성 및 관리
  패스워드 분실등 관리자가 서버 이벤트에 대한 알림을 받을 이메일 발송에 필요한 SMTP 설정

1-2) 그룹 생성 및 관리

1-3) realm 생성 및 관리

realm을 어떻게 관리하는게 B/P일까 ?
우선 마스터 realm은 시스템 관리(other realm 생성 관리)에만 사용해야하고 실제 클라이언트는 용도에 맞게 other realm을 생성해서 포함시켜줘야 한다.

그렇다면 Realm은 어떤 환경에따라 분류를 해줘야할까 ?

2. 디비 백업

3. 로그 관리

4. 주요 SP별 연동 방법

5. 알아두면 좋은 기능들

6. 고가용성 방안

7. 이중화

8. 실 서비스에 keycloak 사용하는법(keycloak을 브로커로 구성)

1. 인증되지 않은 사용자가 클라이언트 애플리케이션에서 보호된 리소스를 요청합니다.

2. 클라이언트 애플리케이션은 인증하기 위해 사용자를 Keycloak으로 리디렉션합니다.

3. Keycloak은 영역에 구성된 ID 공급자 목록이 있는 로그인 페이지를 표시합니다.

4. 사용자는 버튼 또는 링크를 클릭하여 ID 공급자 중 하나를 선택합니다.

5. Keycloak은 인증을 요청하는 대상 ID 공급자에게 인증 요청을 발급하고 사용자를 ID 공급자의 로그인 페이지로 리디렉션합니다. 관리자는 이미 관리 콘솔의 ID 공급자에 대한 연결 속성 및 기타 구성 옵션을 설정했습니다.

6. 사용자가 자격 증명을 제공하거나 ID 공급자에 인증하는 데 동의합니다.

7. ID 공급자가 인증에 성공하면 사용자는 인증 응답과 함께 Keycloak으로 다시 리디렉션됩니다. 일반적으로 이 응답에는 Keycloak에서 ID 공급자의 인증을 신뢰하고 사용자 정보를 검색하는 데 사용하는 보안 토큰이 포함됩니다.

8. Keycloak은 ID 공급자의 응답이 유효한지 확인합니다. 유효한 경우, 사용자가 아직 존재하지 않는 경우 Keycloak는 사용자를 가져와서 만듭니다. 토큰에 해당 정보가 포함되어 있지 않은 경우 Keycloak는 ID 공급자에게 추가 사용자 정보를 요청할 수 있습니다. 이 동작을 ID 페더레이션이라고 합니다. 사용자가 이미 존재하는 경우, Keycloak는 ID 공급자로부터 반환받은 ID를 기존 계정과 연결하도록 사용자에게 요청할 수 있습니다. 이 동작을 계정 연결이라고 합니다. Keycloak에서는 계정 연결을 구성하고 첫 로그인 플로우에서 계정 연결을 지정할 수 있습니다. 이 단계에서 Keycloak은 사용자를 인증하고 토큰을 발급하여 서비스 공급자의 요청된 리소스에 액세스할 수 있도록 합니다.
9. 사용자가 인증하면 Keycloak은 로컬 인증 중에 이전에 발급한 토큰을 전송하여 사용자를 서비스 공급자로 리디렉션합니다.
10. 서비스 공급자는 Keycloak으로부터 토큰을 받고 보호된 리소스에 대한 액세스를 허용합니다.

이 흐름의 변형이 가능합니다. 예를 들어, 클라이언트 애플리케이션에서 ID 공급자의 목록을 표시하지 않고 특정 공급자를 요청하거나, 사용자가 ID를 페더레이션하기 전에 추가 정보를 제공하도록 Keycloak을 설정할 수 있습니다.

인증 프로세스가 끝나면 Keycloak는 토큰을 클라이언트 애플리케이션에 발급합니다. 클라이언트 애플리케이션은 외부 ID 공급자와 분리되어 있으므로 클라이언트 애플리케이션의 프로토콜이나 사용자 신원을 검증하는 방법을 볼 수 없습니다. 공급자는 Keycloak에 대해서만 알면 됩니다.

구글 계정을통해 keycloak으로 연동한 saml로 실 서비스에 로그인하기.

version: '3.7'
services:
  reverse-proxy:
    image: traefik:v2.9
    restart: always
    ports:
      - '80:80' # http
      - '443:443' # https
      - '8080:8080' # https
    networks:
      - harbor
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./letsencrypt:/letsencrypt
    command:
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--providers.docker.network=harbor"
      - "--entrypoints.websecure.address=:443"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.ssh.address=:2222"
        #- "--entrypoints.web.http.redirections.entrypoint.to=websecure"
        #- "--entrypoints.web.http.redirections.entrypoint.scheme=https"
      - "--certificatesresolvers.myresolver.acme.tlschallenge=true"
      - "--certificatesresolvers.myresolver.acme.email=sabo@infograb.com"
      - "--certificatesresolvers.myresolver.acme.storage=/letsencrypt/acme.json"
      - "--certificatesresolvers.myresolver.acme.httpchallenge.entrypoint=web"
      - "--api.insecure=true"
networks:
  harbor:
    external: true

gitlab 과 keycloak을 연동해서 인증시스템을 구축해볼것이다.

그전에 관련 용어 설명

keycloak - 오픈소스 IAM 솔루션

okta - 상용 IAM 솔루션

IAM(Identity and Access Management) - User ID, 암호를 통해 계정을 생성&관리하고 권한을 할당하여 접근제어(인증, 인가, 감사등)

즉 IAM이란 어떤 솔루션이나 프로토콜을 의믜하는게 아니고 보안행위 및 규칙등을 의미하고

IAM을 하기 위한 솔루션으로 keycloak 과 Okta등이 있는것.

더 자세히 들어가보면 IAM 솔루션들의 구성요소, 프로토콜이나 보안 정책등을 알아보자면

1. SAML - 인증정보를 중앙 관리하여 한번의 디지털 서명(ID, PW)으로 설정돼있는 모든 리소스(SAML을 제공하는)에 접근 가능.
   로직은 다음과 같다.
   요청(사용자가 로그인 시도) > 검증(SAML과 IDP 연결) > 로그인(ID, Password 입력창 표시) > 토큰생성(사용자 정보 올바를시 SAML 토큰이 전송되어 서버에 로그인)

2. OAuth - 한번의 로그인(자격증명 성공)으로 얻은 토큰을 다른서비스에 로그인(인증)시 해당 토큰을 전달하는데 사용(ID,PW를 전달해주는게 아님). 단 조건은 사전에 IdP에서 사용자의 승인을 받아 리소스 서버에 토큰을 발행할수 있어야 함.

로직은 다음과 같다.

요청(사용자가 로그인 시도) > 선택(로그인 방법으로 타사 권한 인증 선택) > 로그인(인증 서버가 액세스 토큰 생성하여 리소스 서버에 전송) > 연결(리소스 서버가 토큰 확인후 접근 허용)

SAML과 OAuth의 유사점과 차이점은?

먼저 유사점은 SAML과 OAuth를 사용(한번의 로그인)으로 여러 서비스의 접근이 가능(SSO)해지는것.

예를들어 구글(IDP)계정을 가지고 깃랩도 로그인하고 페북도 로그인하고 플럼버도 로그인하고.. 이런것들이 SAML 혹은 OAuth를 가지고 SSO 기능을 구현했다라고 볼수있음.

차이점은 SAML=인증 / OAuth = 인가이다. SAML의 경우 구글(IDP)계정들의 아이디/패스워드들을 가지고 인증을 받아 다른 서비스에 로그인하는것.

OAuth는 구글에서 받은 토큰을 로그인 하려는 다른 서비스에 등록, 즉 권한을 허가 받아 다른서비스에 로그인하는것

로그인에 초점을 맞추면 둘중 하나만 사용하면 되고.

좀더 보안을 강화하려면 일단 로그인은 SAML(인증된자만)로 접근가능하도록 하고 그 서비스 로그인 이후의 하위서비스 접근은 OAuth(인가된자만)로 접근 가능하도록 처리하면 보안을 좀 더 강화할 수 있다

3. OIDC - 인증을 위해 OAuth에서 인증부분을 확장하여 구현된 프로토콜

OAuth에서 openid 스코프가 포함돼있으면 OIDC임. oauth 스코프에 openid가 있으면 oauth의 본래 목적인 액세스토큰(인가정보)외에 추가로 인증정보인 ID토큰(JWT)을 반환함.
##인증과 인가의 차이 : 인증 - 신원 검증 / 인가 - 권한 부여

즉 OIDC는 인가가 아닌 인증을 위해 OAuth에 인증이 확장된 개념이다.

앞의 내용을 다 이해했다면 OAuth와 OIDC를 각가 언제 사용해야 하는지 이해했을듯 하다.

그럼 둘다 인증이 목적인 SAML과 OIDC은 특징 및 장단점이 뭐고 각각 언제 쓰일까 ?

SAML - XML 기반, OIDC보다 상대적으로 느림, 메시지 크기가 큼, 20년전부터 널리 사용됐기에 스탠다드함. 따라서 기존 시스템과의 호환성이 높음. 기존 엔터프라이즈 환경에서 더 잘 어울려 왔음

OIDC - JSON 기반, 처리속도가 빠르고 사이즈가 작음. 최근(5~7년전)에 각광받고 있음. 여러 환경에서 사용됨.

장단점만을 본다면 OIDC가 더 좋아보이나 기존 엔터프라이즈 환경에서 SAML이 이미 많이 사용되고 있었기에 보안규정 및 지침등이 SAML에 맞게 표준화 돼 있었음. 따라서 아주 빡세게 보안규정을 지켜야한다면 OIDC보단 그에 맞는SAML을 채택하는게 맞고 그게 아니라면 OIDC가 더 유리하다고 판단됨

하여 아직까진 SAML을 많이 사용하나 OIDC도 많아지는 추세임.

그외 

SSO - 싱글사인온. 하나의 인증/인가로 해결하는것

IdP - identitiy provider. 즉 인증/인가정보를 제공하는곳.(구글, 카카오, 페이스북등)

JWT - Json웹 토큰 - 사용자 인증정보를 json 구조로 구성. OIDC가 JWT로 인증을 주고받음