[keycloak-dev] Claims parameter support

[Aron Bustya]

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> 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/aa507cb0e4271ff1166cb45a1248aa
> 25affa5135
>
> 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>
> 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> 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
>>> 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 listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>>
>>
>
>