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 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@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev