<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Your SP is configured to use SAML2 or SAML1 or both depending on the<br>
settings in your shibboleth2.xml file, usually in the SSO element [1].<br>
The order of the SAML2 and SAML1 tokens determines the preference of<br>
which protocol to use.<br></blockquote><div><br></div><div>Thanks Alex. I'm not seeing an issue with protocols, the SP is initiating SAML2 as expected.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
The order of the AssertionConsumerService endpoints used in those<br>
protocols is determined by the ordering of the Binding elements in<br>
protocols.xml.<br>
<br>
I suspect that these files have been edited in your system, as I think<br>
that the default settings are SAML2 > SAML1 and POST > Artifact.<br></blockquote><div><br></div><div>OK, I wasn't previously aware of this file, although I see now that it's documented <a href="https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPConfigurationChanges#NativeSPConfigurationChanges-%3CSessions%3EHandlerContentRadicallySimplified" target="_blank">here</a>.</div><div><br></div><div>However what you're describing doesn't seem to be the case, the relevant section of that file looks like this:</div><div><br></div><div><div><font face="monospace, monospace">    <Service id="SSO"></font></div><div><font face="monospace, monospace">      <Initiator id="SAML2" /></font></div><div><font face="monospace, monospace">      <Binding id="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" path="/SAML2/POST" /></font></div><div><font face="monospace, monospace">      <Binding id="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" path="/SAML2/POST-SimpleSign" /></font></div><div><font face="monospace, monospace">      <Binding id="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" path="/SAML2/Artifact" /></font></div><div><font face="monospace, monospace">      <Binding id="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" path="/SAML2/ECP" /></font></div><div><font face="monospace, monospace">    </Service></font></div></div><div><br></div><div>That's not the ordering I'm seeing in the generated metadata.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
You may also find that your config files use SessionInitiators [2]<br>
instead of the SSO element shorthand. In which case, the order of the<br>
md:AssertionConsumerService endpoints in shibboleth2.xml explicitly<br>
determines the ordering.<br></blockquote><div><br></div><div>It uses <font face="monospace, monospace">SessionInitiators</font>, but it doesn't include explicit <font face="monospace, monospace">md:AssertionConsumerService</font> elements.</div><div><br></div></div>-- <br><div><div dir="ltr">Best regards,<br><br>Robert Lowe<br><a href="http://crepuscular.rmlowe.com/" target="_blank">http://crepuscular.rmlowe.com/</a></div></div>
</div></div>