keycloak의 리소스, 범위, 권한 및 정책

Question 1

Keycloak의 권한 부여 시스템을 사용하여 매우 간단한 역할 기반 액세스 제어 시스템을 만들고 싶습니다. 시스템 Keycloak을 교체하면 하나 이상의 "그룹"의 구성원 인 "사용자"를 만들 수 있습니다. 이 레거시 시스템에서 사용자는 그룹 멤버십 (그룹에 권한이 할당 됨) 또는 사용자에게 직접 권한 부여를 통해 약 250 개의 "기능"에 각각 액세스 할 수있는 "권한"이 부여됩니다.

레거시 시스템을 keycloak 인증에 매핑하고 싶습니다.

기존 시스템의 각 "기능"을 keycloak 리소스와 keycloak 범위 세트에 매핑하는 것은 간단해야합니다. 예를 들어 "viewAccount"기능은 분명히 "계정"리소스와 "보기"범위에 매핑됩니다. 그리고 "viewTransaction"은 "트랜잭션"리소스에 매핑됩니다.하지만 하나의 "뷰"범위 만 만들고 여러 리소스 (계정, 트랜잭션 등)에서 사용하는 것이 가장 좋은 방법입니까? 아니면 "viewAccount"범위, "viewTransaction"범위 등을 만들어야합니까?

마찬가지로 권한에 대해 약간 혼란 스럽습니다. 리소스와 범위의 실제 조합에 대해 권한을 만드는 것이 일반적입니까? 주어진 리소스 / 범위와 일치하는 여러 권한이있는 경우 Keycloak은 무엇을합니까? Keycloak의 의도는 리소스 및 범위에 대한 권한 매트릭스를 구성 할 수 있도록하는 것입니다. 예를 들어 "계정"에 액세스 할 수있는 권한과 "보기"범위에 대한 권한을 가질 수 있으므로 권한을 갖게됩니다. 계정을 보려면?

이 모든 결과가 내 이전 "viewAccount"기능이 "View"범위와 "viewAccount"권한을 가진 "Account"리소스를 생성하는 것으로 보이므로 내가 원래 있던 곳으로 돌아 가게하는 것 같습니다. 맞다면 괜찮습니다.

마지막으로 viewAccount 적용 여부를 결정하는 정책 세트가 필요합니다. 그러나 이것이 사용자가 속할 수있는 각 레거시 그룹에 대한 정책이 필요하다는 것을 의미합니까? 예를 들어 "헬프 데스크"역할이있는 경우 "헬프 데스크 멤버십"정책이 필요합니다. 그러면 "viewAccount"권한에 추가 할 수 있습니다. 이 올바른지?

감사,

표

Question 2

나는 내가 2 년 이상 늦었다는 것을 알고 있지만 내가 아는 것을 공유하고 미래의 독자들에게 고통을 덜어 줄 것이라고 생각합니다. 완전한 투명성-나는 결코 Keycloak / OAuth / OIDC 전문가가 아니며 내가 아는 것은 대부분 문서, 책, 좋은 유튜브를 읽고 도구를 가지고 노는 것입니다.

이 게시물은 다음 두 부분으로 구성됩니다.

모든 질문에 최선을 다해 답변하겠습니다.
이 스레드의 핵심 개념 중 일부를 더 잘 이해하기 위해 별도의 앱을 배포 할 필요없이 Keycloak에서 정책 / 범위 / 권한을 가지고 놀 수있는 모든 방법을 보여 드리겠습니다. 이것은 대부분 모든 것을 시작하기위한 것입니다. 나는 Keycloak 8.0.0.

파트 I

시작하기 전에 몇 가지 용어 :

Keycloak에서는 리소스 기반 및 범위 기반 의 두 가지 유형의 권한을 생성 할 수 있습니다 .
간단히 말해 Resource-Based권한의 경우 리소스에 직접 적용합니다.
Scoped-Based권한을 얻으 려면 범위 또는 범위 및 리소스에 적용합니다.

하나의 "보기"범위를 만들고 여러 리소스 (계정, 트랜잭션 등)에서 사용하는 것이 모범 사례입니까? 아니면 "viewAccount"범위, "viewTransaction"범위 등을 만들어야합니까?

범위는 보호 된 리소스의 권한 집합을 나타냅니다. 귀하의 경우에는 두 가지 리소스가 있습니다. account및 transaction, 따라서 두 번째 접근 방식을 사용합니다.

장기적으로 글로벌 가지고 view(모든 자원과 관련된 범위를 예를 들면 account, transaction, customer,settlement 모두 관리 및 보안 요구 사항의 변화에 적응에 ...) 인증을 어렵게 만든다.

다음은 디자인에 대한 느낌을 얻기 위해 확인할 수있는 몇 가지 예입니다.

하지만 참고하십시오-리소스간에 범위를 공유해서는 안된다고 주장하는 것이 아닙니다. 사실, Keycloak동일한 type. 당신은 인스턴스 필요 위해 할 수 모두 viewAccount와viewTransaction 주어진 계정에서 트랜잭션을 읽으려면 범위 있습니다 (결국 트랜잭션을보기 위해 계정에 액세스해야 할 수도 있음). 요구 사항과 표준은 설계에 큰 영향을 미칩니다.

리소스와 범위의 실제 조합 각각에 대해 권한을 만드는 것이 일반적입니까?

죄송합니다. 질문을 완전히 이해하지 못해서 좀 더 자세히 말씀 드리겠습니다. 에 대한 액세스 권한을 부여 / 거부하려면 resource다음을 수행해야합니다.

정책 정의
권한 정의
권한에 정책 적용
하나 scope또는 resource(또는 둘 다)에 권한 연결

정책 시행이 적용됩니다. 승인 프로세스를 참조하십시오 .

이 모든 것을 설정하는 방법은 전적으로 귀하에게 달려 있습니다. 예를 들어 다음과 같이 할 수 있습니다.

개별 정책을 정의하고 각 정책을 적절한 권한에 연결합니다.
더 좋은 방법은 개별 정책을 정의한 다음 aggregated정책 ( 정책 정책) 아래 모든 관련 정책을 그룹화 한 다음 집계 된 정책을 scope-based권한 과 연결하는 것 입니다. 해당 scoped-based권한을 리소스 및 모든 관련 범위에 적용 할 수 있습니다 .
또는 두 가지 개별 유형을 활용하여 권한을 추가로 분리 할 수 있습니다. resource-based권한 유형을 통해 리소스에 대한 권한 만 생성하고 권한 유형을 통해 범위와 다른 권한을 별도로 연결할 수 scope-based있습니다.

옵션이 있습니다.

주어진 리소스 / 범위와 일치하는 여러 권한이있는 경우 Keycloak은 무엇을합니까?

이것은에 달려 있습니다

리소스 서버의 Decision Strategy
각 권한의 Decision Strategy
각 정책의 Logic가치.

Logic값은 자바와 비슷합니다 !연산자. Positive또는 일 수 있습니다 Negative. (가) 때 Logic입니다 Positive, 정책의 최종 평가는 변경되지 않습니다. 그 때 Negative, 최종 결과는 무효가됩니다 (예를 들어, 거짓과에 대한 정책 평가되면 LogicIS는 Negative, 다음이 될 것입니다 true). 간단하게하기 위해Logic 항상 다음으로 설정되어Positive .

는 Decision Strategy우리가 정말 해결하려는 것입니다. 은 또는 Decision Strategy일 수 있습니다 . 문서에서UnanimousAffirmative

의사 결정 전략

이 구성은 정책 평가 엔진이 평가 된 모든 권한의 결과를 기반으로 리소스 또는 범위를 부여할지 여부를 결정하는 방법을 변경합니다. 긍정 은 리소스 및 해당 범위에 대한 액세스 권한을 부여하기 위해 적어도 하나의 권한이 긍정적 인 결정으로 평가되어야 함을 의미합니다. 만장일치 란 최종 결정도 긍정적이려면 모든 권한이 긍정적 인 결정으로 평가되어야 함을 의미합니다. 예를 들어 동일한 리소스 또는 범위에 대한 두 개의 권한이 충돌하는 경우 (둘 중 하나는 액세스 권한을 부여하고 다른 하나는 액세스를 거부하는 경우) 선택한 전략이 긍정이면 리소스 또는 범위에 대한 권한이 부여됩니다. 그렇지 않으면 모든 권한에 대한 단일 거부는 리소스 또는 범위에 대한 액세스도 거부합니다.

위의 내용을 더 잘 이해하기 위해 예제를 사용하겠습니다. 당신은이 권한이있는 자원을 가지고 사람이 자원 (즉, 기억하는 것이 액세스를 시도하는 가정 Logic입니다 Positive모든 정책에 대한). 지금:

Permission One로 Decision Strategy설정되어 Affirmative있습니다. 또한 각각 다음을 평가하는 세 가지 정책이 있습니다.
- true
- false
- false

정책 중 하나가 설정되어 있기 때문에 true, Permission One로 설정 true(- 될 만 한 요구에 적극적 true).

Permission Two2 개의 정책 이있는 Decision Strategy세트가 Unanimous있습니다.
- true
- false

이 경우 Permission Two입니다 false하나 개의 정책이 거짓이기 때문에 (만장일치 - 그들이 할 수있는 모든 필요 true).

이제 최종 평가 가 나옵니다 . 리소스 서버가 Decision Strategy로 설정되어 있으면이 리소스 Affirmative에 대한 액세스 권한이 부여 Permission One됩니다 true. 반면에 리소스 서버가 Decision Strategy로 설정되어 있으면 Unanimous액세스가 거부됩니다.

보다:

우리는 이것을 계속 재검토 할 것입니다. Decision Strategy Part II에서 리소스 서버를 설정하는 방법을 설명합니다 .

예를 들어 "계정"에 액세스 할 수있는 권한과 "보기"범위에 대한 권한을 가질 수 있으므로 계정을 볼 수있는 권한이 있습니까?

짧은 대답은 '예'입니다. 자, 이것에 대해 조금 확장 해 봅시다 :)

다음 시나리오가있는 경우 :

리소스 서버 Decision Strategy가 Unanimous또는로 설정되었습니다.Affirmative
account/{id}리소스 에 액세스 할 수있는 권한 은true
view범위 에 액세스 할 수있는 권한 은true

계정을 볼 수있는 액세스 권한이 부여됩니다.

true+ true는 또는 true이하와 같습니다 . AffirmativeUnanimous Decision Strategy

이제이게 있으면

리소스 서버 Decision Strategy가Affirmative
account/{id}리소스 에 액세스 할 수있는 권한 은true
view범위 에 액세스 할 수있는 권한 은false

당신은 것 또한 계정을 볼 수있는 액세스 권한을 부여합니다.

true+ false는 전략 true아래에 Affirmative있습니다.

여기서 요점은 주어진 리소스에 대한 액세스도 설정에 따라 다르므로 두 번째 시나리오를 원하지 않을 수 있으므로주의해야합니다.

그러나 이것이 사용자가 속할 수있는 각 레거시 그룹에 대한 정책이 필요하다는 것을 의미합니까?

Keycloak이 2 년 전에 어떻게 작동했는지 잘 모르겠지만 그룹 기반 정책을 지정하고 해당 정책 아래에 모든 그룹을 추가하기 만하면됩니다. 그룹당 하나의 정책을 만들 필요는 없습니다.

예를 들어 "헬프 데스크"역할이있는 경우 "헬프 데스크 멤버십"정책이 필요합니다. 그러면 "viewAccount"권한에 추가 할 수 있습니다. 이 올바른지?

꽤 많이. 이를 설정하는 방법에는 여러 가지가 있습니다. 예를 들어 다음을 수행 할 수 있습니다.

리소스 (예 :) /account/{id}를 만들고 account:view범위 와 연결합니다 .
크리에이트 역할 기반 정책 과 추가 helpdesk해당 정책에 따라 역할을
크리에이트 Scope-Based라는 권한 viewAccount과 함께 넥타이 scope, resource그리고policy

Part II에서 비슷한 것을 설정하겠습니다.

파트 II

Keycloak에는 모든 정책을 테스트 할 수있는 깔끔한 도구가 있습니다. 더 좋은 점은 실제로 다른 애플리케이션 서버를 가동하고이를 위해 별도의 앱을 배포 할 필요가 없다는 것입니다.

설정할 시나리오는 다음과 같습니다.

우리는라는 새 영역을 만들 것입니다. stackoverflow-demo
우리는 bank-api그 영역 에서 클라이언트를 만들 것 입니다.
/account/{id}해당 클라이언트에 대해 호출되는 리소스를 정의합니다.
는 account/{id}해야합니다 account:view범위를
bob새로운 영역 아래에 라는 사용자를 생성합니다.
또한 세 가지 역할 bank_teller,, account_owner및user
- 우리는 bob어떤 역할과도 연관되지 않을 것 입니다. 지금은 필요하지 않습니다.
다음 두 가지 Role-Based정책을 설정합니다 .
- bank_teller및 account_owner에 액세스 할 수있는 /account/{id}리소스를
- account_owneraccount:view범위에 액세스 할 수 있습니다.
- user 리소스 또는 범위에 대한 액세스 권한이 없습니다.
이 Evaluate도구를 사용하여 액세스 권한을 부여하거나 거부하는 방법을 살펴 보겠습니다.

저를 용서하십시오.이 예는 비현실적이지만 은행 부문에 익숙하지 않습니다. :)

Keycloak 설정

Keycloak 다운로드 및 실행

cd tmp
wget https://downloads.jboss.org/keycloak/8.0.0/keycloak-8.0.0.zip 
unzip keycloak-8.0.0.zip
cd keycloak-8.0.0/bin
./standalone.sh

초기 관리자 생성

이동 http://localhost:8080/auth
Administration Console링크를 클릭하십시오
관리자 생성 및 로그인

방문 시작하기 자세한 내용은. 우리의 목적을 위해 위의 내용으로 충분합니다.

무대 설정

새 영역 만들기

master영역 주위를 마우스로 가리키고 Add Realm버튼을 클릭 합니다.
stackoverflow-demo이름으로 입력하십시오 .
를 클릭하십시오 Create.
이제 왼쪽 상단 stackoverflow-demo에 master영역 대신 표시 되어야합니다 .

새 영역 만들기를 참조하십시오.

새 사용자 만들기

Users왼쪽 의 링크를 클릭하십시오
Add User버튼을 클릭하십시오
입력 username(예를 bob)
User Enabled켜져 있는지 확인
딸깍 하는 소리 Save

새 사용자 만들기를 참조하십시오.

새 역할 만들기

Roles링크를 클릭하십시오
클릭 Add Role
다음 역할을 추가합니다. bank_teller, account_owner및user

다시하지 마십시오 사용자를 역할과 연결 . 우리의 목적을 위해 이것은 필요하지 않습니다.

역할 보기

클라이언트 생성

클릭 Clients링크를
클릭 Create
입력 bank-api에 대한Client ID
에 대한 Root URL입력http://127.0.0.1:8080/bank-api
클릭 Save
그 확인 Client Protocol입니다openid-connect
변화 Access Type에를confidential
변경 Authorization Enabled에On
아래로 스크롤하여 Save. 새로운Authorization 탭이 상단에 나타납니다.
Authorization탭을 클릭 한 다음Settings
Decision Strategy로 설정되어 있는지 확인하십시오.Unanimous
- 이것은 리소스 서버의 Decision Strategy

보다:

사용자 지정 범위 만들기

Authorization탭을 클릭 하십시오
Authorization Scopes> Create를 클릭하여 Add Scope페이지 를 불러옵니다 .
account:view이름을 입력 하고 Enter 키를 누르십시오 .

"계정 리소스보기"만들기

Authorization위의 링크를 클릭하십시오
클릭 Resources
클릭 Create
및 View Account Resource모두 입력NameDisplay name
입력 account/{id}에 대한URI
입력 account:view에서 Scopes텍스트 상자
딸깍 하는 소리 Save

리소스 생성을 참조하십시오.

정책 만들기

다시 Authorization탭 아래 에서Policies
선택 Role하여에서Create Policy 드롭 다운
에서 Name섹션 유형Only Bank Teller and Account Owner Policy
아래 Realm Roles에서 bank_teller및 account_owner역할을 모두 선택하십시오.
Logic로 설정되어 있는지 확인하십시오.Positive
딸깍 하는 소리 Save
Policies링크를 클릭하십시오
드롭 다운 Role에서 다시 선택 하십시오 Create Policy.
이번에 Only Account Owner Policy는Name
아래에서 Realm Roles선택account_owner
Logic로 설정되어 있는지 확인하십시오.Positive
딸깍 하는 소리 Save
Policies상단 의 링크를 클릭 하면 새로 생성 된 정책을 볼 수 있습니다.

참조 역할 기반 정책

Keycloak에는 훨씬 더 강력한 정책이 있습니다. 정책 관리를 참조하십시오.

리소스 기반 권한 생성

다시 Authorization탭 아래 에서Permissions
고르다 Resource-Based
입력 View Account Resource Permission에 대한Name
아래 Resources유형View Account Resource Permission
아래에서 Apply Policy선택Only Bank Teller and Account Owner Policy
Decision Strategy로 설정되어 있는지 확인하십시오.Unanimous
딸깍 하는 소리 Save

리소스 기반 권한 만들기를 참조 하십시오.

휴 ...

리소스 기반 권한 평가

다시 Authorization탭 아래 에서Evaluate
아래는 User입력bob
아래에서 Roles선택user
- 여기에서 사용자를 생성 된 역할과 연결합니다.
아래에서 Resources선택 View Account Resource하고 클릭Add
평가를 클릭하십시오.
View Account Resource with scopes [account:view]결과를 보려면를 확장하면 DENY.

이는 두 역할 만 Only Bank Teller and Account Owner Policy. 이것이 사실인지 테스트 해 봅시다!
Back평가 결과 바로 위에 있는 링크를 클릭하십시오.
bob의 역할을로 변경하고을 account_owner클릭합니다 Evaluate. 이제 결과가 PERMIT. 돌아가서 역할을bank_teller

정책 평가 및 테스트를 참조하십시오.

범위 기반 권한 생성

Permissions섹션으로 돌아 가기
선택 Scope-Based세 이하이 시간 Create Permission드롭 다운을.
아래 Name에 다음을 입력합니다.View Account Scope Permission
아래 Scopes에 다음을 입력합니다.account:view
아래 Apply Policy에 다음을 입력합니다.Only Account Owner Policy
Decision Strategy로 설정되어 있는지 확인하십시오.Unanimous
딸깍 하는 소리 Save

범위 기반 권한 만들기를 참조하십시오.

두 번째 테스트 실행

새로운 변경 사항 평가

Authorization섹션으로 돌아 가기
클릭 Evaluate
사용자는 bob
역할은 bank_teller
리소스는 View Account Resource클릭 해야합니다.Add
를 클릭 Evaluate하면 DENY.
- 다시 말하지만에 bank_teller액세스 할 수 resource있지만 scope. 여기서 하나의 권한은 참으로 평가되고 다른 하나는 거짓으로 평가됩니다. 리소스 서버가 Decision Strategy로 설정되어 Unanimous있는 경우 최종 결정은 DENY입니다.
를 클릭 Settings언더 Authorization탭, 변경 Decision Strategy에 Affirmative및 단계로 돌아가 1-6 다시. 이번에는 최종 결과가되어야합니다 PERMIT(하나의 권한이 사실이므로 최종 결정이 사실입니다).
완전성을 위해 리소스 서버 Decision Strategy를 Unanimous. 다시 1 ~ 6 단계로 돌아가지만 이번에는 역할을로 설정합니다 account_owner. 이번에는 최종 결과가 다시 인 PERMIT(가) 주어진, 어떤 의미 account_owner모두에 액세스 할 수 있습니다 resource와 scope.

깔끔한 :) 이것이 도움이되기를 바랍니다.

Question 3

Lua에 어댑터가 없기 때문에 어댑터를 사용하지 않고 순수 HTTP 메서드를 통해 권한 부여를 시행하려고했습니다. 이 답변이 비 어댑터 기반 방법을 찾는 사람들에게 도움이되기를 바랍니다.

어댑터를 찾고 있다면 빠른 시작 가이드 가 시작 하기에 가장 좋은 곳입니다. 특히 스프링 부트 authz 예제 .

순수 HTTP 기반 구현의 경우 :

1 단계:

Keycloak Admin UI 에서 정책 및 권한 정의

2 단계

어떤 HTTP 경로가 어떤 리소스에 속하는지 내부 매핑과 각 경로에 필요한 범위가 있어야합니다. 이것은 구성 파일에 저장할 수도 있습니다 . 특정 경로가 호출되면 Keycloak 토큰 끝점을 호출하여 액세스 토큰의 클레임을 확인합니다.

{
  "policy-enforcer": {
    "user-managed-access" : {},
    "enforcement-mode" : "ENFORCING"
    "paths": [
      {
        "path" : "/someUri/*",
        "methods" : [
          {
            "method": "GET",
            "scopes" : ["urn:app.com:scopes:view"]
          },
          {
            "method": "POST",
            "scopes" : ["urn:app.com:scopes:create"]
          }
        ]
      }
    ]
  }
}

어댑터를 사용 중이고 경로 또는 리소스를 지정하지 않은 경우 어댑터는 내부적 으로 Keycloak에서 경로 및 리소스 를 검색 합니다.

3 단계 :

토큰 끝점을 사용하여 권한 을 얻거나 평가 합니다. response_mode매개 변수를 사용 하여 최종 결정 (액세스 제공 여부)을 얻거나 전체 권한을 검색 할 수 있습니다.

curl -X POST \
  http://${host}:${port}/auth/realms/${realm}/protocol/openid-connect/token \
  -H "Authorization: Bearer ${access_token}" \
  --data "grant_type=urn:ietf:params:oauth:grant-type:uma-ticket" \
  --data "permission=Resource A#Scope A"

인증 요청이 어떤 권한에도 매핑되지 않으면 403대신 HTTP 상태 코드가 반환됩니다.