Ordering of ACS endpoints
alex.stuart at ed.ac.uk
Wed Dec 9 07:35:29 EST 2015
On 09/12/2015 12:07, Peter Schober wrote:
> * Robert Lowe <robertmlowe at rmlowe.com> [2015-12-09 12:58]:
>>> See also
>> Thanks Rod. That looks like it might explain the behavior, although I do
>> not understand what is meant by “sorted by location.”
> The Shibboleth SP software partially encodes the protocol binding into
> the URL of the AssertionConsumerService/@Location XML attribute, e.g.
> <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://sp.example.org/Shibboleth.sso/SAML2/POST" index="1"/>
> <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://sp.example.org/Shibboleth.sso/SAML2/Artifact" index="2"/>
> If you sorted that by Location then Artifact would come first (as
> would SAML before SAML2, I would imagine).
> None of these problems exist if you generate SP metadata using the
> provided `metagen.sh` script (`shib-metagen` on Debian and friends)
> from the SP distribution.
On a CentOS 6.x machine, I can control the order that the
AssertionConsumerService endpoints are displayed from
https://hostname/Shibboleth.sso/Metadata by editing protocols.xml. They
don't get sorted by location. So I don't understand the jira issue. Does
it just affect a specific platform?
Team Leader - Federated Access Management
EDINA, University of Edinburgh
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
More information about the users