UAA与Oathor

Posted 2023-03-28

参考技术A 微服务常用访问安全设计方案——API Tokens

第三种，如上示意图所示，使用Token Based协议来对用户请求进行操作鉴权。

简单介绍下最基本的Token Based的交互方式：

简单介绍下最基本的Token Based的交互方式：

用户使用包含用户名和密码的credential从客户端发起资源请求

后端接受请求，通过授权中心，生产有效token字符串，返回给客户端

客户端获得token后，再次发出资源请求

后端接受带token的请求，通过授权中心，获取相关资源，返回给客户端

以上图Google提供的Apps SSO的机制，简单介绍下SAML鉴权的交互方式：

用户请求访问自建的google application

当前application 生成一个 SAML 身份验证请求。SAML 请求将进行编码并嵌入到SSO 服务的网址中。

当前application将重定向发送到用户的浏览器。重定向网址包含应向SSO 服务提交的编码 SAML 身份验证请求。

SSO（统一认证中心或叫Identity Provider）解码 SAML 请求，并提取当前application的 ACS（声明客户服务）网址以及用户的目标网址（RelayState 参数）。然后，统一认证中心对用户进行身份验证。

统一认证中心生成一个 SAML 响应，其中包含经过验证的用户的用户名。按照 SAML 2.0 规范，此响应将使用统一认证中心的 DSA/RSA 公钥和私钥进行数字签名。

统一认证中心对 SAML 响应和 RelayState 参数进行编码，并将该信息返回到用户的浏览器。统一认证中心提供了一种机制，以便浏览器可以将该信息转发到当前application ACS。

当前application使用统一认证中心的公钥验证 SAML 响应。如果成功验证该响应，ACS 则会将用户重定向到目标网址。

用户将重定向到目标网址并登录到当前application。

Spring Cloud Security解决方案

Spring Cloud Security特点有：

基于OAuth2 和OpenID协议的可配置的SSO登录机制

基于tokens保障资源访问安全

引入UAA鉴权服务，UAA是一个Web服务，用于管理账户、Oauth2客户端和用户用于鉴权的问题令牌(Issue Token)。UAA实现了Oauth2授权框架和基于JWT(JSON web tokens)的问题令牌。

下面简单介绍下UAA，事实上，它是由CloudFoundry发起的，也是CloudFoundry平台的身份管理服务（ https://docs.cloudfoundry.org... ）。

主要功能是基于OAuth2，当用户访问客户端应用时，生成并发放token给目标客户端。

UAA认证服务包含如下几个方面的内容：

认证对象。如用户、客户端以及目标资源服务器

认证类型。主要有授权码模式、密码模式以及客户端模式

认证范围，即认证权限，并作为一个命名的参数附加到AccessToken上。

接下来，结合实例，一起来看下UAA在Spring Cloud中的实践。

如图所示，这是一个简单的基于Spring Cloud微服务架构的例子，它的主要组件有：

Eureka组件提供服务发现功能

独立的Config组件提供类似配置中心的服务，持久化层可以是文件系统，也可是git repository

Auth组件提供基于UAA的鉴权服务

Account组件保存用户的业务信息

其他组件不一一介绍了

这里主要讲Auth组件和Account组件是如何基于UAA服务进行认证和授权。

clientID和clientSecret

accessTokenUrl，这里指定了auth组件的uaa获取token的url

grant-type，即认证类型，这里指定为client_credentials

scope，这里指定了server，说明是这个认证请求只适用在各微服务之间的访问。

UAA中范围和权限之间的区别

【中文标题】UAA中范围和权限之间的区别

【英文标题】：Difference between scope and authority in UAA

【发布时间】：2016-06-11 23:46:08

【问题描述】：

在 UAA 中有两个概念，权限和范围。

这些概念似乎重叠。我想知道确切的区别和目的

例如，oauth.login

【参考方案1】：

范围是代表用户的 OAuth 客户端的权限。它们在获得具有以下授权类型之一的用户令牌后被授予：auth_code, password, implicit。范围表示允许应用程序代表用户访问的内容（称为委托授权）。

权限是 OAuth 客户端代表自己行事的权限，没有用户参与。它们是在获取grant_type 为client_credentials 的客户端令牌后授予的。典型用途是应用程序或 API 尝试在没有用户参与的情况下使用自己的凭据访问资源。

在 UAA 中，oauth.login 是系统级权限，并被 login-server 项目的旧实现使用（当 UAA 和 Login Server 是单独的组件时）。此权限允许登录服务器的管理员级别访问。

【参考方案2】：

1) 权限和角色是权限的弹簧安全措辞。它没有在 OAuth2 规范中定义。

2) 范围由 OAuth2 定义。它旨在定义最终用户允许每个客户端代表其执行的操作（从授权服务器到资源服务器的信息）。

因此，授予客户端的权限应该始终是最终用户权限的子集：所有可能的范围 => 所有用户权限；范围越小，权限越少。

一个技巧，在“客户端”OAuth2 流程中，客户端是最终用户 => 范围在这种情况下没有意义（客户端不是代表某人进行身份验证，而是以其自己的名义）。

默认的 OAuth2 spring-security 转换器将范围转换为权限。对我来说，这会带来很多混乱，不应该发生。范围声明应改为用于过滤最终用户权限。

最新需要编写和配置您自己的权限转换器，这对于 JWT 来说已经可以，但还不能用于自省（应该来，为此打开一张票）

此外，OAuth2 规范中的任何内容都不需要权限（弹簧权限和角色）包含在令牌中（使用私有声明）或由授权服务器管理。资源服务器可以合法地使用主题声明从数据库中检索它，然后“范围”它（根据授予客户端的范围过滤最终用户权限）。