[keycloak-dev] Keycloak's SAML AuthnResponse uses wrong binding

[John Dennis]

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

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?

Let me give you a concrete example. The SP I registered has support for 
the HTTP-Artifact binding. But the HTTP-Artifact endpoint does not show 
up when I ask Keycloak what my SP's metadata is. I'm speculating, but I 
assume what is going on is that because Keycloak didn't understand the 
HTTP-Artifact endpoint it ignored it. Now lets say Keycloak is upgraded 
to a version that supports HTTP-Artifact, it won't just work, I'll have 
to re-register every SP after the upgrade. In a production environment 
this might not even be possible. (Let's not get hung up over the use of 
Artifact in this example and whether it's an important feature to add 
down the road, the point applies to any SAML feature not currently 
understood).

So there are 2 reasons why the entire contents of original metadata 
should be preserved:

1) Diagnostics, debugging, etc.

2) Supporting upgrades.



-- 
John