質問

Keycloakのauthorizaionシステムを使って、かなり単純なロールベースのアクセス制御システムを作りたいと思っています。Keycloak が置き換えているシステムでは、1つ以上のグループのメンバーであるユーザーを作成することができます。このレガシー システムでは、ユーザーは、グループ メンバーシップ (グループに権限が割り当てられる) またはユーザーへの権限の直接付与によって、約 250 の各機能にアクセスするための "permission" を与えられます。

レガシーシステムを keycloak の権限にマッピングしたいのですが、可能でしょうか？

既存のシステムの各 "capability" を keycloak リソースおよび keycloak スコープのセットにマップすることは、私にとって簡単なはずです。たとえば、"viewAccount"ケイパビリティは、明らかに"account"リソースおよび"view"スコープに対応し、"viewTransaction"は"transaction"リソースに対応しますが、1つの"view"スコープのみを作成し、複数のリソース（アカウント、取引など）間でそれを使用することはベストな方法でしょうか。それとも、"viewAccount" スコープ、"viewTransaction" スコープなどを作成するべきですか？

同様に、パーミッションについても少し混乱しています。リソースとスコープの実用的な組み合わせごとに、権限を作成するのが通常のやり方なのでしょうか。与えられたリソースとスコープに一致する複数のパーミッションがある場合、Keycloak は何をするのでしょうか? Keycloakの意図は、リソースとスコープに対してパーミッションのマトリックスを構成できるようにすることだと思います。例えば、私は"accounts"へのアクセス権限と"view"のスコープの権限を持っているので、アカウントを見る権限を持っているでしょう？

私が尋ねるのは、このすべての結果として、私の古い "viewAccount" 能力が "View" スコープと "viewAccount" 許可で、結局 "Account" リソースを作成し、私を元の場所に戻すようであることだからです。これが正しいのであれば、それは良いことです。

最後に、明らかに、viewAccount が適用されるべきかどうかを決定する一連のポリシーが必要です。しかし、これは、ユーザーが所属する可能性のあるレガシー グループごとにポリシーが必要であることを意味するということであっていますか? たとえば、私が "helpdesk" ロールを持つ場合、私は "helpdesk membership" ポリシーを必要とし、それを "viewAccount" 権限に追加することができるのです。これは正しいですか?

ありがとうございます。

マーク

どのように解決するのですか？

私は2年以上遅れていますが、私が知っていることを共有し、できれば将来の読者の苦痛を軽減したいと考えました。完全な透明性 - 私は決して Keycloak/OAuth/OIDC の専門家ではなく、私が知っていることは、ドキュメントや書籍、古き良き YouTube を読んだり、ツールで遊んだりしたことがほとんどです。

この投稿は2つの部分から構成されます。

1. あなたの質問に可能な限りお答えします。
2. このスレッドの核となる概念のいくつかをよりよく理解するために、別のアプリをデプロイする必要なく Keycloak でポリシー/スコープ/パーミッションで遊べる方法を皆さんにお見せします。このスレッドの核となるコンセプトのいくつかをよりよく理解するためです。私が使っている Keycloak 8.0.0 .

第一部

始める前にいくつかの専門用語を。

• キークロークでは、2種類のパーミッションを作成することができます。 リソースベース と スコープベース .
• 簡単に言えば Resource-Based パーミッションの場合、それを直接リソースに適用します。
• については Scoped-Based の許可を得るには、それをスコープ (または範囲) に適用します。 と リソースに適用されます。

は、1 つの "view" スコープを作成し、それを複数のリソース (アカウント、トランザクションなど) で使用するのが最適な方法でしょうか。それとも、"viewAccount" スコープや "viewTransaction" スコープなどを作成するべきですか?

スコープは、保護されたリソースにおける一連の権利を表します。あなたの場合、2つのリソースがあります。 account そして transaction であるため、私は2番目のアプローチに傾きます。

長い目で見れば、グローバルな view スコープがすべてのリソースに関連付けられます (例. account , transaction , customer , settlement ...）によって、セキュリティ要件の変更に対応し、管理することが難しくなっています。

デザインの感覚をつかむためにチェックアウトできるいくつかの例を紹介します。

• Slack API
• Box API
• ストライプ

しかし、私は、リソース間でスコープを共有すべきではないと主張しているわけではありませんので、ご注意ください。実のところ Keycloak を持つリソースでは、同じ type . たとえば viewAccount と viewTransaction スコープを使用して、指定されたアカウントでトランザクションを読み取ることができます（結局、トランザクションを表示するためにアカウントへのアクセスが必要になる場合があります）。要件と標準は、設計に大きく影響します。

リソースとスコープの実用的な組み合わせのそれぞれについて、許可を作成するのが通常のやり方でしょうか。

申し訳ありませんが、質問を完全に理解しているわけではないので、少し大雑把に書きます。へのアクセスを許可/拒否するためには、以下のようにします。 resource へのアクセスを許可/拒否するには、次のようにする必要があります。

• あなたの ポリシー
• あなたの パーミッション
• ポリシーをパーミッションに適用する
• パーミッションの関連付けを scope または resource (またはその両方)

を使用すると、ポリシーの強制が有効になります。参照 認可プロセス .

これらの設定をどのように行うかは、あなた次第です。たとえば

• 個々のポリシーを定義し、各ポリシーを適切なパーミッションの下に結びつけます。

• より良い方法は、個々のポリシーを定義し、関連するすべてのポリシーを aggregated ポリシー (ポリシーのポリシー) の下にグループ化し、その集約されたポリシーに scope-based パーミッションに関連付けます。あなたは、その scoped-based をリソースとその関連する全てのスコープに適用させることができます。

• あるいは、2つの別々のタイプを活用することで、さらにパーミッションを分割することができます。リソースのためのみのパーミッションを resource-based パーミッション・タイプでリソースのためのパーミッションを作成し、スコープのためのパーミッションは scope-based パーミッション・タイプを通じてスコープにのみ関連付けます。

オプションがあります。

与えられたリソース／スコープにマッチするパーミッションが複数ある場合、Keycloakは何をするのですか？

これは

1. リソースサーバーの Decision Strategy
2. 各パーミッションの Decision Strategy
3. 各ポリシーの Logic の値を指定します。

は Logic の値は、Java の ! 演算子と似ています。これは Positive または Negative . の場合は Logic は Positive の場合、ポリシーの最終評価は変更されません。その Negative の場合、最終結果は否定されます (例えば、ポリシーが false と評価され、かつ Logic は Negative であれば、それは true ). 物事を単純にするために、仮に Logic は常に Positive .

は Decision Strategy は、私たちが本当に取り組みたいことです。その Decision Strategy はどちらかというと Unanimous または Affirmative . docsから。

決定戦略

この構成は、ポリシー評価エンジンが、評価されたすべての許可からの結果に基づいて、リソースまたはスコープが許可されるべきかどうかを決定する方法を変更します。 肯定的 は、リソースとそのスコープへのアクセスを許可するために、 少なくとも一つのパーミッションが肯定的な決定をするために評価されなければならないことを意味します。 全会一致 は、最終的な決定が肯定的であるために、すべてのパーミッションが肯定的な決定と評価されなければならないことを意味します。例として、同じリソースまたはスコープに対する 2 つのパーミッションが競合している場合（一方がアクセスを許可し、他方がアクセスを拒否している）、選択された戦略が Affirmative であれば、リソースまたはスコープへのパーミッションは許可されるでしょう。そうでない場合は、いずれかのパーミッションから1回だけ拒否すると、リソースまたはスコープへのアクセスも拒否されます。

上記のことをよりよく理解するために、例を使って説明しましょう。2 つのパーミッションを持つリソースがあり、誰かがそのリソースにアクセスしようとしているとします（覚えておいてください。 Logic は Positive である)。では

1. Permission One には Decision Strategy に設定されています。 Affirmative . また、3つのポリシーがあり、それぞれを評価すると
   • true
   • false
   • false

ポリシーの1つが true , Permission One が設定され true (肯定的 - 1つだけ必要なのは true ).

1. Permission Two には Decision Strategy に設定されています。 Unanimous を2つのポリシーで設定します。
   • true
   • false

この場合 Permission Two は false というのは、1つのポリシーが誤っているからです（Unanimous - they all need to be true ).

1. では、次に 最終 の評価です。もしリソースサーバーの Decision Strategy が設定されている場合は Affirmative に設定されているため、そのリソースへのアクセスは許可されます。 Permission One は true . 一方、リソースサーバーの Decision Strategy に設定されているのは Unanimous に設定されている場合、アクセスは拒否されます。

参照してください。

• リソースサーバーの設定
• パーミッションの管理

引き続き、再確認しておきます。私は、リソースサーバの Decision Strategy を設定する方法については、パート II で説明します。

例えば、quot;accounts;へのアクセス権限と、quot;view;のスコープに対する権限を持つことができるので、accountsを表示する権限を持つことができるのですね？

短い答えは「はい」です。では、もう少し詳しく説明します :)

次のようなシナリオがあるとします。

1. リソースサーバーの Decision Strategy に設定されている Unanimous または Affirmative
2. へのアクセス許可 account/{id} リソースは true
3. にアクセスするためのパーミッションです。 view スコープは true

アカウントを閲覧するためのアクセス権が付与されます。

• true + true は true の下に Affirmative または Unanimous Decision Strategy .

ここで、もしあなたがこの

1. リソース・サーバーの Decision Strategy に設定されている Affirmative
2. へのアクセス許可 account/{id} リソースは true
3. にアクセスするためのパーミッションです。 view スコープは false

あなたは また アカウントを閲覧するためのアクセス権が付与されます。

• true + false は true の下にある Affirmative 戦略の下で

ここでのポイントは、与えられたリソースへのアクセスも設定に依存するということです。したがって、2番目のシナリオを望まないかもしれないので注意してください。

しかし、これは、ユーザーが所属する可能性のあるレガシーグループごとにポリシーが必要だということであっていますか?

2年前のKeycloakがどのような挙動をしていたかは分かりませんが、指定できるのは グループベースのポリシー を指定し、そのポリシーの下にすべてのグループを単純に追加することができます。確かに、グループごとに 1 つのポリシーを作成する必要はありません。

たとえば、私が "helpdesk" ロールを持っている場合、私は "helpdesk membership" ポリシーを必要とし、それを "viewAccount" 権限に追加することができます。これは正しいですか?

ほとんどそうです。この設定には多くの方法があります。たとえば、次のようなことができます。

1. リソースを作成する (例: /account/{id} ) を作成し、それを account:view スコープに関連付けます。
2. を作成します。 ロールベースのポリシー を追加し helpdesk ロールを追加します。
3. を作成します。 Scope-Based というパーミッションを作成します。 viewAccount と結び、それを scope , resource と policy

第二部でも似たようなことを設定します。

パートII

Keycloakには、すべてのポリシーをテストすることができる、すてきな小さなツールがあります。さらに良いことに、これを動作させるために、別のアプリケーション サーバーを立ち上げ、別のアプリをデプロイする必要はありません。

以下は、私たちが設定するシナリオです。

1. という新しいレルムを作成します。 stackoverflow-demo
2. を作成します。 bank-api クライアントをそのレルムの下に作成します
3. というリソースを定義します。 /account/{id} というリソースを定義します。
4. は account/{id} には account:view のスコープを持ちます。
5. というユーザーを作成します。 bob というユーザを新しいレルムの下に作成します。
6. また、3つのロールを作成します。 bank_teller , account_owner と user
   • を関連付けることはしません。 bob をどのロールにも関連付けません。これは今すぐには必要ありません。
7. 以下の2つを設定します。 Role-Based ポリシーを設定します。
   • bank_teller そして account_owner へのアクセスは /account/{id} リソース
   • account_owner には、アクセスすることができます。 account:view スコープ
   • user リソースまたはスコープへのアクセス権を持っていない
8. を弄ることにします。 Evaluate ツールを使って、どのようにアクセスを許可または拒否できるかを見てみましょう。 を確認します。

この例は非現実的ですが、私は銀行業に詳しくないのでお許しください :)

キーロックのセットアップ

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
を入力します。 bank-api
3. については Client ID を入力します。 Root URL
4. をクリックします。 http://127.0.0.1:8080/bank-api
5. 確認する Save は Client Protocol
6. を変更します。 openid-connect を Access Type
7. 変更 confidential を Authorization Enabled
8. 下にスクロールして On . 新しい Save タブが上部に表示されるはずです。
9. をクリックします。 Authorization タブをクリックし、次に Authorization
10. が表示されていることを確認します。 Settings が設定されていることを確認します。 Decision Strategy
    • これはリソースサーバーの Unanimous

ご覧ください。

• クライアントアプリケーションを作成する
• 認証サービスの有効化

カスタムスコープを作成する

1. をクリックします。 Decision Strategy タブ
2. をクリックします。 Authorization > Authorization Scopes を持ち出す Create ページ
3. 入る Add Scope を名前に入力し、Enterキーを押します。

ビューアカウントリソース」を作成します。

1. クリックすると account:view 上のリンクをクリック
2. をクリックします。 Authorization
の両方に対して Resources と Create
3. 入る View Account Resource を入力します。 Name
4. 入力する Display name の中に account/{id} テキストボックス
5. クリック URI

参照 リソースの作成

ポリシーの作成

1. 再び account:view タブをクリックします。 Scopes
2. 選択する Save を選択します。 Authorization ドロップダウン
3. の中で Policies セクションで Role
4. 下 Create Policy の両方を選択します。 Name と Only Bank Teller and Account Owner Policy 役割
5. 確認すること Realm Roles が設定されていることを確認する。 bank_teller
6. クリック account_owner
7. をクリックします。 Logic リンク
8. 選択 Positive から再び Save のドロップダウンを使用します。
9. 今回使用する Policies には Role
10. の下に Create Policy セレクト Only Account Owner Policy
11. 確認する Name が設定されていることを確認する。 Realm Roles
12. クリック account_owner
13. をクリックします。 Logic のリンクをクリックすると、新しく作成されたポリシーが表示されます。

参照 ロールベースポリシー

Keycloakにはもっと強力なポリシーがあることに注意してください。以下を参照してください。 ポリシーの管理

リソースベースのパーミッションの作成

1. 再び Positive タブをクリックします。 Save
2. 選択する Policies
3. タイプ Authorization は Permissions
4. の下に Resource-Based タイプ View Account Resource Permission
5. 下 Name セレクト Resources
6. を確実に View Account Resource Permission が設定されていることを確認します。 Apply Policy
7. クリック Only Bank Teller and Account Owner Policy

参照 リソースベースのパーミッションの作成

ふぅ...

リソースベースの許可を評価する

1. の下で再び Decision Strategy タブで Unanimous
2. 下の Save 入る Authorization
3. アンダー Evaluate セレクト User
   • ここで、作成したロールとユーザーを関連付けます。
4. 以下 bob セレクト Roles をクリックし user
5. 評価する］をクリックします。
6. を展開します。 Resources を展開すると、結果が表示されます。 View Account Resource .

1. これは理にかなっています。 Add . これが正しいことを確認するために、テストしてみましょう!
2. をクリックします。 View Account Resource with scopes [account:view] のリンクをクリックすると、評価結果の右上に
3. bobのロールを DENY をクリックし Only Bank Teller and Account Owner Policy . すると、次のような結果が得られるはずです。 Back . 同じように、ロールを account_owner

参照 ポリシーの評価とテスト

スコープベースのパーミッションの作成

1. に戻って Evaluate セクション
2. セレクト PERMIT の下にある bank_teller のドロップダウンの下にあります。
3. アンダー Permissions を入力します。 Scope-Based
4. アンダー Create Permission を入力します。 Name
5. アンダー View Account Scope Permission を入力します。 Scopes
6. を確認します。 account:view が設定されていることを確認します。 Apply Policy
7. クリック Only Account Owner Policy

参照 スコープベースのパーミッションの作成

2回目のテスト実行

新しい変更の評価

1. に戻り Decision Strategy セクション
2. をクリックします。 Unanimous
3. ユーザは Save
4. ロールは Authorization
5. リソースは Evaluate で、クリック bob
6. をクリックします。 bank_teller をクリックすると View Account Resource .
   • これもまた驚くことではありませんが Add へのアクセスは Evaluate にはアクセスできますが DENY . ここで、一方の許可は真と評価され、もう一方は偽と評価されます。リソースサーバーの bank_teller に設定されている resource であれば、最終的な判断は scope .
7. をクリックします。 Decision Strategy の下にある Unanimous タブをクリックし DENY を Settings に変更し、もう一度手順1〜6に戻ります。今回は、最終的に Authorization (となります（1つの許可が真なので、最終的な判断は真です）。
8. 完全を期すために、リソースサーバーの Decision Strategy に戻します。 Affirmative . もう一度、1 から 6 の手順に戻りますが、今回はロールを PERMIT . 今度は、最終的な結果は、再び Decision Strategy であることを考えると、これは理にかなっています。 Unanimous の両方にアクセスすることができます。 account_owner と PERMIT .

すっきりしている :) これが役立つといいのですが。