密钥斗篷中的资源，范围，权限和策略 [英] Resources, scopes, permissions and policies in keycloak

查看：51
本文介绍了密钥斗篷中的资源，范围，权限和策略的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

我想使用Keycloak的授权系统创建一个非常简单的基于角色的访问控制系统. Keycloak正在替换的系统允许我们创建一个用户"，该用户是一个或多个组"的成员.在此旧版系统中，通过组成员身份(向组分配了权限)或直接向用户授予权限，授予用户访问权限"以访问约250个功能"中的每一个.

I want to create a fairly simple role-based access control system using Keycloak's authorizaion system. The system Keycloak is replacing allows us to create a "user", who is a member of one or more "groups". In this legacy system, a user is given "permission" to access each of about 250 "capabilities" either through group membership (where groups are assigned permissions) or a direct grant of a permission to the user.

我想将旧系统映射到密钥斗篷授权.

I would like to map the legacy system to keycloak authorizations.

对我来说，将现有系统中的每个功能"映射到一个密钥库资源和一组密钥库作用域应该很简单.例如，"viewAccount"功能显然会映射到"account"资源和"view"范围；和"viewTransaction"映射到事务"资源...但是，最佳实践是仅创建一个视图"作用域，并在多种资源(帐户，交易等)中使用它吗?还是应该创建"viewAccount"范围，"viewTransaction"范围等?

It should be simple for me to map each "capability" in the existing system to a keycloak resource and a set of keycloak scopes. For example, a "viewAccount" capability would obviously map to an "account" resource and a "view" scope; and "viewTransaction" maps to a "transaction" resource... but is it best practice to create just one "view" scope, and use it across multiple resources (account, transaction, etc)? Or should I create a "viewAccount" scope, a "viewTransaction" scope, etc?

类似地，我对权限有些困惑.对于资源和范围的每种实用组合，是否通常创建许可?如果有多个权限匹配给定的资源/范围，Keycloak会做什么?我猜想Keycloak的目的是允许我针对资源和范围配置权限矩阵，例如，我可以具有访问帐户"的权限和具有查看"范围的权限，因此我将拥有权限查看帐户?

Similarly, I'm a little confused about permissions. For each practical combination of resource and scope, is it usual practice to create a permission? If there are multiple permissions matching a given resource/scope, what does Keycloak do? I'm guessing that the intention of Keycloak is to allow me to configure a matrix of permissions against resources and scopes, so for example I could have permission to access "accounts" and permission for "view" scope, so therefore I would have permission to view accounts?

我问，因为所有这些的结果似乎是我原来的"viewAccount"功能最终创建了一个具有"View"范围和"viewAccount"权限的"Account"资源，这似乎使我回到了哪里我曾是.如果正确，那没关系.

I ask because the result of all this seems to be that my old "viewAccount" capability ends up creating an "Account" resource, with "View" scope, and a "viewAccount" permission, which seems to get me back where I was. Which is fine, if it's correct.

最后，很明显，我需要一套确定是否应应用viewAccount的策略.但是我是对的，这意味着我需要一个用户可能属于的每个旧组的策略吗?例如，如果我具有服务台"角色，则需要一个服务台成员身份"策略，然后可以将其添加到"viewAccount"权限中.这是正确的吗?

Finally, obviously I need a set of policies that determine if viewAccount should be applied. But am I right that this means I need a policy for each of the legacy groups that a user could belong to? For example, if I have a "helpdesk" role, then I need a "helpdesk membership" policy, which I could then add to the "viewAccount" permission. Is this correct?

谢谢

标记

推荐答案

我知道我晚了2年以上，但我想我会分享我所知道的东西，并希望减轻以后的读者的痛苦.完全透明-我绝不是Keycloak/OAuth/OIDC专家，我所了解的主要是阅读文档，书籍，出色的YouTube以及使用该工具.

I know I'm 2+ years late but I figure I'd share what I know and hopefully alleviate some pain for future readers. Full transparency- I am by no means a Keycloak/OAuth/OIDC expert and what I know is mostly from reading the docs, books, good ol' YouTube and playing around with the tool.

这篇文章将由两部分组成:

This post will be comprised of two parts:

  1. 我将尽我所能回答您所有的问题
  2. 我将向您展示所有如何在Keycloak中使用策略/作用域/权限的方法，而无需部署单独的应用程序，以便更好地理解该线程中的某些核心概念.请注意，尽管这主要是为了使您入门.我正在使用Keycloak 8.0.0.

第一部分

开始之前的一些术语:

Part I

Some terminology before we get started:

  • 在Keycloak中，您可以创建两种类型的权限:基于资源的和基于范围的.
  • 简单地说，对于Resource-Based权限，您可以将其直接应用于资源
  • 对于Scoped-Based权限，您可以将其应用于您的范围或和资源.
  • In Keycloak, you can create 2 types of permissions: Resource-Based and Scope-Based.
  • Simply put, for Resource-Based permissions, you apply it directly to your resource
  • For Scoped-Based permission, you apply it to your scope(s) or scope(s) and resource.

最佳做法是仅创建一个视图"范围，并在多种资源(帐户，交易等)中使用它吗?还是应该创建"viewAccount"范围，"viewTransaction"范围等?

is it best practice to create just one "view" scope, and use it across multiple resources (account, transaction, etc)? Or should I create a "viewAccount" scope, a "viewTransaction" scope, etc?

范围表示受保护资源的一组权限.在您的情况下，您有2个资源:account和transaction，所以我倾向于第二种方法.

Scopes represent a set of rights at a protected resource. In your case, you have 2 resources: account and transaction, so I would lean towards the second approach.

从长远来看，将全局view范围与您的所有资源(例如account，transaction，customer，settlement ...)关联在一起会使授权难以管理和适应安全要求更改.

In the long run, having a global view scope associated with all your resources (e.g. account, transaction, customer, settlement...) makes authorization difficult to both manage and adapt to security requirement changes.

以下是一些示例，您可以查看这些示例以获得设计感

Here are a few examples that you can check out to get a feel for design

  • Slack API
  • Box API
  • Stripe

不过请注意-我并不是说您不应该跨资源共享范围.实际上，Keycloak允许使用具有相同type的资源.例如，您可能同时需要viewAccount和viewTransaction范围才能读取给定帐户下的交易(毕竟，您可能需要访问该帐户才能查看交易).您的要求和标准将严重影响您的设计.

Do note though - I am not claiming that you shouldn't share scopes across resources. Matter of fact, Keycloak allows this for resources with the same type. You could for instance need both viewAccount and viewTransaction scope to read a transaction under a given account (after all you might need access to the account to view transactions). Your requirements and standards will heavily influence your design.

对于资源和范围的每种实用组合，通常是否创建许可?

For each practical combination of resource and scope, is it usual practice to create a permission?

抱歉，我不太了解这个问题，因此我会比较宽泛.为了授予/拒绝对resource的访问，您需要:

Apologies, I don't fully understand the question so I'll be a bit broad. In order to grant/deny access to a resource, you need to:

  • 定义您的政策
  • 定义您的权限
  • 将策略应用于您的权限
  • 将您的权限与scope或resource(或两者)相关联
  • Define your policies
  • Define your permissions
  • Apply your policies to your permissions
  • Associate your permissions to a scope or resource (or both)

使政策强制生效.请参阅授权过程.

for policy enforcement to take effect. See Authorization Process.

如何设置所有这些完全取决于您.例如，您可以:

How you go about setting all this up is entirely up to you. You could for instance:

  • 定义单个策略，并在适当的权限下绑定每个策略.

  • Define individual policies, and tie each policy under the appropriate permission.

更好的是，定义单个策略，然后将所有相关策略分组到aggregated策略(策略策略)下，然后将该聚合策略与scope-based权限相关联.您可以将scoped-based权限应用于资源及其所有关联范围.

Better yet, define individual policies, then group all your related policies under an aggregated policy (a policy of policies) and then associate that aggregated policy with the scope-based permission. You could have that scoped-based permission apply to both the resource and all its associated scope.

或者，您可以通过利用两种不同的类型来进一步分解权限.您可以通过resource-based权限类型专门为资源创建权限，并通过scope-based权限类型单独将其他权限与作用域关联.

Or, you could further break apart your permissions by leveraging the two separate types. You could create permissions solely for your resources via the resource-based permission type, and separately associate other permissions solely with a scope via the scope-based permission type.

您可以选择.

如果有多个权限匹配给定的资源/范围，Keycloak会做什么?

If there are multiple permissions matching a given resource/scope, what does Keycloak do?

这取决于

  1. 资源服务器的Decision Strategy
  2. 每个权限的Decision Strategy
  3. 每个策略的Logic值.
  1. The resource server's Decision Strategy
  2. Each permission's Decision Strategy
  3. Each policy's Logic value.

Logic的值与Java的!运算符相似.它可以是Positive或Negative.当Logic为Positive时，策略的最终评估保持不变.当其Negative时，最终结果为否定(例如，如果策略评估为false并且其Logic为Negative，则它将为true).为简单起见，我们假定Logic始终设置为Positive.

The Logic value is similar with Java's ! operator. It can either be Positive or Negative. When the Logic is Positive, the policy's final evaluation remains unchanged. When its Negative, the final result is negated (e.g. if a policy evaluates to false and its Logic is Negative, then it will be true). To keep things simple, let's assume that the Logic is always set to Positive.

Decision Strategy是我们真正要解决的问题. Decision Strategy可以是Unanimous或Affirmative.在文档中，

The Decision Strategy is what we really want to tackle. The Decision Strategy can either be Unanimous or Affirmative. From the docs,

决策策略

此配置更改了策略评估引擎基于所有评估权限的结果来决定是否应授予资源或范围的方式. 肯定是指至少一个权限必须评估为肯定的决定，才能授予对资源及其范围的访问权限. 一致表示所有权限都必须评估为肯定的决定，以便最终决定也为肯定的.例如，如果对同一资源或范围的两个权限发生冲突(其中一个权限授予访问权限，另一个权限拒绝访问)，则在所选策略为肯定的情况下，将授予对资源或范围的权限.否则，任何权限的一个拒绝也将拒绝对资源或范围的访问.

This configurations changes how the policy evaluation engine decides whether or not a resource or scope should be granted based on the outcome from all evaluated permissions. Affirmative means that at least one permission must evaluate to a positive decision in order grant access to a resource and its scopes. Unanimous means that all permissions must evaluate to a positive decision in order for the final decision to be also positive. As an example, if two permissions for a same resource or scope are in conflict (one of them is granting access and the other is denying access), the permission to the resource or scope will be granted if the chosen strategy is Affirmative. Otherwise, a single deny from any permission will also deny access to the resource or scope.

让我们使用一个示例来更好地理解上述内容.假设您有一个具有2个权限的资源，并且有人正在尝试访问该资源(请记住，对于所有策略，Logic是Positive).现在:

Let's use an example to better understand the above. Suppose you have a resource with 2 permissions and someone is trying to access that resource (remember, the Logic is Positive for all policies). Now:

  1. Permission One的Decision Strategy设置为Affirmative.它还有3个策略，它们分别对它们进行评估:
    • true
    • false
    • false
  1. Permission One has a Decision Strategy set to Affirmative. It also has 3 policies where they each evaluate to:
    • true
    • false
    • false

由于其中一项策略设置为true，因此Permission One设置为true(肯定的-true仅需要1个).

Since one of the policies is set to true, Permission One is set to true (Affirmative - only 1 needs to be true).

  1. Permission Two的Decision Strategy设置为Unanimous，具有2个策略:
    • true
    • false
  1. Permission Two has a Decision Strategy set to Unanimous with 2 policies:
    • true
    • false

在这种情况下，Permission Two为false，因为一个策略为假(一致-它们都必须为true).

In this case Permission Two is false since one policy is false (Unanimous - they all need to be true).

  1. 现在进行最终评估.如果资源服务器的Decision Strategy设置为Affirmative，则将授予对该资源的访问权限，因为Permission One是true.另一方面，如果资源服务器的Decision Strategy设置为Unanimous，则将拒绝访问.
  1. Now comes the final evaluation. If the resource server's Decision Strategy is set to Affirmative, access to that resource would be granted because Permission One is true. If on the other hand, the resource server's Decision Strategy is set to Unanimous, access would be denied.

请参阅:

  • Resource Server Settings
  • Managing Permissions

我们将继续对此进行回顾.在第二部分中，我将解释如何设置资源服务器的Decision Strategy.

We'll keep revisiting this. I explain how to set the resource sever's Decision Strategy in Part II.

例如，我可以有权访问帐户"和查看"范围的权限，因此，我是否有权查看帐户?

so for example I could have permission to access "accounts" and permission for "view" scope, so therefore I would have permission to view accounts?

简短的回答是.现在，让我们对此进行扩展:)

The short answer is yes. Now, let's expand on this a bit :)

如果您具有以下情况:

  1. 资源服务器的Decision Strategy设置为Unanimous或Affirmative
  2. 访问account/{id}资源的权限为true
  3. 访问view范围的权限为true
  1. Resource server's Decision Strategy set to Unanimous or Affirmative
  2. Permission to access the account/{id} resource is true
  3. Permission to access the view scope is true

您将被授予查看该帐户的权限.

You will be granted access to view the account.

  • true + true等于Affirmative或Unanimous Decision Strategy下的true.
  • true + true is equal to true under the Affirmative or Unanimous Decision Strategy.

现在，如果您拥有

  1. 资源服务器的Decision Strategy设置为Affirmative
  2. 访问account/{id}资源的权限为true
  3. 访问view范围的权限为false
  1. Resource server's Decision Strategy set to Affirmative
  2. Permission to access the account/{id} resource is true
  3. Permission to access the view scope is false

您还将 被授予查看该帐户的权限.

You will also be granted access to view the account.

    在Affirmative策略下，
  • true + false是true.
  • true + false is true under the Affirmative strategy.

这里的要点是，对给定资源的访问还取决于您的设置，因此请小心，因为您可能不希望第二种情况.

The point here is that access to a given resource also depends on your setup so be careful as you may not want the second scenario.

但是我是对的，这意味着我需要一个用户可能属于的每个旧版组的策略吗?

But am I right that this means I need a policy for each of the legacy groups that a user could belong to?

我不确定Keycloak在2年前的行为，但是您可以指定基于组的策略，只需在该策略下添加所有组即可.您当然不需要为每个组创建一个策略.

I'm not sure how Keycloak behaved 2 years ago, but you can specify a Group-Based policy and simply add all your groups under that policy. You certainly do not need to create one policy per group.

例如，如果我具有服务台"角色，则需要一个服务台成员身份"策略，然后可以将其添加到"viewAccount"权限中.这是正确的吗?

For example, if I have a "helpdesk" role, then I need a "helpdesk membership" policy, which I could then add to the "viewAccount" permission. Is this correct?

差不多.您可以通过多种方式进行设置.例如，您可以:

Pretty much. There are many ways you can set this up. For instance, you can:

  1. 创建您的资源(例如/account/{id})，并将其与account:view范围相关联.
  2. 创建基于角色的策略并添加helpdesk角色根据该政策
  3. 创建名为viewAccount的Scope-Based权限，并将其与scope，resource和policy
    4. 绑定
  1. Create your resource (e.g. /account/{id}) and associate it with the account:view scope.
  2. create a Role-Based Policy and add the helpdesk role under that policy
  3. Create a Scope-Based permission called viewAccount and tie it with scope, resource and policy

我们将在第二部分中进行类似的设置.

We'll set up something similar in Part II.

Keycloak有一个简洁的小工具，可让您测试所有策略.更好的是，您实际上不需要启动另一台应用程序服务器并部署单独的应用程序即可正常工作.

Keycloak has a neat little tool which allows you test all your policies. Better yet, you actually do not need to spin up another application server and deploy a separate app for this to work.

这是我们要设置的方案:

Here's the scenario that we'll set up:

  1. 我们将创建一个名为stackoverflow-demo
    2. 的新领域
  2. 我们将在该领域下创建bank-api客户端
  3. 我们将为该客户端定义一个名为/account/{id}的资源
  4. account/{id}将具有account:view范围
  5. 我们将在新领域下创建一个名为bob的用户
  6. 我们还将创建三个角色:bank_teller，account_owner和user
    • 我们不会将bob与任何角色相关联.现在不需要.
  1. We'll create a new realm called stackoverflow-demo
  2. We'll create a bank-api client under that realm
  3. We will define a resource called /account/{id} for that client
  4. The account/{id} will have the account:view scope
  5. We'll create a user called bob under the new realm
  6. We'll also create three roles: bank_teller, account_owner and user
    • We will not associate bob with any roles. This is not needed right now.
  • bank_teller和account_owner有权访问/account/{id}资源
  • account_owner有权访问account:view范围
  • user无权访问资源或范围
  • bank_teller and account_owner have access to the /account/{id} resource
  • account_owner has access to the account:view scope
  • user does not have access to the resource or scope

请原谅我，这个例子是不现实的，但我对银行业不熟悉:)

Do forgive me, this example is unrealistic but I'm not familiar with the banking sector :) 

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. Go to http://localhost:8080/auth
  2. Click on the Administration Console link
  3. Create the admin user and login

访问入门以获取更多信息.就我们的目的而言，以上内容就足够了.

Visit Getting Started for more information. For our purposes, the above is enough.

  1. 将鼠标悬停在master领域，然后单击Add Realm按钮.
  2. 输入stackoverflow-demo作为名称.
  3. 单击Create.
  4. 现在左上角应该显示stackoverflow-demo而不是master领域.
  1. Hover your mouse around the master realm and click on the Add Realm button.
  2. Enter stackoverflow-demo as the name.
  3. Click on Create.
  4. The top left should now say stackoverflow-demo instead of the master realm.

请参见创建新领域

  1. 单击左侧的Users链接
  2. 点击Add User按钮
  3. 输入username(例如bob)
  4. 确保已打开User Enabled
  5. 点击Save
  1. Click on the Users link on the left
  2. Click on the Add User button
  3. Enter the username (e.g. bob)
  4. Ensure that User Enabled is turned on
  5. Click Save

请参见创建新用户

  1. 点击Roles链接
  2. 点击Add Role
  3. 添加以下角色:bank_teller，account_owner和user
  1. Click on the Roles link
  2. Click on Add Role
  3. Add the following roles: bank_teller, account_owner and user

同样，请不将您的用户与角色相关联.就我们的目的而言，这不是必需的.

Again, do not associate your user with the roles. For our purposes, this is not needed.

请参见角色

  1. 点击Clients链接
  2. 点击Create
  3. 为Client ID
    4. 输入bank-api
  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. Click on the Clients link
  2. Click on Create
  3. Enter bank-api for the Client ID
  4. For the Root URL enter http://127.0.0.1:8080/bank-api
  5. Click on Save
  6. Ensure that Client Protocol is openid-connect
  7. Change the Access Type to confidential
  8. Change Authorization Enabled to On
  9. Scroll down and hit Save. A new Authorization tab should appear at the top.
  10. Click on the Authorization tab and then Settings
  11. Ensure that the Decision Strategy is set to Unanimous
    • This is the resource server's Decision Strategy

请参阅:

  • Creating a Client Application
  • Enabling Authorization Services
  1. 点击Authorization标签
  2. 点击Authorization Scopes> Create弹出Add Scope页面
  3. 在名称中输入account:view，然后按Enter.
  1. Click on the Authorization tab
  2. Click on Authorization Scopes > Create to bring up Add Scope page
  3. Enter account:view in the name and hit enter.

创建查看帐户资源"

  1. 点击上方的Authorization链接
  2. 单击Resources
  3. 点击Create
  4. 为Name和Display name都输入View Account Resource
  5. 输入account/{id}作为URI
  6. 在Scopes文本框中输入account:view
  7. 点击Save
  1. Click on Authorization link above
  2. Click on Resources
  3. Click on Create
  4. Enter View Account Resource for both the Name and Display name
  5. Enter account/{id} for the URI
  6. Enter account:view in the Scopes textbox
  7. Click Save

请参见创建资源

  1. 再次在Authorization标签下，单击Policies
  2. 从Create Policy下拉列表中选择Role
  3. 在Name部分中，输入Only Bank Teller and Account Owner Policy
  4. 在Realm Roles下，同时选择bank_teller和account_owner角色
  5. 确保将Logic设置为Positive
  6. 点击Save
  7. 点击Policies链接
  8. 从Create Policy下拉列表中再次选择Role.
  9. 这次将Only Account Owner Policy用作Name
  10. 在Realm Roles下选择account_owner
  11. 确保将Logic设置为Positive
  12. 点击Save
  13. 单击顶部的Policies链接，您现在应该看到新创建的策略.
  1. Again under the Authorization tab, click on Policies
  2. Select Role from the the Create Policy dropdown
  3. In the Name section, type Only Bank Teller and Account Owner Policy
  4. Under Realm Roles select both the bank_teller and account_owner role
  5. Ensure that Logic is set to Positive
  6. Click Save
  7. Click on the Policies link
  8. Select Role again from the Create Policy dropdown.
  9. This time use Only Account Owner Policy for the Name
  10. Under Realm Roles select account_owner
  11. Ensure that Logic is set to Positive
  12. Click Save
  13. Click on the Policies link at the top, you should now see your newly created policies.

请参见基于角色的政策

请注意，Keycloak具有更强大的策略.请参见管理策略

Do note that Keycloak has much more powerful policies. See Managing Policies

  1. 再次在Authorization标签下，单击Permissions
  2. 选择Resource-Based
  3. 为Name键入View Account Resource Permission
  4. 在Resources下键入View Account Resource Permission
  5. 在Apply Policy下选择Only Bank Teller and Account Owner Policy
  6. 确保将Decision Strategy设置为Unanimous
  7. 点击Save
  1. Again under the Authorization tab, click on Permissions
  2. Select Resource-Based
  3. Type View Account Resource Permission for the Name
  4. Under Resources type View Account Resource Permission
  5. Under Apply Policy select Only Bank Teller and Account Owner Policy
  6. Ensure that the Decision Strategy is set to Unanimous
  7. Click Save

请参见创建基于资源的权限

Phew ...

  1. 再次在Authorization标签下，选择Evaluate
  2. 在User下输入bob
  3. 在Roles下选择user
    • 这是我们将用户与我们创建的角色相关联的地方.
  1. Again under the Authorization tab, select Evaluate
  2. Under User enter bob
  3. Under Roles select user
    • This is where we will associate our user with our created roles.

  1. 这很有意义，因为我们只允许两个角色通过Only Bank Teller and Account Owner Policy访问该资源.让我们对其进行测试，以确保这是正确的！
  2. 点击评估结果上方的Back链接
  3. 将鲍勃的角色更改为account_owner，然后单击Evaluate.现在，您应该将结果显示为PERMIT.如果您返回并将角色更改为bank_teller
    4. ，则可以达成相同的协议
  1. This makes sense because we only allow two roles access to that resource via the Only Bank Teller and Account Owner Policy. Let's test this to make sure this is true!
  2. Click on the Back link right above the evaluation result
  3. Change bob's role to account_owner and click on Evaluate. You should now see the result as PERMIT. Same deal if you go back and change the role to bank_teller

请参见评估和测试政策

  1. 返回Permissions部分
  2. 这次在Create Permission下拉列表中选择Scope-Based.
  3. 在Name下，输入View Account Scope Permission
  4. 在Scopes下，输入account:view
  5. 在Apply Policy下，输入Only Account Owner Policy
  6. 确保将Decision Strategy设置为Unanimous
  7. 点击Save
  1. Go back to the Permissions section
  2. Select Scope-Based this time under the Create Permission dropdown.
  3. Under Name, enter View Account Scope Permission
  4. Under Scopes, enter account:view
  5. Under Apply Policy, enter Only Account Owner Policy
  6. Ensure that the Decision Strategy is set to Unanimous
  7. Click Save

请参见创建基于范围的权限

第二次试运行

  1. 返回Authorization部分
  2. 点击Evaluate
  3. 用户应为bob
  4. 角色应该为bank_teller
  5. 资源应为View Account Resource，然后单击Add
  6. 单击Evaluate，我们应该会得到DENY.
    • 同样，这并不奇怪，因为bank_teller可以访问resource，但不能访问scope.在这里，一个许可权评估为true，另一个许可权评估为false.给定资源服务器的Decision Strategy设置为Unanimous，最后的决定是DENY.
  1. Go back to the Authorization section
  2. Click on Evaluate
  3. User should be bob
  4. Roles should be bank_teller
  5. Resources should be View Account Resource and click Add
  6. Click on Evaluate and we should get DENY.
    • Again this should come as no surprise as the bank_teller has access to the resource but not the scope. Here one permission evaluates to true, and the other to false. Given that the resource server's Decision Strategy is set to Unanimous, the final decision is DENY.

整洁:)希望这会有所帮助.

Neat :) Hope this helps.

这篇关于密钥斗篷中的资源，范围，权限和策略的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！

查看全文
相关文章
其他开发最新文章
热门教程
热门工具
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆