[keycloak-dev] Claims parameter support

[Aron Bustya]

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