[keycloak-dev] Claims parameter support

[Marek Posolda]

Thanks, I've merged the PR.

My vote is then to also include the protocolMapper for claims parameter 
support.  I can't guarantee for sure that it will be added (need to 
discuss with other team members), but if it's not big issue for you to 
send PR, it will be welcome. Thanks :)

Marek

On 03/10/17 16:12, Aron Bustya wrote:
> Here's the JIRA - with pull request sent:
>
> https://issues.jboss.org/browse/KEYCLOAK-5616
>
> On 2 October 2017 at 20:21, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     Cool, do you want to create JIRA and send PR with the commit?
>
>     Thanks,
>     Marek
>
>
>     On 01/10/17 20:23, Aron Bustya wrote:
>>     https://github.com/abustya/keycloak/commit/aa507cb0e4271ff1166cb45a1248aa25affa5135
>>     <https://github.com/abustya/keycloak/commit/aa507cb0e4271ff1166cb45a1248aa25affa5135>
>>
>>     I have updated my code - now it doesn't include the mapper
>>     itself, but it does include the processing of the param as a
>>     "known param" and some tests for this.
>>
>>     On 30 September 2017 at 22:32, Aron Bustya
>>     <aron.bustya.js at gmail.com <mailto:aron.bustya.js at gmail.com>> wrote:
>>
>>         Hi,
>>
>>         Sorry for the long silence.
>>
>>         >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?
>>         This would be good, because the "additional" parameters have
>>         a maximum length of 200 characters to be processed.
>>
>>
>>
>>         On 20 September 2017 at 09:55, Marek Posolda
>>         <mposolda at redhat.com <mailto:mposolda at redhat.com>> wrote:
>>
>>             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
>>>             <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
>>>             <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
>>>             <mailto:keycloak-dev at lists.jboss.org>
>>>             https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>             <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>
>>
>>
>>
>
>