summaryrefslogtreecommitdiffstats
path: root/ipsilon/info
diff options
context:
space:
mode:
authorJohn Dennis <jdennis@redhat.com>2015-08-27 16:34:40 -0400
committerJohn Dennis <jdennis@redhat.com>2015-08-27 17:18:02 -0400
commitb6d4eed36301dc0f0f3058271a3f26f115d6f173 (patch)
tree29f3e4234adc44cd839d08d46e5f4203f375bd84 /ipsilon/info
parentf1efb10af288c438fa034e7beb62e14b8417056f (diff)
downloadipsilon-client-paos.tar.gz
ipsilon-client-paos.tar.xz
ipsilon-client-paos.zip
Define PAOS AssertionConsumerService in ipsilon-client-installclient-paos
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>
Diffstat (limited to 'ipsilon/info')
0 files changed, 0 insertions, 0 deletions