Aicrosoft.Extensions.Mvc 6.4.0

Mvc 相关扩展

功能

• 使用Aicrosoft\Web\Middlewares\LoggingScopeTraceMiddleware中间件增加TraceId到Request的服务端与Response的客户端并附加到日志属性中。可通过该TraceId全程追踪本次请求。
• 使用Aicrosoft\Web\Middlewares\UnhandedExceptionMiddleware中间件捕获全局异常并输出为Json结果。注：有些异常无法输出Json，因为该异常已经中断了输出。
• 在Microsoft\AspNetCore\Authorization\AuthorizationExtensions.cs 中
• • AddAadAuthService 仅添加授权要求，没有对Role或Scope进行要求。
• • UseAuthService 里的 app.UseAuthentication(); 仅添加授权的验证，
• • UseAuthService 里的 app.UseAdAuthentication(); 是对Role或Scope授权验证。
• • 在WebAPI的头上加上[AdAuth(Roles)]或[AdAuth(Scopes)]是对两者的任一满足要求的验证。

Release

• 修复重要BUG：app.UseAuthentication()必须在前，app.UseAuthorization()必须在后。

功能列表

• AAD授权功能

关于OAuth2和OpenID Connect

关于AAD授权时的一些说明

• https://learn.microsoft.com/zh-cn/azure/active-directory/develop/v2-oauth2-auth-code-flow
• 代表服务端的AppRegsiontions实例 ServerApp 缩写 SR
• 代表客户端的AppRegsiontions实例 ClientApp 缩写 CR
• CR代表的是一个虚拟的用户或者App，这个APP可以不存在。这个用户可以是客户。
• 在SR中：App Roles → Create app role 增加一个access角色并选择Applctions用户类型。
• 在CR中选API permissions → Add a Permsssion → My APIs 选中SR后选Application permission勾选acess Role
• (通过上一步的操作，查看Delegated permission可以看到它显示的是SR中的Scopes。进而可以猜到Role是给Application使用的。而Scopes是给用户使用的。)
• (SR中定义的App Role是给Application用，而Scopes是给委托权限的用户用。)
• (参见文档：https://learn.microsoft.com/en-us/azure/active-directory/develop/permissions-consent-overview?WT.mc_id=Portal-Microsoft_AAD_RegisteredApps#access-scenarios)
• CR中的API Persmission有了Appliction类型的access角色后，它就能相当于是能代表SR中的access角色了。取得了该权限。
• 同理，可以在CR中增加多个ServerAPP的AppRegionstions实例。表示CR都能访问到它们了(有了这些SR的Role)。
• 在CR中的API Permissions中的要执行Grant admin consent for TenantAccount 才能取得Roles。
• 针对Token中的Role和Scope，目前我的理解是：Role是权限限定某个功能或方法，而Scope是可以在方法内执行部分代码的。如：HttpContext.VerifyUserHasAnyAcceptedScope(scopeRequiredByApi)。
• Scopes：A scope is the smallest entity that describes a single permission.
• Roles:A role is a collection of multiple scopes. It can be assigned to a user or included in another role.
• Identity Server 4 和 Azure AD 都实现了OAuth 2.0 标准.
• OpenID Connect是建立在OAuth2协议上的一个简单的身份标识层, 所以OpenID Connect兼容OAuth2.
• Token Docs:/https://learn.microsoft.com/zh-cn/azure/active-directory/develop/access-tokens
• Token 在一定时间后约60~90分钟间过期后就不可以再用了。
• OAuth2的授权流类型Docs:https://learn.microsoft.com/zh-cn/azure/active-directory/develop/v2-oauth2-on-behalf-of-flow
• CR的授权后，接口要求Roles = "provisioning"。使用access的角色，不能正确取得结果，还是没授权。
• CR的授权后，同样的ClientId，不同的Resource取得的Token并不能用于别的接口访问。
• Roles and Scopes in Azure Identity:Roles manage User’s access and Scopes manage Application’s access.
• C端调用S端时，要注意的一点是Scope要写成S端的APPURI ID，而不是当前的C端APPURI ID。

关于OpenID Connect

• 使用OpenID Connect, 客户端应用可以请求一个叫identity token的token, 它会和access token一同返回给客户端应用. 这个identity token就可以被用来登录客户端应用程序, 而这个客户端应用还可以使用access token来访问API资源.
• OpenID Connect是更高级的协议, 它扩展并替代了OAuth2. 尽管现在我们经常说我们在使用OAuth2来保护API, 其实更准确的说, 大多数情况下, 我们使用的是OpenID Connect.

BearerToekn的相关参数

• 不能是scope还是approles这两个不管是哪个模式，都必须要Admin同意，才能正确取得权限。否则scp或者roles的值是空的。
• Audience(aud-受众): The token is targeted for the web API. 令牌面向的API，保护API的AdApp。
• Sub(sub-使用者): It was issued for an app that's allowed to call the web API.令牌是针对可以调用 Web API 的应用颁发的。
• AppRoles(roles-角色)：数组，一般是客户端AdApp从上游的AdApp取得的ApiPermssion，正确的配置后能具有上游AdApp的AppRoles的角色权限。仅用于Client模式。
• Scopes(scp-范围): 例如: "admin_impersonation user_impersonation"。 它仅表示有交互登录情况下的返回。
• Issuer(iss-颁发者): It was issued by a trusted security token service (STS).令牌是由受信任的安全令牌服务 (STS) 颁发的。
• Expiry(exp-过期时间): Its lifetime is in range.
• Signature(sig-签名): It wasn't tampered with.

Azure Ad 应用类型和身份证码流

单页、公共客户端和机密客户端应用程序

• 单页应用程序 Single-page applications：简称为 SPA。它们是一些 Web 应用，其中的令牌是通过浏览器中运行的 JavaScript 或 TypeScript 应用获取的。 许多新式应用的前端都有一个单页应用程序（主要用 JavaScript 编写）。 该应用程序通常使用 Angular、React 或 Vue 等框架。 MSAL 是唯一支持单页应用程序的 Microsoft 身份验证库。
• 公共客户端应用程序 Public client applications：此类别中的应用（例如以下类型）始终以用户身份登录：
  • 以登录的用户身份调用 Web API 的桌面应用
  • 移动应用
  • 在没有浏览器的设备上运行的应用，例如，在 IoT 上运行的应用
• 机密客户端应用程序 Confidential client applications：此类别中的应用包括：
  • 调用 Web API 的 Web 应用
  • 调用 Web API 的 Web API
  • 守护程序应用（即使实施为 Linux 守护程序或 Windows 服务等控制台服务）

关于AzureAd配置节点中的参数说明

• https://learn.microsoft.com/zh-cn/azure/active-directory/develop/scenario-protected-web-api-app-configuration#config-file

{
  "AzureAd": {
    "Instance": "https://login.microsoftonline.com/",
    "ClientId": "[Client_id-of-web-api-eg-2ec40e65-ba09-4853-bcde-bcb60029e596]",
    /*
      You need specify the TenantId only if you want to accept access tokens from a single tenant
     (line-of-business app).
      Otherwise, you can leave them set to common.
      This can be:
      - A GUID (Tenant ID = Directory ID)
      - 'common' (any organization and personal accounts)
      - 'organizations' (any organization)
      - 'consumers' (Microsoft personal accounts)
    */
    "TenantId": "common"
  },
  "Logging": {
    "LogLevel": {
      "Default": "Warning"
    }
  },
  "AllowedHosts": "*"
}