Cool, do you want to create JIRA and send PR with the commit?
On 01/10/17 20:23, Aron Bustya wrote:
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
On 30 September 2017 at 22:32, Aron Bustya <aron.bustya.js(a)gmail.com>
> 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(a)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
>> 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
>> change, if you can add the "claims" to the
>> AuthzEndpointRequestParser.KNOWN_PARAMS and have separate client note
>> for it as other known OIDC params?
>> On 19/09/17 22:49, Aron Bustya wrote:
>> I need the 'claims parameter' support in keycloak that has been thought
>> about in this jira ticket and
>> 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
>> The ProtocolMapper I've written doesn't support the whole claims
>> feature though - it can only add the default value of the claim to the the
>> 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
>> What do you think about the direction of the development, does it make any
>> sense to put some of it back into keycloak?
>> Áron Bustya
>> keycloak-dev mailing