iam场景与授权方案

IAM(Identity and Access Management)

IAM是用来管理用户和系统对资源的访问权限，覆盖了对用户，组织，角色和策略的身份验证，授权和管理。

IAM功能

IAM核心功能如下:

  1. 身份验证: 常见身份认证方式有用户名密码认证、多因素认证（MFA）、单点登录（SSO）、生物识别认证。
  2. 授权: 确保对应用户有相关权限，比如用户A对资源ABC具有读写权限，但是在D资源上只有读权限。
  3. 用户管理: 管理用户的身份和属性信息，包括创建、删除、禁用和启用用户，以及管理用户的组织结构、角色和权限。
  4. 角色管理: 定义和管理角色，角色是一组权限的集合，通常根据用户的职责或工作功能来定义。
  5. 策略管理: 定义和管理访问策略，策略规定了用户或系统可以对哪些资源执行哪些操作。
  6. 审计与监控: 记录和跟踪用户对资源的操作，以及检查和分析安全事件。

IAM应用场景

假设系统是一套微服务系统架构，用户在访问service1的时候需要使用账户1，类似于admin/admin123；接着访问service2又需要使用admin/admin124以此类推。或者需要反复的注册登录，管理员就需要反复审批。

而开发人员需要开发针对服务重复造轮子，这些行为都是非常低效的。

image-20240505215852124

通过IAM中认证服务，只需要一套账号，再根据用户权限就可以访问对应服务，从而提高效率。

身份验证方案

IAM有多种身份认证方案:

  1. 用户名密码认证
  2. 多因素认证(MFA)
  3. 单点登录(SSO)
  4. 生物识别认证

在之前提到过用户访问多个服务中使用一套账号密码的方案就是SSO，所以这里主要是介绍SSO相关方案实现。

SSO(Single sign-on)

JWT(JSON Web Token)

JWT是一种开放标准(RFC 7519)，它由三部分组成:

  • Header

    • alg: 加密算法
    • typ: token类型

  • Payload: 通常包含用户相关信息，比如用户ID,姓名,角色这种；以及其他自定义数据。

  • Signature: 使用指定算法对header和payload进行签名，以确保token的完整性和安全性。签名的生成算法通常会使用header中指定的算法和一个秘钥。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
{
  "header": {
    "alg": "HS256",
    "typ": "JWT"
  },
  "payload": {
    "sub": "1234567890",
    "name": "John Doe",
    "admin": true,
    "iat": 1516239022
  },
  "signature": "HMACSHA256(
    base64UrlEncode(header) + '.' +
    base64UrlEncode(payload),
    secret)"
}

image-20240506095920502

jwt认证流程如下:

  1. 用户发送用户名和密码
  2. iam服务器进行验证,验证通过后返回token
  3. 用户接收保存token,后续访问服务带上token
  4. 服务器验证token，查看那些服务可以访问。

流程上比较简单，也比较好实现。但是在保存token这里会有一些麻烦，是保存在cookie还是localstorage? 这里分别讨论下。首先是关于cookie，如果使用cookie来保存，在安全性方便会比较高: Cookie可以设置HttpOnly和Secure属性，使得Token不容易受到XSS和CSRF等攻击。实现也简单。但是它的大小有限制，假设token大于4kb，cookie就保存不了。

使用LocalStorage的好处在于不会有大小限制，并且可以在跨域请求中使用，不受同源策略的限制。但是安全性不高，因为LocalStorage中数据可以通过JS访问，存在被XSS攻击窃取Token的风险。

所以一般情况下都会使用cookie来保存token，不过cookie有一些局限性，就是当服务端注销用户的时候，token如果还在，那客户端只需要发送token就可以接着使用，并且因为是无状态的，服务端并没有办法阻止。

session

token生成方式和之前一样，再保存上不同，会存在服务端session中。然后，服务器将这个 token 发送给客户端，并要求客户端在后续的请求中使用这个 token 来验证身份。

具体流程如下：

  1. 用户发送用户名和密码给服务器进行登录验证。
  2. 服务器验证用户身份成功后，生成一个唯一的 token，并将其存储在服务器端的会话中。
  3. 服务器将生成的 token 发送给客户端作为登录成功的响应。
  4. 客户端在后续的请求中将 token 放置在请求的头部（通常是 Authorization 头）或者请求体中。
  5. 服务器收到请求后，从请求中获取 token，然后验证 token 的有效性。
  6. 如果 token 有效，则允许用户访问相应的资源，否则拒绝访问。

使用session好处在于可以更加灵活地管理用户会话，例如可以在服务器端主动注销用户会话。相比较于 Cookie 的会话管理方式，使用 token 可以更好地支持跨域访问和无状态服务。

但是带来的坏处是需要额外空间来保存token，每次请求中都需要将 token 发送给服务器，增加了网络传输的开销。

redis token

在这种方式下，服务器将生成的 token 存储在 Redis 数据库中，并在需要验证用户身份时，从 Redis 中获取并验证 token 的有效性。

具体流程如下：

  1. 用户发送用户名和密码给服务器进行登录验证。
  2. 服务器验证用户身份成功后，生成一个唯一的 token，并将其存储在 Redis 数据库中，通常以用户 ID 或其他唯一标识作为 key。
  3. 服务器将生成的 token 发送给客户端作为登录成功的响应。
  4. 客户端在后续的请求中将 token 放置在请求的头部（通常是 Authorization 头）或者请求体中。
  5. 服务器收到请求后，从请求中获取 token，并使用 token 在 Redis 数据库中进行验证。
  6. 如果 token 有效，则允许用户访问相应的资源，否则拒绝访问。

优点：

  • 使用 Redis 存储 token 可以提供快速、高效的 token 验证，因为 Redis 具有高性能的内存数据库。
  • Redis 具有持久化特性，可以确保 token 在服务器重启或者故障恢复后不会丢失。

缺点：

  • 需要额外的 Redis 服务器来存储 token，增加了系统的复杂性和成本。
  • 如果 Redis 服务器发生故障或者网络问题，可能会影响到 token 的验证和用户访问。

总的来说，Redis Token 方式是一种高效、可靠的用户身份验证方式，特别适用于需要快速、高性能的场景，但需要考虑 Redis 服务器的可用性和可靠性。

本质上来说，redis token也是一种session，使用redis token在灵活性和扩展性等方面会比session更好。

参考

#iam
iam场景与授权方案
http://example.com/2024/05/04/iam场景与授权方案/
Author
John Doe
Posted on
May 4, 2024
Licensed under