過去1年間、IdentityServer3 v1.xを正常に実行してきましたが、現在はv1.6.3からv2.5にアップグレードしています。
IUserServiceを実装するカスタムUserServiceがあるため、これは新しいコンテキストパラメータ用に変更され、ログインできますが、GetProfileDataAsyncに問題があります。
v1.6.3用に構築されたUserServiceは正常に機能し、12の要求されたクレームタイプを確認できます。 requestedClaimTypes
public Task<IEnumerable<Claim>> GetProfileDataAsync(ClaimsPrincipal subject,
IEnumerable<string> requestedClaimTypes = null)
{
var userClaims = claimsService.GetByUserIdAsync(int.Parse(subject.GetSubjectId()));
var claims =
userClaims.Where(x => requestedClaimTypes != null && requestedClaimTypes.Contains(x.Type));
return Task.FromResult(claims);
}
ただし、v2.5にアップグレードしてから、要求されたクレームタイプはcontext.RequestedClaimTypes
、以前取得していた12ではなくsubinのみです。12をすべて入れる唯一の方法は、をに変更するAlwaysIncludeInIdToken
ことです。true
v2.5用に更新されたUserServiceは
public async Task GetProfileDataAsync(ProfileDataRequestContext context)
{
if (context == null) throw new ArgumentNullException("context");
var subject = context.Subject;
var requestedClaimTypes = context.RequestedClaimTypes;
var userClaims = await _claimsService.GetByUserIdAsync(int.Parse(subject.GetSubjectId()));
if (userClaims != null)
{
var claims = userClaims.Where(x => requestedClaimTypes != null && requestedClaimTypes.Contains(x.Type));
context.IssuedClaims = claims;
}
}
SQLを使用してクライアントとスコープを格納しますが、IdentityServer3.EntityFrameworkプロバイダーを使用する以外はデータを変更していません。
私たちのロギングは、以前のように関連するスコープクレームを持つ4つのスコープが要求されていることを示しています
Info: Authorize request validation success {
"ClientId": "MyApp",
"ClientName": "MyApp",
"RedirectUri": "https://xxx:44300/",
"AllowedRedirectUris": [
"https://xxx:44300/"
],
"SubjectId": "9",
"ResponseType": "code id_token",
"ResponseMode": "form_post",
"Flow": "Hybrid",
"RequestedScopes": "openid profile roles user",
"State": "OpenIdConnect.AuthenticationProperties=xxxx",
"Nonce": "xxx",
"SessionId": "xxx",
"Raw": {
"client_id": "MyApp",
"redirect_uri": "https://xxx:44300/",
"response_mode": "form_post",
"response_type": "code id_token",
"scope": "openid profile roles user",
"state": "OpenIdConnect.AuthenticationProperties=xxx",
"nonce": "xxx"
}
}
以前のようにすべてのクレームタイプを要求するために何をする必要がありますか?
仕様では、アクセストークンが要求された場合、id_tokenには最小限のユーザー関連のクレーム(別名sub)のみを含める必要があるとされています。次に、アクセストークンを使用して、userinfoエンドポイントから他のクレームを取得できます。
これは、id_tokenを可能な限り小さく保つための最適化メカニズムです。
これが行われたid_token token
が、行われなかったバグがありましたcode id_token
(これはあなたが使用しているものです)。このバグは途中で修正されました。それがあなたが見ている行動の変化だと思います。
AlwaysIncludeInIdToken
含めるスコープクレームにプロパティを設定するか、userinfoエンドポイントを使用してクレームを取得します。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加