乐趣区

关于后端:MASA-Auth-SSO与Identity设计

jiezi

AAAA

AAAA 即认证、受权、审计、账号（Authentication、Authorization、Audit、Account）。在平安畛域咱们绕不开的两个问题：

  • 受权过程牢靠：让第三方程序可能拜访所需资源又不泄露用户数据，罕用的多方受权协定次要有 OAuth2 和 SAML 2.0

  • 受权后果可控：受权后果用于性能或资源的访问控制。常见的权限管制模型：DAC、MAC、RBAC、ABAC

    想理解权限管制模型的话能够参照上一篇的权限设计

OpenId（Authentication）

OpenID 是一个以用户为核心的数字身份辨认框架，它具备凋谢、分散性。OpenID 的创立基于这样一个概念：咱们能够通过 URI（又叫 URL 或网站地址）来认证一个网站的惟一身份，同理，咱们也能够通过这种形式来作为用户的身份认证

对于反对 OpenID 的网站，用户不须要记住像用户名和明码这样的传统验证标记。取而代之的是，他们只须要事后在一个作为 OpenID 身份提供者（Identity Provider, IDP）的网站上注册。

OAuth2（Authorization）

举个例子：MASA.Contrib 应用 codecov 来剖析单元测试覆盖率，OAuth2 帮我解决了几个平安问题：

  • 明码泄露：不须要把账号密码通知codecov
  • 拜访范畴：只凋谢读取源码的能力
  • 权限回收：在 Github 上撤回受权即可敞开 codecov 的拜访能力

那 OAuth2 是如何解决的呢

咱们来看一张图

OIDC（Authentication & Authorization）

OpenID Connect 1.0 是 OAuth 2.0 协定之上的一个简略的身份层。它容许客户端基于受权服务器执行的身份验证来验证终端用户的身份，并以一种可互操作的、相似 rest 的形式获取对于终端用户的根本概要信息。

OIDC 罕用术语

  • EU：End User：终端用户
  • RP：Relying Party，用来代指 OAuth2 中的受信赖的客户端，身份认证和受权信息的生产方
  • OP：OpenID Provider，有能力提供 EU 认证的服务（比方 OAuth2 中的受权服务），用来为 RP 提供 EU 的身份认证信息
  • ID Token：JWT 格局的数据，蕴含 EU 身份认证的信息
  • UserInfo Endpoint：用户信息接口（受 OAuth2 爱护），当 RP 应用 Access Token 拜访时，返回受权用户的信息，此接口必须应用 HTTPS

OIDC 工作流

  1. RP 发送一个认证申请给 OP
  2. OP 对 EU 进行身份认证，而后提供受权
  3. OP 把 ID Token 和 Access Token（需要的话）返回给 RP
  4. RP 应用 Access Token 发送一个申请 UserInfo EndPoint
  5. UserInfo EndPoint 返回 EU 的 Claims

JWT

JWT（JSON Web token）是一个凋谢的、行业标准的 RFC 7519 办法，用于在单方之间平安地示意申明。

JWT 由 3 局部组成：标头 (Header)、有效载荷(Payload) 和签名 (Signature)。在传输的时候，会将 JWT 的 3 局部别离进行 Base64 编码后用. 进行连贯造成最终传输的字符串

JWT=Base64(Header).Base64(Payload).HMACSHA256(base64UrlEncode(header)+”.”+base64UrlEncode(payload),secret)

Header

JWT 头是一个形容 JWT 元数据的 JSON 对象，alg 属性示意签名应用的算法，默认为 HMAC SHA256（写为 HS256）；typ 属性示意令牌的类型，JWT 令牌对立写为 JWT。最初，应用 Base64 URL 算法将上述 JSON 对象转换为字符串保留

{
  "alg": "HS256",
  "typ": "JWT"
}

Payload

有效载荷局部，是 JWT 的主体内容局部，也是一个 JSON 对象，蕴含须要传递的数据（容许自定义）。

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}

Signature

签名哈希局部是对下面两局部数据签名，须要应用 base64 编码后的 header 和 payload 数据，通过指定的算法生成哈希，以确保数据不会被篡改

HMACSHA256(base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  your-256-bit-secret
)

Identity Server 4 罕用术语

  • Client：一个从 IdentityServer 申请令牌的软件——用于验证用户（申请身份令牌）或拜访资源（申请拜访令牌）。客户端必须先向 IdentityServer 注册，而后能力申请令牌

    • Allowed Scopes：即能够是 Identity Resource，也能够是 Api Scopes 和 Api Resources

  • Resource：您心愿应用 IdentityServer 爱护的货色，如用户的身份数据或 API。资源名称惟一

    • API Scope：API 作用域

      能够当做是 Permission 来用，示例见：https://docs.duendesoftware.c…

    • Identity Resource：对于用户的身份信息（又名申明），例如姓名或电子邮件地址

      • User Claims：身份申明，例如 sub，name，amr，auth_time 等
      • Identity Properties：身份资源自身的一些属性，例如 session_id，issued，expired 等
      • Identity Grants：被授予的身份信息

    • API Resource：一组 API Scope

      • User Claims：须要蕴含在 Access Token 中的用户申明列表
      • API Resource Scope：API 资源蕴含的作用域
      • API Properties：API 自身的一些属性，例如 name, display name, description 等
      • API Grants：被受权的 API 列表
  • Identity Token：身份令牌代表身份验证过程的后果。它至多蕴含用户的标识符以及无关用户如何以及何时进行身份验证的信息。它能够蕴含额定的身份数据
  • Access Token：拜访令牌容许拜访 API 资源。客户端申请拜访令牌并将其转发到 API。拜访令牌蕴含无关客户端和用户（如果存在）的信息。API 应用该信息来受权拜访其数据

  • Grant Types：受权类型（其实还有 Resource owner password，不举荐应用，就不过多介绍了）

    参考自：https://docs.duendesoftware.c…

    • Machine/Robot：Client Credentials

    • Web Applications：Authorization Code With PKCE（Proof Key for Code Exchange）

      通常咱们会抉择 id_token token 作为 response type

      还有一个抉择，就是 Implicit。但在隐式流程中，所有令牌都通过浏览器传输，因而不容许刷新令牌等高级性能。作用范畴就是仅用于用户身份验证（服务器端和 JavaScript 应用程序），或身份验证和拜访令牌申请（JavaScript 应用程序）

    • SPA：Authorization Code With PKCE
    • Native/Mobile Apps：Authorization Code With PKCE
    • TV/Limited Input Device：Device Flow RFC 8628

ASP.Net Core Identity 罕用术语

  • User：用户

    • Action：操作，包含增删改查
    • User Role：用户角色
    • User Claim：用户申明

  • Role：角色

    • Action：操作，包含增删改查
    • Role Claim：角色申明
  • Claim：申明是一个名称值对，示意使用者是什么，而不是使用者能够做什么。基于申明的受权查看申明的值并容许基于该值的资源拜访

  • Policy：策略

    • Require Role：要求角色
    • Require Claim：要求申明
    • Require Assertion：更简单的能够通过要求断言来解决，它反对两个重载的 Func（理论是一个，因为有一个是 Task）

    • Requirements：基于 IAuthorizationRequirement 接口定义一个要求，判断要求要基于 AuthorizationHandler<T> 来实现对应的逻辑

      • 默认策略
      • 回退策略
      • 自定义受权属性

  • Resource：资源

    • Imperative：官网翻译是命令式，能够对特定的资源进行受权策略解决

依赖模型

集成 RBAC

通过.Net Core Identity 的 User Claimns 将 User Role 与 Api Resource、Api Scope、Identity Resource 相关联，能够在不同业务维度下获取到用户的角色

再配合 ASP.Net Core Identity 的 Role 或 Policy 进行资源受权判断来达到 SSO 与 RBAC 的业务落地

总结

本章节波及到 OIDC、ASP.Net Core Identity 和 RBAC 三局部内容。首先 OIDC 的常识体系就比拟宏大，须要依据比较完善的文档把概念都搞清楚以及为什么这么设计的起因，其次还要进行一些微调把 OIDC、RBAC 与 ASP.Net Core Identity 三者联合。能够看出依赖模型其实是个很粗的把各个环节串了起来，但理论落地过程中还免不了对依赖模型进行二次调整来满足不同业务的需要。后续等 MASA Auth 落地后会再出第三篇文章来回顾和还原理论落地过程。

（本文章不代表最终设计）

开源地址

MASA.BuildingBlocks：https://github.com/masastack/…

MASA.Contrib：https://github.com/masastack/…

MASA.Utils：https://github.com/masastack/…

MASA.EShop：https://github.com/masalabs/M…

MASA.Blazor：https://github.com/BlazorComp…

如果你对咱们的 MASA Framework 感兴趣，无论是代码奉献、应用、提 Issue，欢送分割咱们

退出移动版