IdentityServer4【Reference】之Profile Service

时间:2023-03-08 16:13:20
IdentityServer4【Reference】之Profile Service

Profile Service

当创建令牌或者请求像Userinfo这种端点时,IdentityServer通常会需要用户的标识信息(identity information),默认情况下,IdentityServer只能从认证(authentication)Cookie中保存的claims中获取这些信息。

将用户的所有可用的信息都保存到Cookie中很显然是不现实的,也是一种不好的实践,所以,IdentityServer定义了一个可扩展的点,这个点(接口)允许动态的加载用户的Claim,这个点(接口)就是IProfileService。开发人员通常实现此接口来访问包含用户数据(claims)的自定义数据库或API。

IProfileService APIs

GetProfileDataAsync

开发者如果实现该接口方法,这个方法应该用来加载用户的claims。这个方法需要一个ProfileDataRequestContext实例作为参数。

IsActiveAsync

开发者如果实现该接口方法,这个方法用来指示当前用户是否能够获取到token,它需要一个IsActiveContext的实例作为参数

ProfileDataRequestContext

它为用户的声明(claims)建模,是用户声明的媒介物(承载体),它包含了以下属性:

Subject

ClaimsPrincipal类型,用来表示用户。

Client

Client类型,表示客户端(第三方)。

RequestedClaimTypes

IEnumerable<string>类型,用来表示请求的Claims类型。

Caller

string类型,用来表示被请求的Claims中上下文(Context)的标识符(例如IdentityToken,AccessToken,用户端点(userinfo endpoint)),IdentityServerConstants.ProfileDataCallers这个静态类声明的常量中包含了关于这方面的信息。

IssuedClaims

List<Claim>类型,这个列表是一个公共的属性,将会被返回,由自定义的IProfileService 实现(中的方法)进行填充。

AddRequestedClaims

它作为ProfileDataRequestContext 的扩展方法,用来填充IssedClaims这个列表属性,但是会首先利用RequestedClaimTypes这个列表属性里面的值过滤一下,也就是说会根据/基于RequestedClaimTypes里面的值返回相应的值。

Requested scopes and claims mapping 请求的scopes和声明之间的映射

在客户端的Scopes中声明的关于用户的信息会被放到token中返回到客户端。GetProfileDataAsync方法负责根据ProfileDataRequestContext中的RequestedClaimTypes属性来返回用户的信息。

而RequestedClaimTypes的填充(它是一个列表)是基于Resource(它为Scope进行了建模)中定义的Claims。如果请求的Scope中包含了IdentityResource,那么RequestedClaimTypes的填充是由IdentityResource中定义的Claims进行填充,如果请求的Scope中包含的是ApiResource,那么RequestedClaimTypes的填充是由ApiResource中定义的Scope进行填充的(由于默认情况如果构造ApiResource的时候没有制定Scopes这个属性的值,那么这个ApiResource内部会利用构造函数传入的name和displayname创建一个Scope)。

IsActiveContext

它建模请求已确定当前用户是否能够被允许获得令牌(token)。它包含以下属性:

Subject

ClaimsPrincipal类型,建模了当前用户,概念同ProfileDataRequestContext中的同名属性。

Client

Client类型,概念同ProfileDataRequestContext中的同名属性

Caller

String类型,概念通ProfileDataRequestContext中的同名属性

IsActive

boolean类型,它应该在IProfileService的实现中被赋值,已确定用户是否可以被允许获得token