MASA Auth - SSO与Identity设计

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是如何解决的呢

我们来看一张图

$\"MASA$

OIDC（Authentication & Authorization）

OpenID Connect 1.0是OAuth 2.0协议之上的一个简单的身份层。它允许客户端基于授权服务器执行的身份验证来验证终端用户的身份，并以一种可互操作的、类似rest的方式获取关于终端用户的基本概要信息。

$\"MASA$

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工作流

RP发送一个认证请求给OP
OP对EU进行身份认证，然后提供授权
OP把ID Token和Access Token（需要的话）返回给RP
RP使用Access Token发送一个请求UserInfo EndPoint
UserInfo EndPoint返回EU的Claims

$\"MASA$

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来实现对应的逻辑
  - 默认策略
  - 回退策略
  - 自定义授权属性
Resource：资源
- Imperative：官方翻译是命令式，可以对特定的资源进行授权策略处理

依赖模型

$\"MASA$

集成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落地后会再出第三篇文章来回顾和还原实际落地过程。

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