1 案例1：常用系统监控命令

1.1 问题
本案例要求熟悉查看Linux系统状态的常用命令，为进一步执行具体的监控任务做准备：
查看内存信息
查看交换分区信息
查看磁盘信息
查看CPU信息
查看网卡信息
查看端口信息
查看网络连接信息

1.2 方案
一般企业做监控的目的：实时报告系统状态，提前发现系统的问题。
监控的资源可以分为：共有数据（HTTP、FTP等）和私有数据（CPU、内存、进程数等）。
监控软件可以使用：系统自带的命令、Cacti监控系统、Nagios监控系统、Zabbix监控系统。

1.3 步骤
实现此案例需要按照如下步骤进行。
步骤一：使用命令查看计算机状态数据
1）查看内存与交换分区信息
[root@svr5 ~]# free                                     //查看内存信息
              total        used        free      shared  buff/cache   available
Mem:       16166888     8017696      720016      106504     7429176     7731740
Swap:       4194300      218268     3976032
[root@svr5 ~]# free | awk '/Mem/{print $4}'                //查看剩余内存容量
720928
[root@svr5 ~]# swapon -s                                //查看交换分区信息
文件名                类型            大小        已用        权限
/dev/sda3             partition        4194300    218268    -1

步骤二：查看磁盘与CPU利用率
1）查看磁盘信息
[root@svr5 ~]# df                                     //查看所有磁盘的使用率
文件系统           1K-块      已用      可用         已用% 挂载点
/dev/sda2      476254208 116879624 335159084   26%         /
/dev/sda1         198174    133897     49737   73%         /boot
[root@svr5 ~]# df | awk '/\/$/{print $5}'            //查看根分区的利用率

2）查看CPU平均负载
[root@svr5 ~]# uptime                             //查看CPU负载（1，5，15分钟）
 23:54:12 up 38 days, 14:54,  9 users,  load average: 0.00, 0.04, 0.05
[root@svr5 ~]# uptime |awk '{print $NF}'            //仅查看CPU的15分钟平均负载
0.05

步骤二：查看网卡信息、端口信息、网络连接信息
1）查看网卡信息
[root@svr5 ~]# ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.4.5  netmask 255.255.255.0  broadcast 172.25.0.255
        inet6 fe80::5054:ff:fe00:b  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:00:00:0b  txqueuelen 1000  (Ethernet)
        RX packets 62429  bytes 10612049 (10.1 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5674  bytes 4121143 (3.9 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
[root@svr5 ~]# ifconfig eth0 |awk '/inet /{print $2}'        //查看IP地址信息
192.168.4.5
[root@svr5 ~]# ifconfig eth0 |awk '/RX p/{print $5}'        //网卡接受数据包流量
10625295
[root@svr5 ~]# ifconfig eth0 |awk '/TX p/{print $5}'        //网卡发送数据包流量
4130821

2）查看端口信息
[root@svr5 ~]# ss -ntulp                                //查看本机监听的所有端口
//-n以数字显示端口号
//-t显示tcp连接
//-u显示udp连接
//-p显示监听端口对应的程序名称

3）查看网络连接信息
[root@svr5 ~]# ss -antup                                //查看所有的网络连接信息
//-a查看所有连接状态信息

现在市场上的主流网络安全产品可以分为以下几个大类：
1.基础防火墙FW/NGFW类
  主要是可实现基本包过滤策略的防火墙，这类是有硬件处理、软件处理等，其主要功能实现是限制对IP:port的访问。基本上的实现都是默认情况下关闭所有的通过型访问，只开放允许访问的策略。FW可以拦截低层攻击行为，但对应用层的深层攻击行为无能为力。

   FW部署位置一般为外联出口或者区域性出口位置，对内外流量进行安全隔离。部署方式常见如下



2.IDS类
  此类产品基本上以旁路为主，特点是不阻断任何网络访问，主要以提供报告和事后监督为主，少量的类似产品还提供TCP阻断等功能，但少有使用。

3.IPS类
  解决了IDS无法阻断的问题，基本上以在线模式为主，系统提供多个端口，以透明模式工作。在一些传统防火墙的新产品中也提供了类似功能，其特点是可以分析到数据包的内容，解决传统防火墙只能工作在4层以下的问题。和IDS一样，IPS也要像防病毒系统定义N种已知的攻击模式，并主要通过模式匹配去阻断非法访问,致命缺点在于不能主动的学习攻击方式，对于模式库中不能识别出来的攻击，默认策略是允许

访问的！

  IPS类设备，常被串接在主干路上，对内外网异常流量进行监控处理，部署位置常见如下

4.UTM类安全设备
  是以上三者的结合体，按照IDC提出“统一威胁管理”的概念来看，UTM是将防病毒、入侵检测和防火墙安全设备划归到一起“统一管理”的新类别。

  IDC将防病毒、防火墙和入侵检测等概念融合到被称为统一威胁管理的新类别中，该概念引起了业界的广泛重视，并推动了以整合式安全设备为代表的市场细分的诞生。由IDC提出的UTM是指由硬件、软件和网络技术组成的具有专门用途的设备，它主要提供一项或多项安全功能，将多种安全特性集成于一个硬设备里，构成一个标准的统一管理平台。

  由于性能要求出众，导致造价一般比较高，目前一般只有大型企业会有使用。

  UTM的优点主要有以下几条

  1.整合所带来的成本降低（一身兼多职嘛！） 

  2.降低信息安全工作强度 （减轻管理员负担）

  3.降低技术复杂度

  UTM也不能一劳永逸的解决所有安全问题，总结下来，有如下缺点

  1.网关防御的弊端 

  网关防御在防范外部威胁的时候非常有效，但是在面对内部威胁的时候就无法发挥作用了。有很多资料表明造成组织信息资产损失的威胁大部分来自于组织内部，所以以网关型防御为主的UTM设备目前尚不是解决安全问题的万灵药。 

  2.过度集成带来的风险

  3.性能和稳定性
5.主动安全类
  和前面的产品均不同，主动安全产品的特点是协议针对性非常强，比如WAF就是专门负责HTTP协议的安全处理，DAF就是专门负责数据库Sql 查询类的安全处理。在主动安全产品中通常会处理到应用级的访问流程。对于不认识的业务访问全部隔离(以下以WAF为重点说明这一类安全设备)。

  WAF:Web应用防护系统（Web Application Firewall, 简称：WAF）代表了一类新兴的信息安全技术，用以解决诸如防火墙一类传统设备束手无策的Web应用安全问题。与传统防火墙不同，WAF工作在应用层，因此对Web应用防护具有先天的技术优势。基于对Web应用业务和逻辑的深刻理解，WAF对来自Web应用程序客户端的各类请求进行内容检测和验证，确保其安全性与合法性，对非法的请求予以实时阻断，从而对各类网站站点进行有效防护。

  5.1 WAF部署位置

  通常情况下，WAF放在企业对外提供网站服务的DMZ区域或者放在数据中心服务区域，也可以与防火墙或IPS等网关设备串联在一起（这种情况较少）。总之，决定WAF部署位置的是WEB服务器的位置。因为WEB服务器是WAF所保护的对象。部署时当然要使WAF尽量靠近WEB服务器。

  5.2 WAF部署模式及优缺点

  透明代理模式、反向代理模式、路由代理模式及端口镜像模式。前三种模式也被统称为在线模式，通常需要将WAF串行部署在WEB服务器前端，用于检测并阻断异常流量。端口镜像模式也称为离线模式，部署也相对简单，只需要将WAF旁路接在WEB服务器上游的交换机上，用于只检测异常流量。
  部署模式1 透明代理模式（也称网桥代理模式）

  透明代理模式的工作原理是，当WEB客户端对服务器有连接请求时，TCP连接请求被WAF截取和监控。WAF偷偷的代理了WEB客户端和服务器之间的会话，将会话分成了两段，并基于桥模式进行转发。从WEB客户端的角度看，WEB客户端仍然是直接访问服务器，感知不到WAF的存在；从WAF工作转发原理看和透明网桥转发一样，因而称之为透明代理模式，又称之为透明桥模式。

  这种部署模式对网络的改动最小，可以实现零配置部署。另外通过WAF的硬件Bypass功能在设备出现故障或者掉电时可以不影响原有网络流量，只是WAF自身功能失效。缺点是网络的所有流量（HTTP和非HTTP）都经过WAF对WAF的处理性能有一定要求，采用该工作模式无法实现服务器负载均衡功能。 
  部署模式2 反向代理模式

  反向代理模式是指将真实服务器的地址映射到反向代理服务器上。此时代理服务器对外就表现为一个真实服务器。由于客户端访问的就是WAF，因此在WAF无需像其它模式（如透明和路由代理模式）一样需要采用特殊处理去劫持客户端与服务器的会话然后为其做透明代理。当代理服务器收到HTTP的请求报文后，将该请求转发给其对应的真实服务器。后台服务器接收到请求后将响应先发送给WAF设备，由WAF设备再将应答发送给客户端。这个过程和前面介绍的透明代理其工作原理类似，唯一区别就是透明代理客户端发出的请求的目的地址就直接是后台的服务器，所以透明代理工作方式不需要在WAF上配置IP映射关系。

  这种部署模式需要对网络进行改动，配置相对复杂，除了要配置WAF设备自身的地址和路由外，还需要在WAF上配置后台真实WEB服务器的地址和虚地址的映射关系。另外如果原来服务器地址就是全局地址的话（没经过NAT转换）那么通常还需要改变原有服务器的IP地址以及改变原有服务器的DNS解析地址。采用该模式的优点是可以在WAF上同时实现负载均衡。
  



部署模式3 路由代理模式

  路由代理模式，它与网桥透明代理的唯一区别就是该代理工作在路由转发模式而非网桥模式，其它工作原理都一样。由于工作在路由（网关）模式因此需要为WAF的转发接口配置IP地址以及路由。

  这种部署模式需要对网络进行简单改动，要设置该设备内网口和外网口的IP地址以及对应的路由。工作在路由代理模式时，可以直接作为WEB服务器的网关，但是存在单点故障问题，同时也要负责转发所有的流量。该种工作模式也不支持服务器负载均衡功能。


部署模式4 端口镜像模式

  端口镜像模式工作时，WAF只对HTTP流量进行监控和报警，不进行拦截阻断。该模式需要使用交换机的端口镜像功能，也就是将交换机端口上的HTTP流量镜像一份给WAF。对于WAF而言，流量只进不出。

  这种部署模式不需要对网络进行改动，但是它仅对流量进行分析和告警记录，并不会对恶意的流量进行拦截和阻断，适合于刚开始部署WAF时，用于收集和了解服务器被访问和被攻击的信息，为后续在线部署提供优化配置参考。这种部署工作模式，对原有网络不会有任何影响。

Shiro基础知识

在学习Shiro这个框架之前，首先我们要先了解Shiro需要的基础知识：权限管理



什么是权限管理？

只要有用户参与的系统一般都要有权限管理，权限管理实现对用户访问系统的控制，按照安全规则或者安全策略控制用户可以访问而且只能访问自己被授权的资源。

对权限的管理又分为两大类别：

用户认证
用户授权
用户认证

用户认证，用户去访问系统，系统要验证用户身份的合法性

最常用的用户身份验证的方法：1、用户名密码方式、2、指纹打卡机、3、基于证书验证方法。。系统验证用户身份合法，用户方可访问系统的资源。

举个例子：

当我们输入了自己的淘宝的账户和密码，才能打开购物车
用户认证的流程：

判断该资源能否不认证就能访问【登陆页面、首页】
如果该资源需要认证后才能访问，那么判断该访问者是否认证了
如果还没有认证，那么需要返回到【登陆页面】进行认证
认证通过后才能访问资源


从用户认证我们可以抽取出这么几个概念

subject主体：理解为用户,可能是程序，都要去访问系统的资源，系统需要对subject进行身份认证

principal身份信息：通常是唯一的，一个主体还有多个身份信息，但是都有一个主身份信息（primary principal）【我们可以选择身份证认证、学生证认证等等都是我们的身份信息】
credential凭证信息：可以是密码 、证书、指纹。

总结：主体在进行身份认证时需要提供身份信息和凭证信息。



用户授权

用户授权，简单理解为访问控制，在用户认证通过后，系统对用户访问资源进行控制，用户具有资源的访问权限方可访问。

用户授权的流程

到达了用户授权环节，当然是需要用户认证之后了
用户访问资源，系统判断该用户是否有权限去操作该资源
如果该用户有权限才能够访问，如果没有权限就不能访问了


授权的过程可以简单理解为：主体认证之后，系统进行访问控制

subject必须具备资源的访问权限才可访问该资源..

权限/许可(permission) ：针对资源的权限或许可，subject具有permission访问资源，如何访问/操作需要定义permission，权限比如：用户添加、用户修改、商品删除

资源可以分为两种

资源类型:系统的用户信息就是资源类型，相当于java类。

资源实例:系统中id为001的用户就是资源实例，相当于new的java对象。

权限管理模型

一般地，我们可以抽取出这么几个模型：

主体（账号、密码）
资源（资源名称、访问地址）
权限（权限名称、资源id）
角色（角色名称）
角色和权限关系（角色id、权限id）
主体和角色关系（主体id、角色id）


通常企业开发中将资源和权限表合并为一张权限表，如下：

资源（资源名称、访问地址）
权限（权限名称、资源id）
合并为：

权限（权限名称、资源名称、资源访问地址）




分配权限

用户需要分配相应的权限才可访问相应的资源。权限是对于资源的操作许可。

通常给用户分配资源权限需要将权限信息持久化，比如存储在关系数据库中。把用户信息、权限管理、用户分配的权限信息写到数据库（权限数据模型）



基于角色访问控制

RBAC(role  based  access  control)，基于角色的访问控制。




//如果该user是部门经理则可以访问if中的代码
if(user.hasRole('部门经理')){
    //系统资源内容
    //用户报表查看
}

角色针对人划分的，人作为用户在系统中属于活动内容，如果该 角色可以访问的资源出现变更，需要修改你的代码了，




if(user.hasRole('部门经理') || user.hasRole('总经理')  ){
    //系统资源内容
    //用户报表查看
}

基于角色的访问控制是不利于系统维护(可扩展性不强)。



基于资源的访问控制

RBAC(Resource  based  access  control)，基于资源的访问控制。

资源在系统中是不变的，比如资源有：类中的方法，页面中的按钮。




对资源的访问需要具有permission权限，代码可以写为：

if(user.hasPermission ('用户报表查看（权限标识符）')){
    //系统资源内容
    //用户报表查看
}

建议使用基于资源的访问控制实现权限管理。

粗粒度和细粒度权限

细粒度权限管理：对资源实例的权限管理。资源实例就资源类型的具体化，比如：用户id为001的修改连接，1110班的用户信息、行政部的员工。细粒度权限管理就是数据级别的权限管理。

粗粒度权限管理比如：超级管理员可以访问户添加页面、用户信息等全部页面。部门管理员可以访问用户信息页面包括 页面中所有按钮。

粗粒度和细粒度例子：




系统有一个用户列表查询页面，对用户列表查询分权限，

如果粗颗粒管理，张三和李四都有用户列表查询的权限，张三和李四都可以访问用户列表查询。

进一步进行细颗粒管理，张三（行政部）和李四(开发部)只可以查询自己本部门的用户信息。

张三只能查看行政部 的用户信息，李四只能查看开发部门的用户信息。

细粒度权限管理就是数据级别的权限管理。




如何实现粗粒度权限管理？

粗粒度权限管理比较容易将权限管理的代码抽取出来在系统架构级别统一处理。比如：通过springmvc的拦截器实现授权。

对细粒度权限管理在数据级别是没有共性可言，针对细粒度权限管理就是系统业务逻辑的一部分，在业务层去处理相对比较简单

比如：部门经理只查询本部门员工信息，在service接口提供一个部门id的参数，controller中根据当前用户的信息得到该 用户属于哪个部门，调用service时将部门id传入service，实现该用户只查询本部门的员工。



基于URL拦截

基于url拦截的方式实现在实际开发中比较常用的一种方式。

对于web系统，通过filter过虑器实现url拦截，也可以springmvc的拦截器实现基于url的拦截。



使用权限管理框架实现

对于粗粒度权限管理，建议使用优秀权限管理框架来实现，节省开发成功，提高开发效率。

shiro就是一个优秀权限管理框架。



回顾URL拦截

我们在学习的路途上也是使用过几次URL对权限进行拦截的

当时我们做了权限的增删该查的管理系统，但是在权限表中是没有把资源添加进去，我们使用的是Map集合来进行替代的。 
http://blog.csdn.net/hon_3y/article/details/61926175

随后，我们学习了动态代理和注解，我们也做了一个基于注解的拦截

在Controller得到service对象的时候，service工厂返回的是一个动态代理对象回去
Controller拿着代理对象去调用方法，代理对象就会去解析该方法上是否有注解
如果有注解，那么就需要我们进行判断该主体是否认证了，如果认证了就判断该主体是否有权限
当我们解析出该主体的权限和我们注解的权限是一致的时候，才放行！
http://blog.csdn.net/hon_3y/article/details/70767050



流程





认证的JavaBean

我们之前认证都是放在默认的Javabean对象上的，现在既然我们准备学Shiro了，我们就得专业一点，弄一个专门存储认证信息的JavaBean





/**
 * 用户身份信息，存入session 由于tomcat将session会序列化在本地硬盘上，所以使用Serializable接口
 * 
 * @author Thinkpad
 * 
 */
public class ActiveUser implements java.io.Serializable {
    private String userid;//用户id（主键）
    private String usercode;// 用户账号
    private String username;// 用户名称

    private List<SysPermission> menus;// 菜单
    private List<SysPermission> permissions;// 权限

    public String getUsername() {
        return username;
    }

    public void setUsername(String username) {
        this.username = username;
    }


    public String getUsercode() {
        return usercode;
    }

    public void setUsercode(String usercode) {
        this.usercode = usercode;
    }

    public String getUserid() {
        return userid;
    }

    public void setUserid(String userid) {
        this.userid = userid;
    }

    public List<SysPermission> getMenus() {
        return menus;
    }

    public void setMenus(List<SysPermission> menus) {
        this.menus = menus;
    }

    public List<SysPermission> getPermissions() {
        return permissions;
    }

    public void setPermissions(List<SysPermission> permissions) {
        this.permissions = permissions;
    }


}


认证的服务




    @Override
    public ActiveUser authenticat(String userCode, String password)
            throws Exception {
        /**
    认证过程：
    根据用户身份（账号）查询数据库，如果查询不到用户不存在
    对输入的密码 和数据库密码 进行比对，如果一致，认证通过
         */
        //根据用户账号查询数据库
        SysUser sysUser = this.findSysUserByUserCode(userCode);

        if(sysUser == null){
            //抛出异常
            throw new CustomException("用户账号不存在");
        }

        //数据库密码 (md5密码 )
        String password_db = sysUser.getPassword();

        //对输入的密码 和数据库密码 进行比对，如果一致，认证通过
        //对页面输入的密码 进行md5加密 
        String password_input_md5 = new MD5().getMD5ofStr(password);
        if(!password_input_md5.equalsIgnoreCase(password_db)){
            //抛出异常
            throw new CustomException("用户名或密码 错误");
        }
        //得到用户id
        String userid = sysUser.getId();
        //根据用户id查询菜单 
        List<SysPermission> menus =this.findMenuListByUserId(userid);

        //根据用户id查询权限url
        List<SysPermission> permissions = this.findPermissionListByUserId(userid);

        //认证通过，返回用户身份信息
        ActiveUser activeUser = new ActiveUser();
        activeUser.setUserid(sysUser.getId());
        activeUser.setUsercode(userCode);
        activeUser.setUsername(sysUser.getUsername());//用户名称

        //放入权限范围的菜单和url
        activeUser.setMenus(menus);
        activeUser.setPermissions(permissions);

        return activeUser;
    }

Controller处理认证，如果身份认证成功，那么把认证信息存储在Session中



    @RequestMapping("/login")
    public String login(HttpSession session, String randomcode,String usercode,String password)throws Exception{
        //校验验证码，防止恶性攻击
        //从session获取正确验证码
        String validateCode = (String) session.getAttribute("validateCode");

        //输入的验证和session中的验证进行对比 
        if(!randomcode.equals(validateCode)){
            //抛出异常
            throw new CustomException("验证码输入错误");
        }

        //调用service校验用户账号和密码的正确性
        ActiveUser activeUser = sysService.authenticat(usercode, password);

        //如果service校验通过，将用户身份记录到session
        session.setAttribute("activeUser", activeUser);
        //重定向到商品查询页面
        return "redirect:/first.action";
    }


身份认证拦截器





    //在执行handler之前来执行的
    //用于用户认证校验、用户权限校验
    @Override
    public boolean preHandle(HttpServletRequest request,
            HttpServletResponse response, Object handler) throws Exception {

        //得到请求的url
        String url = request.getRequestURI();
        //判断是否是公开 地址
        //实际开发中需要公开 地址配置在配置文件中
        //从配置中取逆名访问url
        List<String> open_urls = ResourcesUtil.gekeyList("anonymousURL");
        //遍历公开 地址，如果是公开 地址则放行
        for(String open_url:open_urls){
            if(url.indexOf(open_url)>=0){
                //如果是公开 地址则放行
                return true;
            }
        }
        //判断用户身份在session中是否存在
        HttpSession session = request.getSession();
        ActiveUser activeUser = (ActiveUser) session.getAttribute("activeUser");
        //如果用户身份在session中存在放行
        if(activeUser!=null){
            return true;
        }
        //执行到这里拦截，跳转到登陆页面，用户进行身份认证
        request.getRequestDispatcher("/WEB-INF/jsp/login.jsp").forward(request, response);

        //如果返回false表示拦截不继续执行handler，如果返回true表示放行
        return false;
    }

授权拦截器




    //在执行handler之前来执行的
    //用于用户认证校验、用户权限校验
    @Override
    public boolean preHandle(HttpServletRequest request,
            HttpServletResponse response, Object handler) throws Exception {

        //得到请求的url
        String url = request.getRequestURI();
        //判断是否是公开 地址
        //实际开发中需要公开 地址配置在配置文件中
        //从配置中取逆名访问url

        List<String> open_urls = ResourcesUtil.gekeyList("anonymousURL");
        //遍历公开 地址，如果是公开 地址则放行
        for(String open_url:open_urls){
            if(url.indexOf(open_url)>=0){
                //如果是公开 地址则放行
                return true;
            }
        }
        //从配置文件中获取公共访问地址
        List<String> common_urls = ResourcesUtil.gekeyList("commonURL");
        //遍历公用 地址，如果是公用 地址则放行
        for(String common_url:common_urls){
            if(url.indexOf(common_url)>=0){
                //如果是公开 地址则放行
                return true;
            }
        }
        //获取session
        HttpSession session = request.getSession();
        ActiveUser activeUser = (ActiveUser) session.getAttribute("activeUser");
        //从session中取权限范围的url
        List<SysPermission> permissions = activeUser.getPermissions();
        for(SysPermission sysPermission:permissions){
            //权限的url
            String permission_url = sysPermission.getUrl();
            if(url.indexOf(permission_url)>=0){
                //如果是权限的url 地址则放行
                return true;
            }
        }

        //执行到这里拦截，跳转到无权访问的提示页面
        request.getRequestDispatcher("/WEB-INF/jsp/refuse.jsp").forward(request, response);

        //如果返回false表示拦截不继续执行handler，如果返回true表示放行
        return false;
    }

拦截器配置：





    <!--拦截器 -->
    <mvc:interceptors>

        <mvc:interceptor>
            <!-- 用户认证拦截 -->
            <mvc:mapping path="/**" />
            <bean class="cn.itcast.ssm.controller.interceptor.LoginInterceptor"></bean>
        </mvc:interceptor>
        <mvc:interceptor>
            <!-- 授权拦截 -->
            <mvc:mapping path="/**" />
            <bean class="cn.itcast.ssm.controller.interceptor.PermissionInterceptor"></bean>
        </mvc:interceptor>
    </mvc:interceptors>



        <script type="text/javascript">
            $(function () {
                $('pre.prettyprint code').each(function () {
                    var lines = $(this).text().split('\n').length;
                    var $numbering = $('<ul/>').addClass('pre-numbering').hide();
                    $(this).addClass('has-numbering').parent().append($numbering);
                    for (i = 1; i <= lines; i++) {
                        $numbering.append($('<li/>').text(i));
                    };
                    $numbering.fadeIn(1700);
                });
            });
        </script>

权限管理

      权限管理，一般指根据系统设置的安全规则或者安全策略，用户可以访问而且只能访问自己被授权的资源，不多不少。权限管理几乎出现在任何系统里面，只要有用户和密码的系统。权限管理实现对用户访问系统的控制。按照安全规则或安全策略控制用户可以访问而且只能访问自己被授权的资源。

权限管理分类

从控制粒度来看，可以将权限管理分为两大类：

      1、功能级权限管理---粗粒度（比较容易将权限管理代码抽取出来在系统架构级别统一管理）

1、张三赋予“人力资源经理”角色，“人力资源经理”具有“查询员工”、“添加员工”、“修改员工”和“删除员工”权限。此时张三能够进入系统，则可以进行这些操作；
2、李四没有“人力资源经理”角色，此时李四就不能够进入系统进行这些操作了。

       2、数据级权限管理---细粒度（数据级别是没有共性可言的，针对细粒度的权限管理就是系统业务逻辑的一部分，如果在业务层去处理相对简单，如果将细粒度的权限管理统一在系统架构级别去抽取，比较困难，即使进行了抽取，功能也可能存在扩展性不全的弊端。建议细粒度权限管理放在业务层去控制。）

1、张三是北京分公司的“人力资源经理”，他只能够管理北京分公司员工和北京分公司下属的子公司的员工；
2、因为王五是海淀子公司的“人力资源经理”，所以他能够也只能够管理海淀子公司的员工；

从控制方向来看，也可以将权限管理分为两大类：

      1、从系统获取数据，比如查询订单、查询客户资料；

      2、向系统提交数据，比如删除订单、修改客户资料。

 

认证授权

1、用户认证

      用户去访问系统，系统需要验证用户身份的合法性。最常用的用户身份认证方法：1.用户密码方式、2.指纹打卡机、3.基于证书的验证方法。系统验证用户身份合法，用户方可访问系统的资源。

subject：主体，理解为用户，可能是程序，都要去访问系统的资源，系统需要对subject进行身份认证。
principal：身份信息，通常是唯一的，一个主体可以有多个身份信息，但是只能有一个主身份信息(primary  principal)。
credential：凭证信息，可以是密码、证书、指纹等。


主体在进行身份认证时需要提供身份信息和凭证信息。

认证流程：



2、用户授权

      在用户认证通过后，系统对用户访问资源进行控制，当用户具有资源的访问权限方可访问。

授权流程：



权限系统模型

就是：谁？是什么身份？可以允许看到什么内容，执行哪些操作？
      谁？当前访问管理系统的是什么人？---用户
      是什么身份？角色管理，如：经理、主管、销售专员、客服、财务等等。---角色
      可以看到什么内容，执行哪些操作？数据管理：允许看到哪些菜单、字段等？功能权限：增删改---权限



通常企业开发中将资源和权限合并为一张权限表