[keycloak-dev] Claims parameter support

[Marek Posolda]

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
>
> 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>
>
>
>
>