通常在我们确定一个用户的身份之后，我们需要确定这个用户是否可以访问他要访问的页面或资源（授权）。基于角色的访问控制（RBAC）是企业软件完成此操作的最常用方法之一。它具有高度的灵活性，并可以进行多种配置。 我们将在这里高层讨论角色和权限是什么，它们如何协同工作以及如何使用它们来检查访问权限。
什么是角色（Role）？
角色通常与工作职能保持一致，但根据我们的具体情况，它们很可能不符合工作职能。
例如，如果我们正在建立一个电子商务网站，则可能有一位全站管理员，他可以执行诸如创建新产品，更改库存，查看订单，履行订单，添加用户等工作。
我们可能有一个在履行中工作的人可以查看和履行订单，也许在会计中有一个人应该只能查看订单，而不能更改任何东西。
这些示例中的角色可能是管理员，履行经理，会计管理员等。
用户也可以具有多个角色，或者，为了简化该过程，角色可以是分层的（一个角色封装了多个其他角色，从而在其中包含所有权限）。这就是灵活性的体现！
权限（Permission）是什么？
权限是特定的、基于资源的，权限定义了一个人是否有权访问特定资源。这可能基于资源的类型或特定的资源-例如，用户可能能够编辑所有产品，或者他们可能仅能够编辑产品D和Y。
使用上面的示例，权限的示例可能是查看产品，编辑产品，查看订单，履行订单或添加用户。
在必要的情况下，这些权限可以是细粒度的，也可以是广泛的，但是粒度越细，我们对谁可以做什么的控制就越多-毕竟，这才是重点！而且，由于可以为角色分配多个权限，因此没有令人信服的理由不使它们变得更精细。
角色和权限-将两者捆绑在一起
角色分配有一组特定的权限。它们实际上是命名的权限组。
例如，具有履行经理角色的某人可能有权查看订单，履行订单和退款订单。它们也不是互斥的。会计经理可能还可以查看订单，但他们无法履行或退款，而他们可以查看汇总分析，而履行经理则无法。
这意味着当我们遍历需要检查当前用户是否有权访问或更改给定资源的应用程序逻辑时，我们应始终检查他们是否具有适当的权限，而不是他们是否具有正确的角色。
根据权限而不是角色进行访问检查意味着：
我们只需要检查一件事。在允许他们查看订单列表之前，无需检查某人是会计经理还是执行经理，我们只需检查他们是否具有查看订单权限即可。
我们可以在角色中添加或删除权限，而无需更改应用程序逻辑。如果我们从履行经理角色中删除退款订单权限，而不是在允许用户执行此操作之前从支票中删除该角色，我们可以从角色中删除该权限，然后在检查用户是否具有该权限时在获得特定许可的情况下，我们会被告知他们没有。这适用于向角色添加权限，甚至完全添加新权限。
我们可以添加或删除角色，而无需更改我们的应用程序代码。如果我们需要一个封装了不同于当前可配置权限的新权限集的新角色，则可以创建该角色并将其分配给用户，并且应用程序代码可以继续仅检查用户是否具有给定的权限。