[keycloak-dev] Claims parameter support

[Aron Bustya]

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