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

[Bill Burke]

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