基本涉及到用户参与的系统都要进行权限管理，权限管理属于系统安全的范畴，权限管理实现对用户访问系统的控制，按照安全规则或者安全策略控制用户可以访问而且只能访问自己被授权的资源。
权限管理包括用户身份认证和授权两个部分，简称认证授权。对于需要访问控制的资源用户首先经过身份认证，认证通过后用户具有该资源的访问权限方可访问。
1.2. 用户身份认证
1.2.1. 概念：身份认证就是判断一个用户是否为合法用户的处理过程。最常用的简单身份认证方式是系统通过对用户输入的用户名和口令，看起是否与系统中储存的该用户的用户名和口令一致，来判断用户身份是否正确。对于采用指纹等系统，则初始指纹；对于硬件key等刷卡系统，则需要刷卡。
1.2.2. 用户名密码身份认证流程。
1.2.3. 关键对象：
Subject：主体，访问系统的用户，程序等，进行认证的都称为主体。
Principal：身份信息，是主体进行身份认证的表示，表示必须具有唯一性，如用户名、手机号、邮箱地址等，一个主体可以有多个身份，但必须有一个主身份。（primary principal）
credential：凭证信息，是只有主体才知道的安全信息，如密码、证书等。
1.3. 授权
1.3.1. 概念：授权即访问控制，控制谁能访问哪些资源。主体进行身份认证后需要分配权限方可访问系统资源，对于某些资源没有权限是无法访问的。
1.3.2. 授权流程。
授权可理解为who对what（which）进行how操作：
who，即主体（Subject），主体需要访问系统中的资源。
what，即资源（Resource），如系统菜单，页面，按钮，类方法信息等。资源包括资源类型和资源实例（用户类：资源类型和用户对象：资源实例）。
how，权限/许可（Permission），规定了主体对资源的操作许可，权限离开资源没有意义，通过权限可知主体对哪些资源都有哪些操作许可。
权限分为粗颗粒和细颗粒，粗颗粒权限是指对资源类型的权限，细颗粒权限是对资源实例的权限。
主体，资源，权限关系图：
1.3.5. 权限分配：
对主体分配权限，主体只允许在权限范围内对资源进行操作，权限分配的数据需要持久化，根据上边的数据模型城建表并将用户的权限信息储存在数据库中。
1.3.6. 权限控制
用户拥有权限即可操作权限范围内的资源，系统不知道主体是否具有访问权限需要对用户的访问进行控制。
1.3.6.1. 基于角色的访问控制
RBAC基于角色的访问控制（）是以角色为中心进行访问控制。比如：主体的角色为总经理可以查询企业运营报表。
缺点：一角色进行访问控制粒度较粗，若主体变为总经理和经理则需要修改代码，可扩展性差。
1.3.6.2. 基于资源的访问控制
RBAC基于资源的访问控制（）是以资源为中心进行访问控制，比如：主体必须具有查询工资的权限才可以查询工资。
有点：系统设计时定义好查询工资的全西安表示，即查询工资所需要的角色变化为总经理和部门经理也只需要将“查询工资的权限”添加到部门经理角色的权限列表中，判断逻辑不用修改，系统可扩展性强。
1.1.1. 什么是粗颗粒度和细颗粒度
对资源类型的管理称为粗颗粒度权限管理，即只控制到菜单，按钮，方法，粗颗粒度例子：用户具有用户管理的权限，具有到处订单明细的权限。
对资源实例的管理称为细颗粒度权限管理，即控制到数据级别的权限，比如：用户只允许修改本部门的员工信息，用户只允许到处自己创建的订单明细。
1.1.2. 如何实现粗颗粒度和细颗粒度
对于粗颗粒度的权限管理可以很容易做系统架构级别的功能，即系统功能操作使用统一的粗颗粒度的权限管理。
对于细颗粒度的权限管理不建议做成系统架构级别的功能，因为对数据级别的控制是系统的业务需求，随着业务需求的变更业务功能的可能性大，建议对数据级别的权限控制在业务层跟杏花开发，比如：用户只允许修改自己创建的商品信息可以在service接口添加校验实现，service接口需要传入当前操作人的表示，与商品信息创建人标识对比，不一致则不允许修改商品信息。
1.2. 基于url拦截
基于url拦截是企业中常用的权限管理方法，实现思路：将系统操作的每个url配置在权限表中，将权限对应到角色，将角色分配给用户，用户访问系统功能通过Filter进行过滤，过滤器获取到用户访问的url，只要访问url是用户分配角色中的url则放行继续访问。
以下是模型图：