认证

认证：

  • 判断一个用户的身份是否合法的过程，用户去访问系统资源时系统要求验证用户的身份信息，身份合法才可以连续访问，不合法则拒绝访问
  • 目的：为了保护系统的隐私与资源，用户的身份合法方可该系统的资源

会话：

  • 用户认证后，为了避免用户的每次操作都进行认证，会将用户的信息保存在会话中。会话就是系统为了保持当前用户登录状态所提供的机制，常见的机制：基于 session 方式、基于 token 方式等
  • 基于 session 方式：
    • 用户认证成功后，在服务器端生成用户相关的数据保存在 session （当前会话）中，发送给客户端的 session_id 存放到 cookie 中
    • 用户客户端再次请求时带上 session_id 就可以验证服务器端是否存在 session 数据，以此完成用户的合法校验
    • 当用户退出系统或 session 过期销毁时，客户端的 session_id 也就无效了
  • 基于 token 方式：
    • 用户认证成功后，服务端生成一个 token 发送给客户端，客户端可以放到 cookie 或 loadStorage 等存储中，每次请求时带上 token，服务端收到 token 通过验证后即可确认用户身份

image.png

  • 两种方式对比：
    • 基于 session：由 Servlet 规范定制，服务端存储 session 信息需要占用内存资源，客户端需要支持 token
    • 基于 token：一般不需要服务端存储 token，且不限制客户端的存储方式

授权

授权：

  • 用户认证通过根据用户的权限来控制用户访问资源的过程，拥有资源的访问权限则正常访问，没有权限则拒绝访问
  • 认证是为了保证用户身份合法性，授权则是为了更细粒度的对隐私数据进行划分，属于在认证通过后发生的，控制不同的用户能够访问不同的资源

授权数据模型：who 对 what(which) 执行 how 操作

  • Who，即主体（Subject），一般指用户，或者程序，需要访问系统中的资源
  • What，即资源（Resource），如系统菜单、页面、代码方法、系统商品信息等，其中
    • 系统功能资源：对于 web 系统每个功能资源通常对应一个 URL，如系统菜单、页面、按钮等
    • 实体资源或数据资源：由资源类型和资源实例组成，如商品信息为资源类型，商品编号为001的商品为资源实例
  • How，权限，许可（Permission），规定了用户对资源的操作许可，权限离开资源没有意义

示例：
image.png
针对上述权限的表信息：
image.png
image.png
通常企业开发中将资源和权限表合并成一张权限表：

  • 资源（资源id、资源名称、访问地址、…）
  • 权限（权限id、权限标识、权限名称、资源id、…）

合并后：

  • 权限（权限id、权限标识、权限名称、资源名称、资源访问地址、…）

修改后的数据模型：
image.png

RBAC

授权：通常基于 RBAC 实现授权

1、基于角色的访问控制

RBAC：Role-Based Access Control，按角色进行授权，比如：主体的角色为总经理可以查询企业运营报表，查询员工工资信息等，访问控制流程
image.png
伪代码：

  1. if (主体.hasRole("总经理角色 id")){
  2.     查询工资
  3. }

如果需要允许部门经理角色同样允许查询工资，则上述代码就要修改为：

  1. if (主体.hasRole("总经理角色 id") || 主体.hasRole("部门经理角色 id")){
  2.     查询工资
  3. }

缺点：当需要修改角色的控制权限时就需要修改相关代码，系统可扩展性差

2、基于资源的访问控制

RBAC：Resource-Based Access Control，基于资源（或权限）进行授权，如：员工必须具有查询工资权限才可以查询员工工资信息，访问控制流程如下
image.png
伪代码：

  1. if (主体.hasPermission("查询工资")){
  2.     查询工资
  3. }

优点：系统设计时定义好查询工资的权限标识，即使查询工资所需要的角色变化为总经理和部门经理也不需要改变授权代码，系统可扩展性强