[keycloak-dev] Client Registration CLI tool

Stian Thorgersen sthorger at redhat.com
Wed Jun 29 07:11:07 EDT 2016


On 28 June 2016 at 15:28, John Dennis <jdennis at redhat.com> wrote:

> On 06/28/2016 01:35 AM, Stian Thorgersen wrote:
>
>> AFAIK you have one problem? About not all redirect URI included from the
>> SAML entity descriptor. Is that what you are referring to or do you have
>> other problems?
>>
>> In either case fix-ups should be performed by the client registration
>> services, not in the CLI.
>>
>>
>>
>>     * Keycloak has two ways to register a client (client registration
>>     service vs. REST API). The two methods do not produce the same client
>>     configuration (I suspect because they do not share common code in the
>>     server). How are you planning on addressing the discrepancies?
>>
>>
>> The task of the CLI is not to address any discrepancies. It's just
>> invoking the client reg services. Any discrepancies should be handled by
>> the client reg services themselves. Have you created JIRA's for these or
>> can you list them to us?
>>
>
> I think these are all things previously discussed, but here is a recap:
>
> * Force POST Binding must be enabled (saml.force.post.binding). This is an
> example of where the client registration service and the REST API have
> different behavior. One of them produces a ClientRepresentation with this
> SAML attribute defaulted to False and the other defaults it to True. I
> believe the consensus is that this flag needs to be removed because it's
> inconsistent with the SAML spec. On the client side we need to know if we
> are talking to a server which implements the flag or not, so far we do not
> have that check implemented.
>
> * Adding all the SAML binding endpoints to the list of Redirect URI's. The
> endpoint's are present in the SAML Metadata sent to Keycloak but for some
> reason they are ignored. A related issue (not specific to client
> registration) is significant parts of the SAML metadata is ignored and
> discarded (among these are the endpoints)
>
> * Adding the group attribute mapper to the client. A reasonable argument
> could be made this is not part of initial client registration but rather a
> post registration configuration operation. However without group
> information many SAML SP's will not operate correctly because groups are
> typically used to make authorization access decisions. Therefore we must
> assure a new client will return group attribute information.


Can you create JIRAs for these please?


>
>

>
>
>
>>
>>
>>     * The tool should be smart enough to produce a working client without
>>     manual intervention (i.e. the need to run admin cli commands
>> afterwards
>>     to fix problems). Most admins won't know how to tweak the
>> configuration.
>>
>>
>> Can you list any you are aware of? Same comment as above applies though,
>> it's the responsibility of the client reg services to handle this, not
>> the CLI. Otherwise you'd have different behavior if you invoke client
>> reg services directly rather than through the CLI.
>>
>
>
>
>
> --
> John
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160629/db047fe2/attachment.html 


More information about the keycloak-dev mailing list