Identityserver4: RC5 broke support for "roles" claim?

[khelben]

Hi,

I've updated my application from rc3 to rc5. I've implemented a custom IResourceStore (which is actually the same implementation of the InMemoryResourcesStore.

I've replaced the existing scopes from rc3

                StandardScopes.OpenId,
                StandardScopes.ProfileAlwaysInclude,
                StandardScopes.EmailAlwaysInclude,
                StandardScopes.OfflineAccess,
                StandardScopes.RolesAlwaysInclude

by identity resources

        private IEnumerable<IdentityResource> GetPredefinedIdentityResources()
        {
            yield return new IdentityResources.OpenId();
            yield return new IdentityResources.Profile();
            yield return new IdentityResources.Email();
            yield return new IdentityResource("roles", "Identity roles", new []{JwtClaimTypes.Role});
        }

(as a side note, I find it strange that there's no predefined IdentityResource for roles)

This should be enough I queuss, but with RC5 the roles claims are not returned in the id_token, which was the case with RC3.

Am I missing something here?

Kind regards,

Christiaan

[leastprivilege]

does this help?

https://leastprivilege.com/2016/12/14/optimizing-identity-tokens-for-size/

[leastprivilege]

ps. generally speaking roles are often misused at the token service level. To stop encouraging that, we removed them from our own code.

That said - if you know what you are doing feel free to define your own role resource/claims

[leastprivilege]

Maybe I should write a blog post about that as well ;)

[khelben]

Well, I understand the reasoning about whether or not to include it in the id token / access token or getting it from the user info endpoint. And I fully understand that it is my responsability to ensure that the tokens are limited in size.

What I still do not know is how to be able to let IdSvr4 return the role claims and where they should be put (access token / id token / ...)

As you suggested it would be beneficial for every implementor to know more on this, so yes a blog post / documentation would be great.

Thanks

[leastprivilege]

What I still do not know is how to be able to let IdSvr4 return the role claims and where they should be put (access token / id token / ...)

Who should consume those roles? claims in id_tokens are for clients. Claims in access tokens are for APIs.

[khelben]

We have both type of applications.

[khelben]

But the real issue was that in my first example I've added the roles claim to the identity resources, but somehow IdSvr4 didn't include them anymore in the id_token.

So what do I need to do more than the code in my original example?

[khelben]

I've found out that the current RC5 does not allow me to include the role claims in the id_token.

I've tested it with the latest dev branch and re-enabling the AlwaysIncludeUserClaimsInIdToken fixed the issue for me.

So I'll wait till the next release.

But I'm still wondering what the best approach then would be (without having this AlwaysIncludeUserClaimsInIdToken set to true)

[leastprivilege]

I can't believe that.

a) try a response type of id_token (and debug the profile service)
b) try a response type that includes a token (and debug the profile service)
c) try b - but add a call to userinfo (and debug the profile service)

[leastprivilege]

More context

https://leastprivilege.com/2016/12/16/identity-vs-permissions/

[lock[bot]]

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.