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

Pedro Igor Silva psilva at redhat.com
Fri Apr 15 14:07:38 EDT 2016


Hi John,

    Like we discussed on IRC, KC relies on the ProtocolBinding attribute of an AuthnRequest to decide which response binding to use. We don't support AssertionConsumerServiceURL neither AssertionConsumerServiceIndex. Accordingly with the specs, all those attributes are optional and mutually exclusive. In case ProtocolBinding is not provided, KC chooses on based on how the AutnRequest was sent. Eg.Ç If sent using POST than use POST to respond.

    Regarding the SP Metadata, I would suggest you to open a JIRA with more details about what you need to get into the SP Metadata and how the mismatch between what you loaded and what is actually published is affecting you.

Regards.
Pedro Igor

----- Original Message -----
From: "John Dennis" <jdennis at redhat.com>
To: "keycloak-dev" <keycloak-dev at lists.jboss.org>
Cc: "Nathan Kinder" <nkinder at redhat.com>
Sent: Thursday, April 14, 2016 9:55:56 PM
Subject: [keycloak-dev] Keycloak's SAML AuthnResponse uses wrong binding

I could use some help from your SAML developers because I'm seeing what 
appears to be incorrect behavior.

During testing with keycloak-1.9.0.Final a SAML AuthnRequest is sent 
using the HTTP-Redirect binding. The AuthnRequest specifies a 
AssertionConsumerServiceURL for the SP which has the HTTP-POST binding. 
When Keycloak responds with the Assertion in the SAMLResponse it 
incorrectly uses the HTTP-Redirect binding instead of the HTTP-POST 
binding (specified in both the AuthnRequest and the SP metadata). This 
causes a failure because the endpoint for the SP's 
AssertionConsumerServiceURL only expects HTTP-POST, the resulting error 
is an invalid HTTP method failure.

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?

Thanks,

-- 
John
_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev



More information about the keycloak-dev mailing list