What's the right way to create a IProfileService

[John0King]

I saw the code about DefaultProfileService and TestProfileService but it seems not work properly.
here's the hybrid flow log (I'm manually add the "name" claim in context.RequestedClaimTypes)

MyApp.Web.Auth.Services.IdentityServerProfileService: Debug: Issued claims: sub, name
IdentityServer4.Services.DefaultClaimsService: Debug: Claim types from profile service that were filtered: sub

From the sourse code :
DefaultProfileService and TestProfileService only add claims in ProfileDataRequestContext.RequestedClaimTypes which only has value in "Implicit flow"
I have service that use "Extension Grants"

here's the ProfileService I used

        public Task GetProfileDataAsync(ProfileDataRequestContext context)
        {
            context.LogProfileRequest(_logger);

            var claimsNames = new List<string>();
            claimsNames.AddRange(context.RequestedResources.IdentityResources.SelectMany(r => r.UserClaims));
            claimsNames.AddRange(context.RequestedResources.ApiResources.SelectMany(r => r.UserClaims));

            claimsNames.AddRange(new[]{
                "rootadmin",
                "role",
                "username",
                "nickname",
                ClaimTypes.Role,
                ClaimTypes.Name
            });

            context.RequestedClaimTypes = claimsNames;
            context.AddRequestedClaims(context.Subject.Claims);

            context.LogIssuedClaims(_logger);
            return Task.CompletedTask;
        }

and the problem is that I must specify the "IdentityResource name" so it can contains the cliam in access_token

[brockallen]

The design is that you indicate the expected claim types on the IdentityResource or the ApiResource if you wan those claims in the tokens.

[John0King]

@brockallen

MyApp.Web.Auth.Services.IdentityServerProfileService: Debug: Issued claims: sub, name
IdentityServer4.Services.DefaultClaimsService: Debug: Claim types from profile service that were filtered: sub

I do add the claims but why it filter again ?

[John0King]

And Is there a sample of ExtensionGrant and custem claims in access_token ?

[John0King]

@brockallen

Thanks for anwser my question.~~ But I'm confusing about id_token and access_token. They both in jwt formate .~~

I read this doc and now I understand except one I'm not sure.

Is Implicit a special flow that will add more claim in id_token ?

[brockallen]

As I said before, the claims in the tokens are controlled by which UserClaims you designate when you model the IdentityResource and ApiResource. Perhaps you read the docs: http://docs.identityserver.io/en/release/topics/resources.html

[John0King]

@brockallen
The DefaultProfileService do not have those line

var claimsNames = new List<string>();
claimsNames.AddRange(context.RequestedResources.IdentityResources.SelectMany(r => r.UserClaims));
claimsNames.AddRange(context.RequestedResources.ApiResources.SelectMany(r => r.UserClaims));
context.RequestedClaimTypes = claimsNames;

and the ProfileDataRequestContext.RequestedClaimTypes is an empty list
but ProfileDataRequestContext.RequestedResouce is

// I can't insert a screenshot here :(
{
    ApiResources: [
        {
            Name: "myApi"
            //...
        }
    ],
    IdentityResources: [
        {
            Name:"wechat.app.openId",
            UserClaims:[
                "wechatminiapp-openid"
            ]
            //...
        }
    ]
}

Is this by design ?

ps: This happened in ExtensionGrants

[brockallen]

All set on this issue -- can we close?

[John0King]

@brockallen Can you answer my last question :

Why ExtensionGrants's context.RequestedResources.IdentityResource and context.RequestedResources.ApiResources does have value, but context.RequestedClaimTypes is a empty list ?

this is how I request the access_token :

let response = await this._client.postFormAsync<tokenResposne>({
            url:`${setting.authEndPoint}/connect/token`,
            data:{
                grant_type:"my extend grant type",
                client_id:"myclient",
                client_secret:"mysecret",
                code:res.code, // this is my extend grant needed parameter
                scope:"myApiScope myExtendGrantIdentityScope"
            }
        });

[brockallen]

As I said before, RequestedClaimTypes is populated by the user claim types configured in the IdentityResource or the ApiResource. It's up to your profile service to honor or ignore that.

[John0King]

@brockallen I'm confusing about the DefaultProfileService of IdentityServer4.Why in some grant type the context.RequestedClaimTypes already have value (populated from IdentityResource and ApiResource) , and some grant type dese not (only context.RequestedResources have value ).

This is the my expected behavior of the IProfileService that IdentityService4 registed by defaut:

1. Add claim typ in identityResouce : name :"IdResouceA". claims : [ "A" ] and add into client definition.
2. Add the claim{ type:"A",value:"a"} to the current user when sign in
3. Request access token with the correct client and IdResouceA scope
4. returned access_token contaions {"A":"a"}

actual behavior: only grant type "Impact" has {"A":"a"} and others does not contaions.

What's the reason IdentityServer can not registe a functional IProfileService by default , IMO
, The cliam already filtered by ApiResouce and IdentityResouce and add thire cliam to make the API and client work is reasonable for me.

[John0King]

@brockallen Is this a bug or there's another class controled this .

1. I can't add any cliam to id_token , there only a 'sub' cliam
2. I must menuly create a IProfileService (not try to extend the cliam , but for requested scope) , so that I can add requested cliam to access_token

I read this doc , and their Id_token can contaions thing like name and picture

[brockallen]

What's the reason IdentityServer can not registe a functional IProfileService by default

There is a default one that uses the cookie as the source of claims for tokens. But if your DB contains more, then you need to implement your own since we don't know your user DB.

[teggno]

As I said before, the claims in the tokens are controlled by which UserClaims you designate when you model the IdentityResource and ApiResource. Perhaps you read the docs: http://docs.identityserver.io/en/release/topics/resources.html

The link is broken. Correct link: http://docs.identityserver.io/en/latest/topics/resources.html

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.