<div dir="ltr"><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;font-size:small;color:#073763">Donald,</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;font-size:small;color:#073763"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;font-size:small;color:#073763">I don't know your circumstances, but I would think that the first answer is to push back very hard on the SP to figure out how to accept your IdP as it is. That's probably the second and third answer, too.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;font-size:small;color:#073763"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;font-size:small;color:#073763">If I had to go the route you are trying, though, I would see if I have another SAML provider already running for another reason, and maybe that provider will work for your SP. For instance, we have an AD FS instance for apps that the vendor says they need AD FS, and so we do that to play nice with vendor support. Google and Azure can be configured as SAML providers too, and although we haven't</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;font-size:small;color:#073763"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;font-size:small;color:#073763">Last resort for me would be to run a completely separate SAML provider. Maybe it's something designed to be a proxy, or maybe it's just another Shibboleth IdP instance that may or may not be completely independent from your main Shibb instance. I think it'd be easier for the rest of my team to understand having a separate IdP instance that exists solely to support a special-needs SP, rather than inserting an obscure configuration option. Mainstream Shibboleth configuration is already pretty obscure to the rest of my team.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;font-size:small;color:#073763"></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;font-size:small;color:#073763"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;font-size:small;color:#073763">-Les</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;font-size:small;color:#073763"><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><br><table style="color:rgb(136,136,136);border:none;border-collapse:collapse"><tbody><tr style="height:0pt;border-top:1pt solid rgb(204,204,204)"><td style="border-right:1pt solid rgb(204,204,204);vertical-align:middle;padding:5pt;overflow:hidden"><p dir="ltr" style="line-height:1.2;margin-top:0pt;margin-bottom:0pt"><a href="http://www.carleton.edu/" target="_blank"><span style="font-size:11pt;font-family:Arial;color:rgb(17,85,204);vertical-align:baseline;white-space:pre-wrap"><span style="border:none;display:inline-block;overflow:hidden;width:70px;height:73px"><img height="73" src="https://lh6.googleusercontent.com/QEL1To3Ci_dJA1huaKzfZ0Lf4MaZlAy_f-W3vQjbyzNq_yXq_ZYGv3tuT4dkaZS_bZ5X6fZR4iKzBboZhxbCF5htZFnLNKGqmrzHsVJtsjsy0pfK5w2z0Dlq-EtZcWhv0PxBpWmR" width="70" style="margin-left:0px;margin-top:0px"></span></span></a></p></td><td style="border-left:1pt solid rgb(204,204,204);vertical-align:top;padding:10.8pt;overflow:hidden"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><font color="#dea410" face="Arial"><span style="font-size:14.6667px;white-space:pre-wrap"><b>Les LaCroix '79</b></span></font></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="color:rgb(11,80,145)"><span style="font-size:11pt;font-family:Arial;vertical-align:baseline;white-space:pre-wrap">Strategic Technologist</span></span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="color:rgb(11,80,145)"><span style="font-size:11pt;font-family:Arial;vertical-align:baseline;white-space:pre-wrap">Information Technology Services</span></span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="color:rgb(11,80,145)"><span style="font-size:11pt;font-family:Arial;vertical-align:baseline;white-space:pre-wrap">t: (507) 222-5455</span></span></p></td></tr></tbody></table></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 6, 2020 at 11:49 AM Donald Lohr <<a href="mailto:lohrda@jmu.edu">lohrda@jmu.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
We've the need to use a different certificate for a SP than the
default one in our IdP metadata. As a result, we made a copy of our
IdP metadata and replaced the default cert with this new one and
configured the credentials.xml and relying-party.xml files to use
this.<br>
<br>
Also wanting for this SP to be different and not use our default
entityID value, in that new IdP metadata file, we made a new
entityID value. But the SP is reporting that during a user login,
we are sending over our default entityID.<br>
<br>
Is our goal doable?<br>
<br>
I noticed in the credentials.xml file is:<br>
<br>
<i>p:entityId-ref="entityID" /></i><i><br>
</i><br>
Is the entityID here a variable, thus pulling my default value?<br>
<br>
On the Shibboleth wiki, using the search field, searching for <i>entityId-ref</i>
does not return anything for me.<br>
<br>
<br>
Thanks,<br>
Don<br>
<br>
<pre cols="72">--
D o n a l d L o h r
I n f o r m a t i o n S y s t e m s
J a m e s M a d i s o n U n i v e r s i t y
5 4 0 . 5 6 8 . 3 7 3 0
</pre>
</div>
-- <br>
For Consortium Member technical support, see <a href="https://wiki.shibboleth.net/confluence/x/coFAAg" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/confluence/x/coFAAg</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a><br>
</blockquote></div>