Keycloak 시작하기 5

이번글에서는 다양한 인가 전략(Authorization strategies) 옵션과 RBAC(Role-Based Access Control), GBAC(Group-Based Access Control), OAuth2 scopes 그리고 ABAC(Attribute-Based Access Control)과 같은 접근 제어 메커니즘을 사용해 애플리케이션 인가를 활성화하고 사용하는 방법을 작성하겠습니다. 또한 해당 옵션의 차이점과 가장 적합한 전략을 선택하는 방법에 대해서도 작성할 예정입니다.

 

1. 인가란?

모든 인가 시스템은 사용자가 리소스에 접근하고 해당 리소스에 대한 작업 가능 여부를 판단합니다. 

ID 공급자로서 Keycloak은 애플리케이션에게 토큰을 발행합니다. 따라서 애플리케이션은 해당 토큰이 인가 데이터를 포함하고 있다고 예상할 수 있습니다. Keycloak에서 발생한 토큰은 사용자에 대한 정보와 사용자가 인증된 컨텍스트를 전송합니다. 컨텍스트는 사용중인 클라이언트에 대한 정보 또는 인증 프로세스 과정에서 수집된 기타 정보를 포함할 수 있습니다. 하지만 제약 사항에는 사용자가 갖고 있는 단일속성, 하나 이상의 역할 집합 또는 현재 트랜잭션과 관련된 데이터에 이르기까지 다양한 유형의 데이터가 포함될 수 있습니다. 토큰에 포함된 정보에 따라 애플리케이션은 보호된 리소스에 대한 접근을 수행할 때 토큰에 포함된 클래임을 해석하는 방법에 따라 다양한 접근 제어 메커니즘을 선택할 수 있습니다. 보호된 리소스에 적용되는 접근 제한을 구현하고 적용하기 위한 2가지 주요 인가 패턴이 존재합니다. 가장 일반적인 패턴은 일부 메타데이터 및 설정을 사용해 선언적 또는 프로그래밍적인 방식으로 애플리케이션 수준에서 접근 제어를 수행하는 것입니다. 다른 하나는 애플리케이션이 접근 허가 여부를 외부 서비스에 위임하고 해당 서비스에서 수행된 결정을 기반으로 접근 제어를 수행할 수도 있습니다. 그 해당 패턴은 통합 인가라고 합니다. 2개의 패턴은 상호 배타적이지 않으며, 애플리케이션에 2개의 패턴을 사용할 수 있습니다. Keycloak은 매우 유연하며 다양한 접근 제어 메커니즘을 사용해 애플리케이션 수준에서 리소스를 보호하기 위해 필요한 모든 정보를 교환할 수 있습니다. 또한 접근 제어를 관리하고 수행하기 위해 다양한 인가 패턴 중에서 해당 접근 제어 매커니즘을 선택할 수 있습니다.

 

2. RBAC (Role-Based Access Control) 활용

가장 많이 사용되는 접근 제어 메커니즘 중 하나인 RBAC를 통해 사용자에게 부여된 역할에 따라 리소스를 보호할 수 있습니다. Keycloak에는 역할 관리뿐만 아니라 토큰을 사용해 애플리케이션에 역할을 전파할 수 있는 기능을 내장하고 있습니다. 역할은 일반적으로 조직 또는 애플리케이션 컨텍스트에서 사용자가 갖는 역할을 나타냅니다. 예를 들어 사용자에게 애플리케이션의 모든 리소스에 접근하고 작업을 수행할 수 있는 권한을 가진 관리자 역할을 부여할 수 있습니다. 또는 하위 조직과 관련된 자원에 접근하고 작업을 수행할 수 있는 권한을 가진 people-manager 역할을 부여할 수 있습니다.

 

Keycloak은 realm 및 client와 같은 두 종류의 역할을 갖고 있습니다. realm 레벨에서 정의된 역할을 realm roles라고 합니다. 해당 역할은 일반적으로 realm에 공존하는 다양한 클라이언트에 관계없이 조직 내에서 사용자의 역할을 나타냅니다.

반면 client roles는 클라이언트에 따라 다르며, 역할의 의미는 클라이언트가 사용하는 시맨틱에 따라 달라집니다. 

역할은 realm 또는 클라이언트 역할로 정의하는 시점에 대한 결정은 역할이 갖고 있는 범위에 따라 달라집니다. 해당 범위가 동일한 의미를 유지하면서 realm의 여러 클라이언트에 포함돼 있는 경우 realm 역할은 유효합니다. 그에 반해 특정 클라이언트만 역할을 수행해야 하는 경우 클라이언트 역할을 사용하는 것이 더 적절합니다.

역할을 사용하는 경우 무분별한 역할 사용을 피해야합니다. 즉 시스템에 과도하게 많은 역할이 있는 경우 관리하기 어렵게 될 수 있습니다. 해당 문제를 방지하기위한 한가지 방법은 역할이 관련된 범위와 애플리케이션에서 역할과 관련된 권한의 세분성을 고려해 매우 신중하게 역할을 생성하는 것입니다. 역할의 범위가 세분화될수록 시스템에는 더 많은 역할이 존재합니다. 경험에 비춰볼때, 세분화된 인가를 위해 역할을 사용하는것을 권장하지 않습니다. 역할은 인가를 위해 사용하면 안됩니다. 

Keycloak에서는 그룹에 역할을 부여할 수 있습니다. 그룹 멤버들은 해당 그룹의 역할을 자동으로 부여받기 때문에 유용한 기능입니다. 해당 기능을 활용하면 특정 권한을 개별 사용자에게 각각 부여하지 않아도 되기 때문에 역할 관리 이슈를 해결할 수 있습니다. 

Keycloak은 또한 다른 역할을 연결하는 특별한 유형의 복합 역할 개념을 제공합니다. 복합 역할을 부여받은 사용자는 체인에 포함된 모든 역할이 자동으로 부여됩니다. 해당 기능은 Keycloak의 강력하고 고유한 기능이지만 여러 복합 역할을 연결하는 경우 발생할 수 있는 성능 문제와 시스템의 역할 확산 및 권한의 세분화로 인한 관리 효율성 문제를 예방하기 위해 신중하게 사용해야합니다. 사용자에게 다양한 역할을 부여해야 하는 경우 그룹을 사용해 해당 그룹에 역할을 할당하는 것을 권장합니다. 그룹을 사용하는 것이 복합 역할을 사용하는 거보다 더 적절한 권한 모델입니다.

시스템 역할을 모델링하는 방법은 Keycloak에서 발행하는 토큰의 크기에도 영향을줍니다. 

토큰에는 클라이언트가 로컬에서 또는 해당 토큰을 사용하는 다른 서비스에 접근할 때 사용자에게 권한을 부여하는 데 필요한 최소한의 역할 집합이 포함되는 것이 가장 적절합니다. 

 

3. GBAC (Group-Based Access Control) 활용 

Keycloak에서 realm 그룹을 관리할 수 있으며 사용자는 조직 내의 특정 부서에 포함될 수 있고, 관리 작업을 수행할 수 있는 권한을 가진 특정 사용자 그룹을 설정하는 것과 같이 애플리케이션에서 사용자의 역할에 따라 그룹화할 수 있습니다.

일반적으로 그룹과 역할은 상호 교환해서 사용할 수 있는데, 이러한 특성은 권한 모델을 정의할 때 약간의 혼란을 야기합니다. Keycloak은 그룹과 역할을 명확히 구분하며, 역할과 달리 그룹은 사용자를 구성하고 그룹과 관련된 역할에 따라 권한을 부여합니다. 

역할을 그룹에 할당할 수 있기 때문에 Keycloak을 사용하면 realm의 각 개별 사용자에 대한 역할을 부여 및 취소하지 않고도 다양한 사용자의 역할을 훨씬 쉽게 관리 할 수 있습니다. 

Keycloak의 그룹은 계층 구조이며, 토큰이 발행되면 그룹의 경로를 보고 계층 구조를 순회합니다. 예를 들어 인사팀 그룹이 있고, 해당 그룹의 하위 그룹을 매니저 그룹이 있을 수 있습니다. Keycloak이 그룹에 대한 정보를 토큰에 포함할 경우 해당 정보는 /human resource/manager형식으로 저장됩니다. 해당 정보는 객체(사용자)가 그룹의 멤버인 서버에서 발급된 모든 토큰에 적용됩니다.

역할과 달리 그룹 정보는 토큰에 자동으로 포함되지 않습니다. 이런 경우 특정 프로토콜 매퍼를 클라이언트와 연결해야합니다.

 

4. 그룹 멤버십을 토큰에 매핑하기

역할과는 달리 자동으로 그룹 정보를 토큰에 포함시키는 디폴트 프로토콜 매퍼가 존재하지 않습니다.해당 작업을 수행하기 위해 프로토콜 매퍼를 클라이언트에 생성해야 합니다.

 

명령프롬프트 창을 열어 keycloak을 실행합니다.[Keycloak 시작하기 4 https://marshmello.tistory.com/97 참조]

cd C:\keycloak-26.0.7\keycloak-26.0.7
bin\kc.bat start-dev

 

Clients 메뉴 > Create client 선택 후 myclient 클라이언트를 생성합니다.

 

Client ID를 myclient 로 입력 후 Next

Next 버튼 클릭

Save 버튼 클릭

Users 메뉴 > Create new user 버튼 클릭

 

username을 test01로 입력 후 사용자 생성

 

Clients 메뉴 > Client scopes 탭 > 생성한 clientid-dedicated 이름으로 된 client를 클릭

 

Add predefined mapper 버튼 클릭

groups 선택 후 Add 버튼 클릭

 

Groups 메뉴 > Create group 버튼 클릭

 

 

그룹명에 Project Management Office 입력 후 Create 버튼 클릭

 

Users 메뉴 > test01 버튼을 클릭하여 test01 사용자 상세보기

 

Users 메뉴 > Groups 탭 > Join Group 버튼 클릭 

 

Project Management Office 선택 후 Join 버튼 클릭

 

이제 test01은 Project Management Office 그룹의 멤버입니다.

 

5. OAuth2 범위 활용

기본적으로 Keycloak은 OAuth2 인가 서버입니다. OAuth2 자체에는 클라이언트와 리소스 서버의 두가지 주요 애플리케이션 유형이 있습니다. 클라이언트에게 접근 토큰을 발행하고 해당 토큰은 사용자 권한을 기반으로 하는 범위 집합을 제한하는 방식으로 사용자 역할을 수행할 수 있게 해줍니다. 또한 리소스 서버는 접근 토큰을 활용해 사용자가 부여한 범위에 따라 클라이언트가 리소스 서버의 보호된 리소스에 대한 접근 여부를 결정하기 위해 접근 토큰을 검증합니다.

이와 같이 OAuth2 범위를 사용한 권한 부여는 전적으로 사용자 동의를 기반으로 합니다. 

서드파티를 사용자의 API와 통합시키고자 할 때 가장 좋은 전력입니다. 따라서 서드파티 애플리케이션의 리소스에 접근 여부에 대한 결정을 사용자에게 위임 할 수 있습니다. 해당 전략에서 중요한 점은 리소스 서버에서 일반리소스가 아닌 사용자 정보를 보호하는 것입니다. OAuth2 범위를 사용하는 것과 지금까지 살펴본 여러 가지 인가 전략 사이에는 주로 시스템을 보호하는 엔티티 측면에서 근본적인 차이가 있습니다. 예를 들어 RBAC를 사용하는 경우 사용자로부터 시스템을 보호하는 반면, OAuth2 범위를 사용하면 클라이언트로부터 시스템을 보호할 수 있습니다. 

요약하면 클라이언트는 사용자를 대신해 일부 작업을 수행하거나 리솟에 접근할 수 있으며, 일반적인 위임 사용사례는 OAuth2를 사용합니다.

Keycloak이 주로 기업환경에서 사용되기 때문에 기본적으로 Keycloak의 클라이언트는 사용자 동의를 요청하지 않도록 설정돼 있습니다. 위임 활용 사례와 다른점은 클라이언트가 엔터프라이즈 경계 내에 있고 접근해야 하는 리소스가 사용자의 동의가 필요하지 않지만 시스템 관리자 부여한 접근 권한을 사용한다는 것입니다. 또한 클라이언트는 역할, 그룹 또는 사용자와 관련된 특정 속성에 따라 접근 범위가 정의되는 사용자를 인증하는 것에 더 초점을 둡니다.

 

6. ABAC (Attribute-Based Access Control) 활용

사용자 Keycloak을 통해 인증하는 경우 서버에서 발급한 토큰에는 인증 컨텍스트에 대한 중요한 정보가 포함됩니다.토큰에는 인증된 사용자 및 토큰이 발급된 클라이언트에 대한 정보와 인증 프로세스 수행 중에 수집할 수 있는 다양한 정보가 포함됩니다. 따라서 토큰이 제공하는 모든 정보를 사용해 애플리케이션에 대한 접근 권한을 인가하기 위해 사용할 수 있습니다. 해당 정보들은 토큰에 매핑된 클레임 (Claims)입니다.

ABAC은 인증 컨텍스트에 대한 정보뿐만 아니라 ID(토큰으로 표현됨)와 관련된 다양한 속성들을 사용해 리소스에 대한 접근 권한을 수행합니다. ABAC은 가장 유연한 접근 제어 메커니즘이며, 따라서 세분화된 인가를 지원합니다. 토큰 기반 인가와 함께 Keycloak을 사용하는 애플리케이션에서는 리소스를 보호하기 위해 손쉽게 ABAC를 활성화 할 수 있습니다.

토큰 기반 권한 인가는 토큰을 검사하고 해당 정보를 사용해 접근 권한 부여 여부를 결정합니다.해당 정보는 속성 또는 클레임 집합으로 표시되며 접근 권한을 활성화합니다.

애플리케이션에서 접근 권한을 적용하기 위해 역할을 사용하는 방법에대해 알아보겠습니다.

역할은 특정 클레임 집합을 사용해 토큰에 매핑됩니다. 역할을 사용해 접근 권한을 수행하려면 애플리케이션에서 이러한 클레임을 사용해 사용자에게 부여된 역할을 확인한 다음 특정 리소스에 접근 권한을 부여해야하는지 여부를 결정해야합니다. 역할을 사용해 접근 권한을 적용하려면 어떤 역할이 사용자에게 부여됐는지 확인하기 위해 애플리케이션은 해당 클레임만 확인하면 됩니다. 그리고 특정 리소스에 접근 허용 여부를 결정합니다.

해당 클레임은 애플리케이션이 모든 클레임을 사용해 접근 권한을 적용할 수 있는 토큰내의 다른 클레임과 동일합니다. 각 클라이언트에서 토큰에 저장되는 클레임 및 표명을 조정할 수 있습니다. 해당 작업을 수행하기 위해 Keycloak은 프로토콜 매퍼라는 기능을 제공합니다. Keycloak을 사용하면 원하는 정보를 토큰에 매핑해 애플리케이션 수준에서 접근 권한을 적용할 수 있습니다. ABAC은 다중접근제어 메커니즘을 지원할 만큼 충분히 유연하지만 구현 및 관리가 쉽지 않습니다.

 

7. 통합 Keycloak 인가 서버 활용

지금까지 특정 접근 제어 메커니즘에 의존하는 인증 전략을 살펴봤습니다. ABAC을 제외하고 해당 전략은 사용자에 대한 특정 데이터 집합에 의존해 애플리케이션에 접근 권한을 적용합니다. 또한 해당 전략은 애플리케이션과 긴밀하게 연동돼 보안 요구 사항을 변경하면 애플리케이션 코드를 변경해야합니다.

if(User.hasRole("pm") ){
	//pm 권한이 있는 사람에 대한 소스코드
}

 

위 코드에서 pm권한이 부여된 사용자만 보호된 리소스에 접근할 수 있는 RBAC을 사용해 간단한 검증을 수행합니다. 요구 사항이 변경돼 동일한 리소스에 대한 접근 권한을 특정 사용자에게도 부여해야 한다면 어떻게 될까? 또한 다른 역할이 부여된 사용자에게 해당 리소스에 대한 접근 권한을 부여할 수 있을까? 또는 ABAC을 활용해 리소스에 접근하는 컨텍스트에 대한 다양한 정보를 확인 할 수 있는가?

최소한 코드를 변경하고 애플리케이션을 다시 배포해야 하며, 변경 사항이 프로덕션에 사용할 준비가 됐는지 확인하기 위해 지속적인 통합 및 전달 프로세스를 수행해야합니다. 통합 인가는 외부 인가 서비스를 사용해 애플리케이션의 접근 관리 및 의사 결정을 외부화합니다. 해당 서비스는 애플리케이션을 접근 제어 메커니즘과 연동하지 않고도 다중 제어 메커니즘을 사용할 수 잇도록 해주며 애플리케이션의 다양한 보호 리소스를 참조하기 위해 사용되는 동일한 시맨틱을 사용해 접근 권한을 활성화합니다

if(User.canAccess("PM Resource")){
....
}

 

위 소스는 동일한 접근 검사를 제공하는 코드입니다. 이 코드는 특정 접근 제어 메커니즘에 대한 참조는 존재하지 않습니다. 접근제어는 사용자가 보호를 수행하는 리소스로 구성됩니다. 그리고 애플리케이션은 외부 인가 서비스에서 부여한 권한만 고려합니다. PM Resource에 접근할 수 있는 방법을 변경하면 애플리케이션 코드에 영향을 미치지 않지만 인가 서비스를 통해 해당 리소스에 대한 접근을 제어하는 정책은 변경해야합니다.

Keycloak은 Authorization Service 기능을 통해 통합 인가 서비스의 역할을 수행할 수 있습니다. 해당 기능은 다양한 접근 제어 메커니즘을 포함하는 정책 집합으로 구성됩니다. 접근 제어 메커니즘은 보호 리소스와 연동됩니다. 모든 작업은 Keycloak 관리 콘솔과 REST API를 통해 관리됩니다.

Keycloak 인가 서비스 기능은 애플리케이션에서 세분화된 인가를 수행하기 위해 ABAC를 활용합니다. 기본적으로 리소스를 보호할때 다양한 인가 전략을 쉽게 지원하기 위해 해당 정책을 통합할 수 있는 가능성과 함께 다양한 접근 제어 메커니즘을 나타내는 해당 정책 집합이 즉시 제공됩니다. 또한 Keycloak 인가 서비스 기능은 특정 작업 및 보호하는 리소스와 관련된 속성에 대한 접근 권한을 제어합니다.

통합 인가 서버의 일반적인 이슈는 접근 결정을 수행하기 위한 추가적인 통신이 필요하다는 것입니다. 토큰 기반 인가를 사용하면 Keycloak 인가 서비스 기능은 서버에서 부여한 모든 권한을 가진 토큰을 발급해 해당 이슈를 해결할 수 있습니다. 따라서 해당 토큰을 사용하는 애플리케이션은 토큰을 내부적으로 검증하는 것 외에는 추가적인 네트워크 요청을 수행할 필요가 없습니다. 또한 필요한 경우 신규 권한을 획득할 수 있는 제한된 권한 집합이 토큰에 발급되는 증분 인가도 지원합니다.

 

이번글에서는 통합 인가 및 Keycloak 인가 서비스가 통합 인가 서버의 역할을 수행하는 것을 살펴보았습니다. 또한 토큰 기반 인가를 활용하면 애플리케이션에 세분화된 Keycloak 인가 서비스를 사용할 수 있다는 점을 작성하였습니다.

 

다음글에서는 Keycloak 설정 및 관리 방법을 작성하겠습니다.

 

감사합니다.