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

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

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

파트 I

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

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

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

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

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

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

• Slack API
• Box API
• 줄무늬

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

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

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

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

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

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

• 개별 정책을 정의하고 각 정책을 적절한 권한에 연결합니다.

• 더 좋은 방법은 개별 정책을 정의한 다음 aggregated정책 ( 정책 정책) 아래 모든 관련 정책을 그룹화 한 다음 집계 된 정책을 scope-based권한 과 연결하는 것 입니다. 해당 scoped-based권한을 리소스 및 모든 관련 범위에 적용 할 수 있습니다 .

• 또는 두 가지 개별 유형을 활용하여 권한을 추가로 분리 할 수 ​​있습니다. resource-based권한 유형을 통해 리소스에 대한 권한 만 생성하고 권한 유형을 통해 범위와 다른 권한을 별도로 연결할 수 scope-based있습니다.

옵션이 있습니다.

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

이것은에 달려 있습니다

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

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

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

의사 결정 전략

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

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

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

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

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

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

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

보다:

• 리소스 서버 설정
• 권한 관리

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

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

짧은 대답은 ‘예’입니다. 자, 이것에 대해 조금 확장 해 봅시다 🙂

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

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

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

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

이제이게 있으면

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

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

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

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

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

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

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

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

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

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

파트 II

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

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

1. 우리는라는 새 영역을 만들 것입니다. stackoverflow-demo
2. 우리는 bank-api그 영역 에서 클라이언트를 만들 것 입니다.
3. /account/{id}해당 클라이언트에 대해 호출되는 리소스를 정의합니다.
4. 는 account/{id}해야합니다 account:view범위를
5. bob새로운 영역 아래에 라는 사용자를 생성합니다.
6. 또한 세 가지 역할 bank_teller,, account_owner및user
   • 우리는 bob어떤 역할과도 연관되지 않을 것 입니다. 지금은 필요하지 않습니다.
7. 다음 두 가지 Role-Based정책을 설정합니다 .
   • bank_teller및 account_owner에 액세스 할 수있는 /account/{id}리소스를
   • account_owneraccount:view범위에 액세스 할 수 있습니다.
   • user 리소스 또는 범위에 대한 액세스 권한이 없습니다.
8. 이 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

초기 관리자 생성

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

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

무대 설정

새 영역 만들기

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

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

새 사용자 만들기

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

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

새 역할 만들기

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

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

역할 보기

클라이언트 생성

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

보다:

• 클라이언트 응용 프로그램 만들기
• 권한 부여 서비스 활성화

사용자 지정 범위 만들기

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

“계정 리소스보기”만들기

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

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

정책 만들기

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

참조 역할 기반 정책

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

리소스 기반 권한 생성

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

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

휴 …

리소스 기반 권한 평가

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

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

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

범위 기반 권한 생성

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

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

두 번째 테스트 실행

새로운 변경 사항 평가

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

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