KeyCloak 핵심 컨셉

원문 : https://www.keycloak.org/docs/latest/server_admin/

Server Administration Guide

 

users : 당신의 시스템에 login을 할 수 있는 엔티티. 해당 엔티티는 email, username, address, phone number, birthday와 같은것과 연결되어 있다. User는 Group 멤버쉽에 할당함으로써 특정한 Role을 할당한다.

authentication : User의 인증 프로세스

authorization : User의 인가 프로세스

credentials : KeyCloak이 User를 확인하기 위한 데이터조각. passwords, one-time-passwords, digital certificates, fingerprints 등이 될 수 있다.

roles : User의 Type과 Category를 식별. Admin, user, manager, employee 등과 같은 것들이 될 수 있다. 어플리케이션(리소스)은 종종 개별적인 User의 권한으로 역할을 정의하기 보다 Role을 지정해 접근하고 허가 받고자 한다. (이는 AWS의 권한관리와 유사한 개념)

user role mapping : Role과 User를 연결을 정의. User에는 Role을 할당하지 않을수도, 하나이상의 Role을 할당할 수도 있다. 이 Role Mapping 정보는 token 과 assertion에 캡슐화 할 수 있다. 이에 따라 어플리케이션은 관리하는 다양한 리소스에 대해서 접근 권한을 결정할 수 있다.

composite roles : 다른 Role과 결합될 수 있는 Role. 예를 들어 superuser composite role은 sales-admin role과 order-entry-admin roles을 결합한다. 만약 User가 superuser role과 매핑된다면 이 User는 sales-admin role과 order-entry-admin role 모두를 상속한다.

groups : User의 집합이다. Role을 Group에다 매핑할 수도 있다.

realms : users, credentials, roles, groups를 관리하는 단위. User는 Realm에 속하게 되고 이 Realm에 로그인하게된다. 하나의 Realm은 다른 Realm과 완전히 격리되므로 고유의 컨트롤할 수 있는 영역이라고 하겠다.

clients : Keycloak에 User 인증을 요청하는 엔티티. Client, 어플리케이션, 서비스는 Keycloak을 자신들의 보안을 위해 사용하고 SSO를 제공한다. Client는 식별 정보나 access token을 요청하는 엔티티를 말하기도 한다. 그리하여 그들은 keycloak으로 보안이된 네트워크 기반하에 다른 서비스를 호출(언급)한다. 

client adapters : 어플리케이션 환경에 설치되어 Keycloak과 안전하게 통신할 수 있도록 지원하는 Plugin. Keycloak은 다양한 플랫폼에 적용할 수 있는 수많은 adapter를 제공하고 있음. Third Party Adapter도 있다.

consent : 당신이 admin으로써 Client가 인증 프로세스에 참가하기 전에 Client에게 접근허가를 주려고 할 때를 말한다. User는 그들의 credential을 제공하고, Keycloak은 이 요청에 대해 화면에 팝업을 띄운다. User는 그 요청에 대해 승인할것인지 결정할 수 있다.

client scopes : Client가 등록되면 당신은 반드시 protocol mapper와 role scope mapping을 정의해야한다. 이때 client scope를 통해 새로운 client를 쉽게 생성하고 일반적인 setting을 가져와 적용할수 있다. 또한 Claim을 요청하거나 Scope parameter 기반하에 조건적으로 Role을 할당하기에 유용하다. 


client role : Client는 그들에게 고유한 Role을 할당할 수 있다. 이것은 해당 Client에 온전히 전담되어 있는 Role Namespace라고 할 수 있다.

identity token : 해당 유저에 대한 식별정보를 제공하는 token이다. OpenID Connect spec의 일부이다.]

access token : HTTP 요청의 일부로써, 서비스의 접근을 허가하는데 사용되는 Token. OpenID Connect와 OAuth2.0의 일부이다. 

assertion : User에 대한 정보. 식별 메타데이터를 제공하는 xml 형식의 SAML인증 응답을 포함하고 있다. 

service account : 모든 Client는 Access Token을 포함하기 위해 Built-in된 Service Account를 갖고 있다.

direct grant : User를 대신하는 Access Token을 가지고 REST 방식의  Client 요청

protocol mappers : 각각의 Client는 어떤 Claim과 Assertion을 OIDC token 또는  SAML에 저장할지 조정할 수 있다. Client마다 Protocol Mapper를 만들거나 환경설정함으로써 이를 달성한다.

session : User가 로그인하였을때 로그인 Session을 관리하기 위한 오브젝트. 

user federation provider : Keycloak은 유저 정보를 저장하고 관리할 수 있다. 일반적으로 회사들은 사용자 정보와 Credential을 저장하고 있는 LDAP 또는 Active Directory 서비스를 갖고 있다. 당신은 다른 외부 Credential 저장소로 부터 식별정보를 가져와 인증서비스를 제공할 수 있는 구성으로 Keycloak을 접점으로 사용할 수 있다. 

identity provider : 사용자 인증을 제공하는 서비스를 IDP라고 한다. 

identity provider federation : Keycloak은 인증기능을 하나 또는 그 이상의 IDP에 위임하도록 설정할 수 있다. Facebook, Google 소셜로그인 이 identify provider federation의 좋은 예이다. 당신은 다른 OpenID Connect나 SAML IDP의 인증을 위임받을 수 있도록 Keycloak을 hook을 걸 수 있다.

identity provider mappers : IDP federation할 때 유입되는 token과 assertion을 User와 Session 속성에 매핑할 수 있다. 식별정보를 외부 IDP로부터 Client가 요청하고 있는 인증정보로 전파할 수 있도록 해준다.

required actions : 사용자가 인증 프로세스 동안에 반드시 수행해야하는 행위를 뜻한다. 이 행위가 완료될때까지 사용자는 인증을 완료할 수 없다. 예를들어 주기적인 비밀번호 변경을 강제하는 프로세스 등이 그렇다. 

authentication flows : 사용자가 반드시 수행해야하는 인터렉션의 흐름을 정의하는 것. 로그인 흐름은 어떤 Credential Type이 요구되는지로 정의될 수 있고. 사용자 등록 흐름은 사용자의 어떤 프로필 정보를 입력해야하는지, 때때로 reCAPTCHA와 같은 추가 bot필터와 같은 것을 대동하기도 한다. Credential 초기화 흐름은 사용자가 그들의 비밀번호 초기화 이전에 수행해야하는 행위들을 정의한다.

events : 관리자가 볼수 있거나 낚아챌 수 있는 감사의 흐름이다. 
Events are audit streams that admins can view and hook into.

themes : 모든 화면은 theme로부터 제공된다. Theme는 HTML 템플릿과 Stylesheet로 이루어져 있다. 이용자가 원하면 Override 할 수 있다.

 

※ 이사람 글 좋다..

https://hudi.blog/open-id/

OpenID(OIDC) 개념과 동작원리