[prev in list] [next in list] [prev in thread] [next in thread] 

List:       keycloak-dev
Subject:    [keycloak-dev] Claims parameter support
From:       aron.bustya.js () gmail ! com (Aron Bustya)
Date:       2017-09-30 20:32:34
Message-ID: CAGZZ5Og4bdyQ3OvsThB+8gCVCOJu_LZ-Wr7Y-RHs02xH0wyD5A () mail ! gmail ! com
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]