<div dir="ltr">I see what you mean. Is it assumed that the self-signed certificate on the attribute authority endpoints matches the one in the IDP's metadata? Or likewise should they be different for security reasons?<br>
</div><div class="gmail_extra"><br clear="all"><div><font face="tahoma, sans-serif"><div><font face="tahoma, sans-serif"><br></font></div>Joshua Riffle</font><div><font face="tahoma, sans-serif">Software Engineer<br></font><div>
<font color="#CC0000" face="tahoma, sans-serif"><b>Azusa Pacific University</b></font></div></div></div>
<br><br><div class="gmail_quote">On Fri, Jul 12, 2013 at 7:50 AM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">> I see this does seem to be a trend with other Identity Providers in InCommon<br>
> federation metadata but I haven't seen a documented technical reason why<br>
> you shouldn't just use the same port and certificate for all of your endpoints?<br>
> So my questions is simply -- why? I'd like to understand this better.<br>
<br>
</div>Two primary ones:<br>
<br>
- The choice to stick with mutual TLS from the earliest days to authenticate the client. There are a variety of problems trying to do client TLS on a subset of a vhost.<br>
<br>
- Using non-self-signed certs for SAML exchanges creates a requirement for constant cert rollover or for the use of PKIX at runtime, which we abandoned many years ago in probably the single smartest decision I've ever made (after trying to support it, which was the dumbest).<br>
<br>
-- Scott<br>
<br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
</blockquote></div><br></div>