Open leonard84 opened 8 years ago
That is the official extension point. Several implementations use exactly this pattern to do so. You'll also need to swap out the @Repository for UserInfo objects to use your class instead of DefaultUserInfo objects.
Thanks for the info, if that is the official extension point for custom claims, then there are still some issues to be fixed (not a complete list):
DefaultUserInfo
, e.g. UserInfoFetcher
DiscoveryEndpoint
currently uses a hardcoded list of supported claimsbtw: is there any best practice on how to name custom claims, e.g., prefix, URN/URL or just the plain name, the openid spec is a bit vague here?
UserInfoFetcher
is client side so you shouldn't need to extend that for the server -- but of course you'll want to replace it with something better suited for the extended claims on the client if you're using the client library.
The DiscoveryEndpoint
should definitely be more extensible.
We're happy to take pull requests that open up overrides of this kind of functionality, as long as it doesn't break the current "default" behavior.
Hi,
we are currently evaluating the MITRE-Stack, one crucial feature that is missing is the ability to define and use custom
claims
.From a cursory look into the code base it could suffice to implement the
UserInfo
interface and and add the missing claims there. Since it'stoJson
method is used for serialization and later mapping inorg.mitre.openid.connect.view.UserInfoView#toJsonFromRequestObj
the additional fields should be automatically picked up. Also an extended version oforg.mitre.openid.connect.service.ScopeClaimTranslationService
would be needed to gain access to those claims. Did I miss anything important?Is there an official extension point planned?