[keycloak-dev] Claims parameter support

[Marek Posolda]

Great work!

If I see it correctly, there are 2 parts:

1) improvements in request object parsing - I am all for include your 
improvements. If you can create separate JIRA for current request object 
limitation, add the test (there are existing tests for request object in 
OIDCAdvancedRequestParamsTest. Feel free to add new test or change one 
of existing tests) and create separate PR, it will be nice and will be 
merged. If I understand correctly, this is the only part, which really 
blocks you right? (As additional protocolMapper can be deployed to the 
existing Keycloak instance as separate JAR and doesn't require changes 
in core keycloak code?)

2) ProtocolMapper for claims - as you pointed, you don't have full 
support for 'claims' parameter. Still it's better then nothing, so my 
vote is to include your changes. I am not 100% convinced, maybe someone 
has different opinion on it (new protocolMapper always adds a bit of 
additional complexity. However I think it's ok as it's OIDC standard). 
Maybe one small change, if you can add the "claims" to the 
AuthzEndpointRequestParser.KNOWN_PARAMS and have separate client note 
for it as other known OIDC params?

Thanks!
Marek



On 19/09/17 22:49, Aron Bustya wrote:
> Hello!
>
> I need the 'claims parameter' support in keycloak that has been thought
> about in this jira ticket and postponed/rejected:
> https://issues.jboss.org/browse/KEYCLOAK-3226
> The proposed alternatives don't work for me, because I am implementing a
> specification that explicitly requests data to be passed this way.
> In addition to the JIRA above we also need to support passing the claims
> parameter in the signed request object - not just as a separate query param.
>
> I've solved the problem for our own use case by writing a ProtocolMapper
> but some changes were also needed in the keycloak request parser (to
> support the parsing of json objects from the request object - not just
> strings).
>
> The ProtocolMapper I've written doesn't support the whole claims parameter
> feature though - it can only add the default value of the claim to the the
> tokens.
>
> I'm now trying to figure out how much of this code could be put back into
> keycloak, and what needs to be changed to do so.
> My goal would be to use an 'official' keycloak with cutomization only in
> Service Providers and configuration.
>
> Current code commit is here:
> https://github.com/abustya/keycloak/commit/41fecf57a982ffdb9
> 6e210d8bd302d23fa7884da
>
> What do you think about the direction of the development, does it make any
> sense to put some of it back into keycloak?
>
> Regards,
> Áron Bustya
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev