<div dir="ltr">Kevin,<div><br></div><div class="gmail_extra"><div class="gmail_quote">On Thu, Oct 22, 2015 at 10:42 AM, Kevin Foote <span dir="ltr"><<a href="mailto:kpfoote@uoregon.edu" target="_blank">kpfoote@uoregon.edu</a>></span> wrote:<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"><span class=""><br>
<br>
> On Oct 22, 2015, at 9:30 AM, Corey Puffalt <<a href="mailto:cplists@gmail.com">cplists@gmail.com</a>> wrote:<br>
><br>
> which helped me understand why a separate self-signed certificate is being used for the back-channel endpoints.<br>
><br>
> For testing purposes I hacked the metadata and simply changed the endpoints referencing 8443 to 443. Should this work?  (I know it's not advisable in a production system, but I'm just trying to validate a basic SP configuration).  I'm now seeing errors saying "Inbound message issuer was not authenticated." but I'm not sure if this is because I changed the port or if there's some other issue related to my SP configuration causing the issue.<br>
<br>
</span>Cory,<br>
<br>
Why are you trying to set up backchannel communication on a newer SP?<br>
<br>
You should not be using those endpoints (backchannel) unless you are trying to use SAML1 (on purpose, for some reason) and or doing AttributeResolution.<br></blockquote><div><br></div><div>I'm not purposely trying to use backchannel communication.  My SP (OpenAM in this case) is configured to use frontchannel communication with HTTP-POST binding but the SP is performing AttributeResolution over a backchannel and I don't know how to avoid that?</div><div><br></div><div>Corey</div></div></div></div>