How to disable binding urn:oasis:names:tc:SAML:1.0:profiles:browser-post

[hvirring]

Hi,

I'm trying to in integrate with an external IdP. They have a service
for validating metadata, and it's complaining that I'm using an
unsupported binding:

<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:
1.0:profiles:browser-post" Location="https://mydomain/module.php/saml/
sp/saml1-acs.php/default-sp" index="1"/>

I have the following 'default-sp' in authsources.php:

'default-sp' => array(
'saml:SP',
'entityID' => NULL,
'idp' => NULL,
'discoURL' => NULL,
'certificate' => 'mycert.pem',
'privatekey' => 'mycert.key',
),

Any hints on how I disable this specific AssertionConsumerService
binding?

/Jesper

[Tom Scavo]

On Tue, May 17, 2011 at 8:33 AM, hvirring <jes...@hvirring.dk> wrote:
>
> I'm trying to in integrate with an external IdP. They have a service
> for validating metadata, and it's complaining that I'm using an
> unsupported binding:
>
> <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:
> 1.0:profiles:browser-post" Location="https://mydomain/module.php/saml/
> sp/saml1-acs.php/default-sp" index="1"/>

That is a valid <md:AssertionConsumerService> element with a standard
SAML V1.1 Binding attribute value. A conforming IdP shouldn't care if
that element is in metadata, even if it's a SAML V2.0-only IdP.

Tom

[Olav Morken]

As Tom said, that endpoint is valid, and should just be ignored by the
IdP if it doesn't understand it. There is no way to disable SAML 1.1
support in the SP. You can however just download the metadata and
delete the SAML 1.1 endpoints manually before sending the metadata to
the IdP.

(You should also remove "urn:oasis:names:tc:SAML:1.1:protocol" from the
list of supported protocols.)

Regards,
Olav Morken
UNINETT / Feide

[hvirring]

Tom and Olav thanks, that makes perfect sense. It just seemed a little
hackish to manually tweak the metadata ;)

Thanks,
Jesper

[Tom Scavo]

On Wed, May 18, 2011 at 4:15 AM, hvirring <jes...@hvirring.dk> wrote:
> Tom and Olav thanks, that makes perfect sense. It just seemed a little
> hackish to manually tweak the metadata ;)

Well, you shouldn't have to do that, that's the whole point. Any IdP
that requires that kind of metadata is broken. If you tell us who the
IdP is, we'll go beat them up for you ;-) If you don't want to say so
much in public, please drop me a private note since we wouldn't want
to let such an IdP into our federation (seriously).

Tom