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

[Bill Burke]

On 4/15/2016 5:51 PM, John Dennis wrote:
> On 04/15/2016 02:07 PM, Pedro Igor Silva wrote:
>
>> 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.
>
> I don't believe that's true, they are not all mutually exclusive. Here
> is my reading of the SAML Core Spec in Section "3.4.1 Element
> <AuthnRequest>"
>
> The AssertionConsumerServiceIndex, AssertionConsumerServiceURL and
> ProtocolBinding attributes are all optional. The
> AssertionConsumerServiceIndex is mutually exclusive with the
> AssertionConsumerServiceURL attribute. The ProtocolBinding attribute
> may only be composed with the AssertionConsumerServiceURL
> attribute. Therefore the ProtocolBinding attribute is also mutually
> exclusive with the AssertionConsumerServiceIndex attribute.
>
> Here are the 5 possible legal combinations:
>
> 1) None of AssertionConsumerServiceIndex, AssertionConsumerServiceURL
> nor ProtocolBinding are supplied.
>
> 2) AssertionConsumerServiceIndex is supplied
>
> 3) AssertionConsumerServiceURL is supplied
>
> 4) AssertionConsumerServiceURL and ProtocolBinding are supplied.
>
> 5) ProtocolBinding is supplied.
>
> In the Web SSO case the SAML Profiles Spec in Section
> 4.1.2 "Profile Overview" in "Step 5. Identity Provider issues <Response>
> to Service Provider" the spec is very clear you're supposed to respond
> with an AuthnResponse using either POST or Artifact, but *never*
> Redirect. Here is the specification text:
>
> "In step 5, the identity provider issues a <Response> message to be
> delivered by the user agent to the service provider. Either the HTTP
> POST, or HTTP Artifact binding can be used to transfer the message to
> the service provider through the user agent. The message may indicate
> an error, or will include (at least) an authentication assertion. The
> HTTP Redirect binding MUST NOT be used, as the response will typically
> exceed the URL length permitted by most user agents."
>
>> 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.
>
> See above, this is not correct.
>
> You can only respond using either HTTP-Post or Artifact. So which of the
> two do you choose? You need to follow the rules outlined above for the
> presence of the attributes in the AuthnRequest. Here is how I think you
> need to handle the 5 cases enumerated above.
>
> 1) Since nothing was specified use a default (HTTP-Post). The spec seems
> to be silent on what the default should be but HTTP-Post seems like the
> best choice.
>
> 2) Verify the AssertionConsumerServiceIndex is valid and specifies a
> binding of either HTTP-Post or Artifact, if not it's an error. If the
> ProtocolBinding attribute is also specified it's an error.
>
> 3) If only the AssertionConsumerServiceURL is specified you have to
> figure out if you're going to use HTTP-Post or Artifact. The spec is
> silent on how you determine this but a reasonable and friendly thing to
> do is scan the AssertionConsumerService endpoints the SP supplied in
> it's metadata in order [1] and select the first one which matches either
> HTTP-Post or Artifact. If none of them match use the default 
> (HTTP-Post). You must verify the AssertionConsumerServiceURL is 
> present in the SP metadata.
>
> 4) Verify the ProtocolBinding is one of HTTP-Post or Artifact, if not
> it's an error. Use the ProtocolBinding attribute for the binding and 
> the AssertionConsumerServiceURL as the destination (after validating 
> the URL is specified in the SP metadata!)
>
> 5) Verify the ProtocolBinding is one of HTTP-Post or Artifact, if not
> it's an error. The spec appears to be silent on how to determine the
> AssertionConsumerService URL. Probably the best action is something
> similar to case 3, scan the ACS endpoints in order [1] and use the first
> match.
>
> [1] See Section 2.2.3 "Complex Type IndexedEndpointType" in the SAML
> Metadata spec. concerning the isDefault flag and index values. Start
> with the default ACS as determined by the rules in Section 2.3.3 and 
> then iterate over the remainder of the ACS's. I would suggest 
> iterating in index order as opposed to metadata order.
>

I don't see any blockers here.  If you want to log a few jiras, we'll 
get to the rest in Keycloak 2.0 (RH SSO 7.1).  We will not be supporting 
Artifact binding unless a critical mass of customers ask for it.  I also 
do not see us supporting ACSI either unless asked for either.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com