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）的显著的两大特征是：

1. 因为角色/权限之间的变化比角色/用户关系之间的变化相对要慢得多，减少了受权管理的复杂性，下降管理开销。
2. 灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。
   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能够层次化，以知足不一样层级权限控制的要求。

1. RBAC的关注点在于Role和User, Permission的关系。称为User assignment(UA)和Permission assignment(PA).关系的左右两边都是Many-to-Many关系。就是user能够有多个role，role能够包括多个user。
2. 凡是用过RDBMS都知道，n:m 的关系须要一个中间表来保存两个表的关系。这UA和PA就至关于中间表。事实上，整个RBAC都是基于关系模型。
3. Session在RBAC中是比较隐晦的一个元素。标准上说：每一个Session是一个映射，一个用户到多个role的映射。当一个用户激活他全部角色的一个子集的时候，创建一个session。每一个Session和单个的user关联，而且每一个User能够关联到一或多个Session.
4. 在RBAC系统中，User其实是在扮演角色(Role)，能够用Actor来取代User，这个想法来自于Business Modeling With UML一书Actor-Role模式。考虑到多人能够有相同权限，RBAC引入了Group的概念。Group一样也看做是Actor。而User的概念就具象到一我的。
   这里的Group和GBAC（Group-Based Access Control）中的
5. Group（组）不一样。GBAC多用于操做系统中。其中的Group直接和权限相关联，实际上RBAC也借鉴了一些GBAC的概念。
6. Group和User都和组织机构有关，但不是组织机构。两者在概念上是不一样的。组织机构是物理存在的公司结构的抽象模型，包括部门，人，职位等等，而权限模型是对抽象概念描述。组织结构通常用Martin fowler的Party或责任模式来建模。
7. Party模式中的Person和User的关系，是每一个Person能够对应到一个User，但可能不是全部的User都有对应的Person。Party中的部门Department或组织Organization，均可以对应到Group。反之Group未必对应一个实际的机构。例如，能够有副经理这个Group，这是多人有相同职责。
8. 引入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);
        }

同时这里是用区别的。

1. 在应用服务层中咱们直接直接使用[AbpAuthorize]特性，
2. 但在MVC控制器中使用[AbpMvcAuthorize]特性，
3. 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及前端受权

1. 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);
        }

1. 前台html ，javascript页面中加入之前代码便可过滤权限：

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

1. 咱们可使用定义在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。

最后送上福利。

github地址： https://github.com/Jimmey-Jiang/WY.MVC.RMS
一套完整权限管理系统，codefirst,直接生成数据库可用。

本章项目图