Shiro-07-Authorization 授权

授权

[外链图片转存中…(img-Hy85ZiSz-1708262588217)]

授权，也称为访问控制，是管理对资源访问的过程。

换句话说，控制谁有权访问应用程序中的内容。

授权检查的示例包括：是否允许用户查看此网页，编辑此数据，查看此按钮或打印到该打印机？

这些都是决定用户有权访问的内容的决定。

授权要素

授权具有三个在Shiro中引用的核心元素：权限，角色和用户。

权限（Permissions）

Apache Shiro中的权限代表安全策略中最基本的元素。

从根本上讲，它们是有关行为的声明，并明确表示可以在应用程序中完成的操作。

格式正确的权限声明本质上描述了资源以及主题与这些资源进行交互时可以采取的措施。

权限声明的一些示例：

• Open a file

• View the ‘/user/list’ web page

• Print documents

• Delete the ‘jsmith’ user

大多数资源将支持典型的CRUD（创建，读取，更新，删除）操作，但是任何对特定资源类型有意义的操作都是可以的。

基本思想是，权限声明至少基于“资源和操作”。

在查看权限时，可能要意识到的最重要的事情是，权限语句不代表谁可以执行所代表的行为。它们仅是在应用程序中可以执行的操作的声明。

• 权限仅代表行为

权限语句仅反映行为（与资源类型关联的操作）。它们不能反映谁能够执行这种行为。

定义允许谁（用户）执行某事（权限）是一种以某种方式向用户分配权限的练习。这始终由应用程序的数据模型完成，并且在不同的应用程序之间可能会有很大差异。

例如，权限可以分组在一个角色中，并且该角色可以与一个或多个用户对象相关联。或某些应用程序可以具有一个用户组，并且可以为一个组分配一个角色，这通过传递关联将意味着该组中的所有用户都隐式地获得了该角色中的权限。

如何授予用户权限有很多变体-应用程序根据应用程序需求确定如何对此建模。

我们将介绍Shiro如何确定某个主题是否被允许做某事或以后做某事。

权限粒度（Permission Granularity）

首先，权限示例指定对资源类型（门，文件，客户等）的操作（打开，读取，删除等）。

在某些情况下，他们甚至指定了非常精细的实例级行为-例如，使用用户名“ jsmith”（实例标识符）“删除”（操作）“用户”（资源类型）。

在 Shiro 中，您可以精确定义这些语句的粒度。

我们会在 Shiro 的权限文档中更详细地介绍权限粒度和权限声明的“级别”。

角色（Roles）

角色是一个命名实体，通常代表一组行为或职责。这些行为会转化为您可以使用软件应用程序执行或无法执行的操作。角色通常分配给用户帐户，因此通过关联，用户可以“执行”归因于各种角色的事情。

实际上有两种类型的角色，并且Shiro支持这两种概念：

隐式角色

大多数人将角色用作隐式构造：您的应用程序仅基于角色名称隐含一组行为（即权限）。

在具有隐式角色的情况下，在软件级别上没有任何内容说“允许角色X执行行为A，B和C”。

行为仅由名称暗示。

• 潜在的脆弱安全性

虽然更简单，最常见的方法是隐式角色，但可能会带来很多软件维护和管理问题。

例如，如果您只想添加或删除角色，或稍后重新定义角色的行为，该怎么办？

每当需要进行更改时，您都必须返回源代码并更改所有角色检查，以反映安全模型中的更改！更不用说会产生的运营成本（重新测试，进行质量检查，关闭应用程序，使用新角色检查升级软件，重新启动应用程序等）。

对于非常简单的应用程序（例如，可能有“管理员”角色和“其他所有人”），这可能是可以的。但是对于更复杂或可配置的应用程序，这可能是整个应用程序生命周期内的主要主要问题，并为您的软件带来大量维护成本。

显式角色

但是，显式角色本质上是实际权限声明的命名集合。

以这种形式，应用程序（和Shiro）确切地知道具有或没有特定角色的含义。

因为已知可以执行或不能执行的确切行为，所以没有猜测或暗示特定角色可以执行或不能执行的操作。

Shiro团队提倡使用权限和显式角色，而不是较早的隐式方法。您将可以更好地控制应用程序的安全性。

• 基于资源的访问控制

一定要阅读Les Hazlewood的文章“新的RBAC：基于资源的访问控制”，该文章深入介绍了使用权限和显式角色（以及它们对源代码的积极影响）而不是旧的隐式角色方法的好处。

用户（Users）

用户本质上是应用程序的“用户”。但是，正如我们之前介绍的那样，主题实际上是Shiro的“用户”概念。

允许用户（主题）通过与角色或直接权限的关联在您的应用程序中执行某些操作。您应用程序的数据模型精确定义了允许主题执行某项操作或不执行某项操作的方式。

例如，在您的数据模型中，也许您有一个实际的User类，并且直接将权限分配给User实例。或者，您可能仅直接将权限分配给角色，然后再将角色分配给用户，因此通过关联，用户可传递地“拥有”分配给其角色的权限。或者，您可以使用“组”概念来表示这些东西。这取决于您-使用对您的应用程序有意义的内容。

您的数据模型精确定义了授权将如何起作用。 Shiro依靠Realm实现将您的数​​据模型关联详细信息转换为Shiro理解的格式。稍后我们将介绍Realms如何做到这一点。

• 注意

最终，您的Realm实现是与数据源（RDBMS，LDAP等）进行通信的对象。因此，您的 realm 将告诉Shiro是否存在角色或权限。您可以完全控制授权模型的结构和定义方式。