Define PAOS AssertionConsumerService in ipsilon-client-install
authorJohn Dennis <jdennis@redhat.com>
Thu, 27 Aug 2015 20:34:40 +0000 (16:34 -0400)
committerPatrick Uiterwijk <puiterwijk@redhat.com>
Wed, 2 Sep 2015 01:26:54 +0000 (03:26 +0200)
commit085d5b1a893b59af797dc530a5abdac1df118647
treef9eeced0b8b42a850a7465d18809833da907c27f
parent9470d68a7e673a73c6997c6ab18910f2b1a27709
Define PAOS AssertionConsumerService in ipsilon-client-install

A SAML SP will not be able to perform ECP unless a
AssertionConsumerService for the PAOS binding has been defined in it's
metadata. The PAOS AssertionConsumerService participates in the ECP
protocol exchange, specifically it's where the ECP client sends the
IdP Assertion.

If lasso starts to engage in an ECP transaction by trying to generate a
Samlp:AuthnRequest and no PAOS AssertionConsumerService is defined in
the SP metadata it will fail with a unknown provider error.

Note, AssertionConsumerService elements are indexed endpoints, there
may be one per protocol binding. Now that there is more than 1
AssertionConsumerService we set the isDefault flag to True on the
existing post response at index 0. This isn't strictly necessary
because the spec says if the default flag isn't set on any
AssertionConsumerService endpoint then the first one is selected, but
it's good practice anyway.

FWIW, if mod_auth_mellon is not configured with metadata then
mod_auth_mellon will generate it's own metadata which includes the
PAOS AssertionConsumerService. However in ipsilon-client we generate
the SP metadata and were failing to add the PAOS
AssertionConsumerService, something mellon would have done
automatically for us. This is why this bug was only first seen using
ipsilon-client-install.

Ticket: 162
Signed-off-by: John Dennis <jdennis@redhat.com>
Reviewed-by: Patrick Uiterwijk <puiterwijk@redhat.com>
ipsilon/install/ipsilon-client-install
ipsilon/tools/saml2metadata.py