On 4/16/2016 11:23 AM, John Dennis wrote:
On 04/16/2016 10:04 AM, Bill Burke wrote:
>>> I also noticed that when I used the Web UI to examine the SP metadata
>>> (Installation tab of the realm client, selecting the "SAML Metadata
>>> SPSSODescriptor" format) that it did not match the SP metadata that
>>> had been loaded using the client registration service. Not only wasn't
>>> it the exact same metadata, but specifically it was missing several of
>>> the endpoints the SP declared in it's metadata. Why isn't the
metadata
>>> the same and why did Keycloak drop essential endpoint/binding
>>> information?
> Its not going to store the exact SP metadata file that was imported.
> Keycloak only imports SP metadata that Keycloak. Also, the admin
> console is allowed to modify this imported metadata however it wants. I
> don't see a problem with this behavior at all.
Here is the issue. I'm an admin and I register my SP with Keycloak.
But either because things are not working as expected or because I
simply can't remember if I updated the SP metadata in the Keycloak IdP
after I made a change in the SP at my end I decide to go the the
Keycloak Web UI and check and see what Keycloak thinks my SP metadata is.
Instead of seeing what I believe my SP metadata should be I see
something completely different and that is a red flag. I wonder why
the metadata I load is not the same metadata Keycloak is operating on.
Is this the source of my problems?
In particular I'm concerned about Keycloak dropping my SP's SAML
endpoints.
I don't think your concern is valid or a red flag. Please correct me if
I'm wrong, but there is absolutely nothing within the SP metadata file
that defines the preferred way the client wants to communicate if there
are multiple options defined. Also, it is usually the IDP side that
drives these preferences, not the client.
I think what you're implying is that Keycloak will parse the SP
metadata and retain only those parts of it which it currently
understands, it then stores the data it picked out of the metadata in
persistent storage and when asked to display the metadata Keycloak
will read it's internal datastore and format it as SAML metadata.
Correct?
No, it parses the SP metadata file and decides how it is going to
interact with the SP based on best practices, i.e. POST over Redirect, etc.
If so what happens when Keycloak grows support for other SAML
features? Are you then going to require every SP to re-register
themselves so that Keycloak can parse the metadata again and rebuild
it's internal data structures? Shouldn't after a Keycloak upgrade
things just work?
If it works before Keycloak is upgraded, why wouldn't it work after? I
really don't see the admin wanting to switch to Artifact if Keycloak
ever ends up supporting it. Also, IMO, it is just as likely that the
admin defines the client in the admin console and exports the SP
metadata to be consumed by mod-auth-mellon, than for somebody to craft
an SP metadata file and import it into Keycloak. It really depends if
the admin is migrating from an existing SSO solution to Keycloak or not.
IMO, what the bug fixes should be are:
* Make sure "Force POST Binding" is on by default (High Priority)
* Don't support an import unless there are valid bindings. i.e. if only
artifact is listed, then abort import with an error. (High priority)
* Add support for ACSI and ACSU (low priority)
* Add support for Artifact Binding (very low priority, to Won't Implement)
So there are 2 reasons why the entire contents of original metadata
should be preserved:
1) Diagnostics, debugging, etc.
2) Supporting upgrades.
I completely disagree that the entire contents need to be preserved.
And I don't see what a Keycloak upgrade has to do with anything.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com