ABP module-zero +AdminLTE+Bootstrap Table+jQuery权限管理系统第十三节--RBAC模式及ABP权限管理（附赠福利）

ABP+AdminLTE+Bootstrap Table权限管理系统一期
 Github:https://github.com/Jimmey-Jiang/ABP-ASP.NET-Boilerplate-Project-CMS

角色访问控制（RBAC）

角色访问控制（RBAC）应该是目前用得最多也是关注最多的权限管理模型了。
权限（Permission）与角色（Role）相关联，用户（User）通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。
RBAC引入了角色（Role）概念，目的应该是解耦了Permission与User之间的关系，直接授权给Role，而不是直接授权给用户，或者用户组。
基于角色的访问控制方法（RBAC）的显著的两大特征是：

由于角色/权限之间的变化比角色/用户关系之间的变化相对要慢得多，减小了授权管理的复杂性，降低管理开销。
灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。
RBAC支持三个著名的安全原则：最小权限原则，责任分离原则和数据抽象原则。
（1）最小权限原则之所以被RBAC所支持，是因为RBAC可以将其角色配置成其完成任务所需要的最小的权限集。
（2）责任分离原则可以通过调用相互独立互斥的角色来共同完成敏感的任务而体现，比如要求一个计帐员和财务管理员共参与同一过帐。
（3）数据抽象可以通过权限的抽象来体现，如财务操作用借款、存款等抽象权限，而不用操作系统提供的典型的读、写、执行权限。然而这些原则必须通过RBAC各部件的详细配置才能得以体现。

RBAC结构

RBAC认为权限授权实际上是Who、What、How的问题。在RBAC模型中，who、what、how构成了访问权限三元组,也就是“Who对What(Which)进行How的操作”。

Who：权限的拥用者或主体（如Principal、User、Group、Role、Actor等等）
What：权限针对的对象或资源（Resource、Class）。
How：具体的权限（Privilege,正向授权与负向授权）。
Operator：操作。表明对What的How操作。也就是Privilege+Resource
Role：角色，一定数量的权限的集合。权限分配的单位与载体,目的是隔离User与Privilege的逻辑关系.
Group：用户组，权限分配的单位与载体。权限不考虑分配给特定的用户而给组。组可以包括组(以实现权限的继承)，也可以包含用户，组内用户继承组的权限。User与Group是多对多的关系。Group可以层次化，以满足不同层级权限控制的要求。

RBAC的关注点在于Role和User, Permission的关系。称为User assignment(UA)和Permission assignment(PA).关系的左右两边都是Many-to-Many关系。就是user可以有多个role，role可以包括多个user。
凡是用过RDBMS都知道，n:m 的关系需要一个中间表来保存两个表的关系。这UA和PA就相当于中间表。事实上，整个RBAC都是基于关系模型。
Session在RBAC中是比较隐晦的一个元素。标准上说：每个Session是一个映射，一个用户到多个role的映射。当一个用户激活他所有角色的一个子集的时候，建立一个session。每个Session和单个的user关联，并且每个User可以关联到一或多个Session.
在RBAC系统中，User实际上是在扮演角色(Role)，可以用Actor来取代User，这个想法来自于Business Modeling With UML一书Actor-Role模式。考虑到多人可以有相同权限，RBAC引入了Group的概念。Group同样也看作是Actor。而User的概念就具象到一个人。
这里的Group和GBAC（Group-Based Access Control）中的
Group（组）不同。GBAC多用于操作系统中。其中的Group直接和权限相关联，实际上RBAC也借鉴了一些GBAC的概念。
Group和User都和组织机构有关，但不是组织机构。二者在概念上是不同的。组织机构是物理存在的公司结构的抽象模型，包括部门，人，职位等等，而权限模型是对抽象概念描述。组织结构一般用Martin fowler的Party或责任模式来建模。
Party模式中的Person和User的关系，是每个Person可以对应到一个User，但可能不是所有的User都有对应的Person。Party中的部门Department或组织Organization，都可以对应到Group。反之Group未必对应一个实际的机构。例如，可以有副经理这个Group，这是多人有相同职责。
引入Group这个概念，除了用来解决多人相同角色问题外，还用以解决组织机构的另一种授权问题：例如，A部门的新闻我希望所有的A部门的人都能看。有了这样一个A部门对应的Group，就可直接授权给这个Group。

ABP权限管理

首先ABP权限管理也是基于RBAC的。
在 RBAC之中,包含用户users(USERS)、角色roles(ROLES)、目标objects(OBS)、操作operations(OPS)、许可权permissions(PRMS)五个基本数据元素，权限被赋予角色,而不是用户，当一个角色被指定给一个用户时，此用户就拥有了该角色所包含的权限。会话sessions是用户与激活的角色集合之间的映射。
然后我们来看一下一开始就生成的AbpPermissions表。

我们可以看到一个权限（AbpPermissions）有以下属性：
Name：系统范围内的唯一名字。把它定义为一个字符串常量是个不错的注意。我们倾向于将“.”分割不同的层级，但并不要求这么做。你可以设置你任何喜欢的名字。唯一的规则就是这个名字必须是唯一的。

Display Name：使用一个本地化的字符串去显示权限到UI。
Description：和Display Name类似。
IsGrantedByDefault：此权限是否授权给（已登陆）所有用户，除非显示指定。通常设置为False（默认值）。
MultiTenancySides：对租户应用程序，一个权限可以基于租户或者主机(原文:host)。这是个枚举标识，因此权限可以应用于不同方面。一个权限可以有父权限和子权限。

定义权限

前面几篇文章，我们已经完成了用户详情列表的增删改查。
这里我们来给他们加上权限，首先，在module-zero项目中已经完整实现了。我们先看下默认已经存在的代码。

  public class ABPCMSAuthorizationProvider : AuthorizationProvider
    {
        public override void SetPermissions(IPermissionDefinitionContext context)
        {
            context.CreatePermission(PermissionNames.Pages_Users, L("Users"));
            context.CreatePermission(PermissionNames.Pages_Roles, L("Roles"));
            context.CreatePermission(PermissionNames.Pages_Tenants, L("Tenants"), multiTenancySides: MultiTenancySides.Host);
        }
        private static ILocalizableString L(string name)
        {
            return new LocalizableString(name, ABPCMSConsts.LocalizationSourceName);
        }
    }

我们仿照这段代码，新建一个类UserInfoAuthorizationProvider，继承自AuthorizationProvider，看下代码：

   public class UserInfoAuthorizationProvider: AuthorizationProvider
    {
        public override void SetPermissions(IPermissionDefinitionContext context)
        {

            var pages = context.GetPermissionOrNull(PermissionNames.Pages);
            if (pages == null)
                pages = context.CreatePermission(PermissionNames.Pages, L("Pages"));


            var UserInfos= pages.CreateChildPermission(PermissionNames.Pages_UserInfos, L("UserInfos"));
            UserInfos.CreateChildPermission(PermissionNames.Pages_UserInfos_Create, L("UserInfosCreate"));
            UserInfos.CreateChildPermission(PermissionNames.Pages_UserInfos_Delete, L("UserInfosDelete"));
            UserInfos.CreateChildPermission(PermissionNames.Pages_UserInfos_Update, L("UserInfosUpdate"));
        }

        private static ILocalizableString L(string name)
        {
            return new LocalizableString(name, ABPCMSConsts.LocalizationSourceName);
        }
    }

然后再PermissionNames中依样添加如下常量。

  public static class PermissionNames
    {
        public const string Pages_Tenants = "Pages.Tenants";

        public const string Pages_Users = "Pages.Users";

        public const string Pages_Roles = "Pages.Roles";


        public const string Pages = "Pages";

        public const string Pages_UserInfos = "Pages.UserInfos";

        public const string Pages_UserInfos_Create = "Pages.UserInfo.Create";

        public const string Pages_UserInfos_Delete = "Pages.UserInfo.Delete";

        public const string Pages_UserInfos_Update = "Pages.UserInfo.Update";
    }

注册TaskAuthorizationProvider

定位到ABPCMSCoreModule.cs,这里已经有关于 Configuration.Authorization.Providers.Add<ABPCMSAuthorizationProvider>();
我们在他的下面补上我们自己的类。
Configuration.Authorization.Providers.Add<UserInfoAuthorizationProvider>();

给admin赋值

定位到HostRoleAndUserCreator和TenantRoleAndUserBuilder类
然后手动在下面添加上如下代码。

   //Grant all tenant permissions
                var permissions = PermissionFinder
                    .GetAllPermissions(new ABPCMSAuthorizationProvider())
                    .Where(p => p.MultiTenancySides.HasFlag(MultiTenancySides.Host))
                    .ToList();

在这段代码之下，添加如下代码。

     //将UserInfoAuthorizationProvider相关Permission赋予给Admin
                var UserInfoAuthorization =
                    PermissionFinder.GetAllPermissions(new UserInfoAuthorizationProvider()).ToList();
                permissions.AddRange(UserInfoAuthorization);

删除数据库执行命令并生成数据库

有了上面的基础，我们先删除数据库，在生成数据库，有人说这里为什么要删除数据库，因为在在ABP模板项目中暂未提供用户角色权限管理功能，但在AbpZero中提供了该功能，支持按用户或角色赋予权限，在数据库初始化的时候，将权限赋给Admin。我们已经创建了数据库，所以要删除数据库重新初始化。

执行update-database -Verbose命令，于是生成数据库如下。

有了数据，admin用户已经赋予了权限，自然不需要我们去管，但是如果我们切换用户进来，就没有权限，我们怎么出给他加上权限呢。
我们直接在控制方法上添加上标签[AbpAuthorize(PermissionNames.Pages_UserInfos)]就可以了

        [AbpAuthorize(PermissionNames.Pages_UserInfos)]
        [HttpGet]
        [DontWrapResult]

        public async Task<ActionResult> GetUserInfo()
        {
            string pageNumber = string.IsNullOrWhiteSpace(Request["pageNumber"]) ? "0" : Request["pageNumber"];
            string pageSize = string.IsNullOrWhiteSpace(Request["pageSize"]) ? "20" : Request["pageSize"];
            var users = (await _userAppService.GetAll(new PagedResultRequestDto { MaxResultCount = int.MaxValue })).Items;
            var  Userlist = users.Skip(int.Parse(pageNumber) * int.Parse(pageSize)).Take(int.Parse(pageSize)).ToList();
            int totaldata = Userlist.Count();
            var result = new { total = 10, rows = Userlist };
            return Json(result, JsonRequestBehavior.AllowGet);
        }

同时这里是用区别的。

在应用服务层中我们直接直接使用[AbpAuthorize]特性，
但在MVC控制器中使用[AbpMvcAuthorize]特性，
Web API控制器中使用[AbpApiAuthorize]。
AbpAuthorize属性说明(AbpAuthorize attribute notes)
Abp使用动态方法拦截进行权限验证。因此，使用AbpAuthorize特性的方法会有些限制。如下：

不能应用于私有(private)方法
不能应用于静态(static)方法
不能应用于非注入(non-injected)类（我们必须用依赖注入）。
此外，
AbpAuthorize特性可以应用于任何的Public方法，如果此方法被接口调用（比如在Application Services中通过接口调用）
方法是虚(virtual)方法，如果此方法直接被类引用进行调用（像是ASP.NET MVC 或 Web API 的控制器）。
方式是虚(virtual)方法，如果此方法是protected。
注意：有三种AbpAuthorize 特性：
在应用程序服务中（application layer)，我们使用Abp.Authorization.AbpAuthorize；
在MVC控制器（web layer）中，我们使用Abp.Web.Mvc.Authorization.AbpMvcAuthorize；
在ASP.NET Web API，我们使用 Abp.WebApi.Authorization.AbpApiAuthorize。
这三个类继承自不同的地方。
在MVC中，它继承自MVC自己的Abp.Web.Mvc.Authorization.AbpMvcAuthorize类。
在Web API，它继承自Web API 的Abp.WebApi.Authorization.AbpApiAuthorize类。因此，它最好是继承到MVC和Web API中。
但是，在Application 层，它完全是由Abp自己实现没有扩展子任何类。

IPermissionChecker及前端授权

AbpAuthorize 适用于大部分的情况，但是某些情况下，我们还是需要自己在方法体里进行权限验证。我们可以注入和使用IPermissionChecker对象。如下边的代码所示：

public void CreateUser(CreateOrUpdateUserInput input)
{
    if (!PermissionChecker.IsGranted("Administration.UserManagement.CreateUser"))
    {
        throw new AbpAuthorizationException("You are not authorized to create user!");
    }

    //A user can not reach this point if he is not granted for "Administration.UserManagement.CreateUser" permission.
}

因为授权一般在应用服务层中进行，所以ABP默认在ApplicationService基类注入并定义了PermissionChecker属性。这样，在应用服务层就可以直接使用PermissionChecker属性进行权限检查。如下面的代码：


        protected override async Task<User> GetEntityByIdAsync(long id)
        {
            bool UserInfos = PermissionChecker.IsGranted(PermissionNames.Pages_UserInfos);
            //如果当前人员没有权限，则抛出异常
            if (!UserInfos)
            {
                throw new AbpAuthorizationException("没有权限！");
            }
            var user = Repository.GetAllIncluding(x => x.Roles).FirstOrDefault(x => x.Id == id);
            return await Task.FromResult(user);
        }

前台html ，javascript页面中加入以前代码即可过滤权限：

@if (IsGranted(PermissionNames.Pages_UserInfos))
{
 //业务代码
}

我们可以使用定义在abp.auth命名空间下的API.
abp.auth.hasPermission('PermissionNames.Pages_UserInfos);
你也可以使用abp.auth.grantedPermissions来获得所有授权的权限或者使用 abp.auth.allPermissions来获取所有应用中可用的权限名。

注意：自ABP 0.7.8版本开始，将javascript端的abp.auth.hasPermission更名为abp.auth.isGranted。hasPermission已经过时了。在新的项目中不要使用abp.auth.hasPermission。

总结

其实ABP module-zero中的权限管理让人痛苦，如果我要去对AbpPermissions表等其他表进行增删查改的时候，很痛苦，或者给要admin赋值的时候不可能每次都删数据库去实现,虽然在abp zero已经实现。我觉得最好的方式是不要module-zero那套东西，一切都自己去创建一套RBAC。
送上本文源码：https://github.com/Jimmey-Jiang/ABP-ASP.NET-Boilerplate-Project-CMS。