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