瓜瓜头条

IAM系统的权限管理体系介绍

2023-01-30 10:57 由 coffeebabe 发表于 #企业信息化

目录

IAM平台是什么

IAM（Identity and Access Management 的缩写），即“身份识别与访问管理”，具有认证管理、策略授权、审计、动态授权、身份管理、应用管理等功能。

IDaas平台介绍

IDaas（Identify as a Service 的缩写）, IDaaS 实际上就是一个基于 SaaS 模式的 IAM 解决方案,也就是云上的身份和访问管理服务,完全由受信任的第三方云服务厂商托管和管理。SaaS + IAM = IDaaS。即服务（SaaS）通常是指由别人（一般指云服务厂商）提供的服务，它可以让个人或企业专注于自身更重要的业务。
在 SaaS 这种软件交付模式下，软件不再需要复杂的安装部署过程，只需通过网络连接就可直接使用，软件及其数据托管在云服务厂商中，厂商将全程负责处理软件更新、漏洞修复等维护工作。用户通常通过 Web 浏览器或 API 连接就可以使用软件。

IAM组成

  • 认证管理
  • 身份管理
  • 策略授权
  • 审计
  • 应用管理

IAM系统的权限管理体系

一. 权限管理体系描述

权限管理做为系统工程中比较重要的基础模块,因此一套完善和灵活的权限体系方案可以更好的为系统的安全赋能。完善的权限体系,需要依赖于一套完备的解决方案,在整个体系的建立过程中可以分为两个部分(认证和授权)实现，并且这两个部分没有强依赖性,可以根据业务的不同选择不同的类型进行组合。

  • 认证(认证管理)
    • 认证方式(账号密码、手机验证码、第三方账号登录等)
    • 认证协议(cas、jwt、oauth2等)
  • 鉴权(策略授权)
    • 权限模型(RBAC、ABAC、DAC、MAC)
    • 鉴权模型(shrio、casbin、access list)

二. 认证

认证过程(登录)是一个系统工程的门户也是访问的第一步,只有进行认证过的浏览器才可以进行后续的操作,但是很多时候会将认证的方式和认证的协议搞混,其实这里可以看到认证的方式可以多种多样的(甚至可以进行组合成认证链),而且认证的协议也可以是多种多样的,不管是独立的认证还是进行单点登录的认证都可以根据自己的业务进自由组合。

2.1 认证方式

认证方式(登录方式),随着越来越多的业务场景和一些复杂的环境的要求,诞生出来不同的登录方式,在不同的业务场景下可以进行自主的选择和叠加,分为独立认证方式和叠加认证两种方式。

2.1.1 独立认证

  • 账号密码登录

    ​ 目前最常使用,但是安全性也是最低的一种认证方式,因此一般会采用一些措施保证登录安全和帐号安全。

    • 检测长时间使用同一密码进行强制修改密码操作
    • 对登录过程中的数据进行加密传输
    • 对数据的存储进行加随机盐等安全的密码方式进行脱敏存储(防止撞库)

  • 手机验证码登录

    ​ 手机验证码有着快速登录认证的特点,因此会有一部分系统选择使用手机验证码进行登录，但是也会存在一定的风险。

    • 短信验证码防盗刷
    • 短信验证码超时机制

  • 第三方登录(运营商、微信、支付宝等)

    ​ 越来越多的第三方登录方式(微信为主),由第三方进行认证的主要流程,然后应用后端进行认证结果的判断,例如微信传入openId,应用后端就需要进行账号和openId的关联。

2.1.2 叠加认证(认证链)

由于单一的认证场景下并不能保证认证过程的安全性,因此可以根据不同的业务场景进行认证方式的组合和叠加。

  • 账号密码+短信验证码
  • 账号密码+邮箱验证

2.2 认证协议

认证的协议是认证结果完成之后认证票据的表达形式，也是认证过程中的一部分，因此需要了解不同的认证协议所应对的不同的认证场景，可以在不同的场景下选择合适的认证协议。

2.2.1 CAS

单点登录的协议的一种,通过SSO进行认证的登录操作

sequenceDiagram 浏览器->>前端:访问 前端->>服务器后端:访问 服务器后端-->>前端:返回CAS认证地址 前端->>SSO:访问 SSO-->>浏览器:无全局会话,重定向到登录页面 浏览器->>SSO:携带登录信息进行登录操作 SSO-->>SSO:检验登录信息并且生成TGT存入session SSO-->>浏览器:将保存TGT的sessionId（TGC）写入cookie中并且将页面重定向到前端地址 浏览器->>前端:访问 前端->>服务器后端:访问 服务器后端-->>前端:返回CAS认证地址 前端->>SSO:访问 SSO-->>SSO:校验TGT并且生成ST SSO-->>服务器后端:携带ST返回后端 服务器后端->>SSO:验证当前的ST信息并且根据TGC从session获得用户信息 服务器后端->>前端:登陆成功

2.2.2 JWT

一种简单的认证协议,因为无状态和服务器无关性,因此具有较好的使用基础,但是也会有一些相应的问题

sequenceDiagram 浏览器->>前端:访问 前端->>服务器后端:访问 服务器后端-->>前端:返回SSO认证地址 前端->>SSO:访问 SSO-->>浏览器:无全局会话,重定向到登录页面 浏览器->>SSO:携带登录信息进行登录操作 SSO-->>SSO:检验登录信息并且生成全局会话 SSO-->>浏览器:将全局会话写入cookie中并且将页面重定向到前端地址 浏览器->>前端:访问 前端->>服务器后端:访问 服务器后端-->>前端:返回SSO认证地址 前端->>SSO:访问 SSO-->>SSO:校验全局会话并且生成jwt token SSO-->>服务器后端:携带token返回后端 服务器后端->>SSO:验证当前的token信息并且获得用户信息 服务器后端-->>浏览器:将token写入到浏览器中

三. 鉴权

做为权限体系的组成部分,鉴权也是至关重要的。再认证完成之后,接下来的访问操作我们都需要根据之前生成的认证结果进行权限的校验和判断，这部分的设计也可以分为两部分：权限模型和鉴权模型

3.1 权限模型

权限模型的选择也需要去根据具体的业务进行选择，主流的权限模型分为四种：

自主访问控制(DAC，Discretionary Access Control)

强制访问控制 (MAC，Mandatory Access Control)

基于角色访问控制 (RBAC，Role-based Access Control)

基于属性访问控制 (ABAC，Attribute-based Access Control)

比较常用的则是后面两种，我们就后面两种的使用场景进行讲解。

3.1.1 RBAC(基于角色访问控制)

最常使用的一种访问控制模型,基于角色进行授权，将权限关联到角色上，通过角色的授权进行用户的权限管理,这样有利于进行权限的管理,只需要维护角色的权限即可,不用去关心用户的属性。需要注意单个用户拥有多个角色的时候需要进行权限的合并。

graph TB subgraph 权限管控体系 菜单表-->角色和菜单关联表 角色表-->用户和角色关联表 角色表-->角色和菜单关联表 用户表-->用户和角色关联表 end

3.1.2 ABAC(基于属性访问控制)

基于属性访问控制模型,将权限分裂到不同的属性上，可以针对不同的属性分配不同的权限，适合权限体系多样性的系统,并且可以实时动态变更权限的系统。

graph TB subgraph 权限管控体系 菜单表-->属性和菜单关联表 属性表-->用户和属性关联表 属性表-->属性和菜单关联表 用户表-->用户和属性关联表 end

3.2 鉴权模型

在鉴权体系中,在确定了权限模型之后,那就需要考虑鉴权模型的建立,通过选择不同的鉴权模型进行权限数据的维护和校验。模型在选择的过程中可以根据不同的需求和权限模型进行选择，目前比较主流的下列三种：

shrio

casbin

access list

3.2.1 shrio

一个Apache开源的安全框架,可以很好的和spring代码进行融合，但是由于shrio在做权限的时候，依赖于接口层面的一些注解(不够灵活)，再加上微服务体系中可能会集成进来的别的语言编写的代码，因此在纯java体系并且权限校验的接口变化不频繁的场景下可以选择shrio

3.2.2 casbin

一个支持多种权限模型的框架,可以通过自行配置一些系统的权限规则模型进行权限的校验。因其支持多种不同的模型并且支持鉴权接口的动态配置，再加上语言的无关性，所以有不错的使用基础，但是由于模型配置的问题，导致需要提前预置模型规则

3.2.3 access list

一个基于访问控制列表延申出来的一套方案，通过自行去维护访问的授权列表，来进行权限的校验。由于其只依赖于外部存储和需要预先配置的权限数据，因此不同的体系和不同的资源类型都可以通过这种方式进行配置。

热门相关：仙城纪   豪门闪婚：帝少的神秘冷妻   寂静王冠   第一神算：纨绔大小姐   天启预报