<div dir="ltr">Thanks a lot Peter. That will help figure out where to look further... </div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 16, 2018 at 12:44 PM, Peter Schober <span dir="ltr"><<a href="mailto:peter.schober@univie.ac.at" target="_blank">peter.schober@univie.ac.at</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">* Mohamed Lrhazi <<a href="mailto:lrhazi@cua.edu">lrhazi@cua.edu</a>> [2018-01-16 18:31]:<br>
<span class="">> An SP asked us to update their metadata and add new one for when<br>
> they will switch dns names...<br>
<br>
</span>If that also involves changing the entityID (as I understand you're saying):<br>
Short of selling the domain from the old entityID there's no reason to<br>
ever do that, of course.<br>
<br>
> I made the updates in the metadata [...]<br>
<span class="">> With this config, the SP is unable to decrypt the messages... but if I<br>
> remove the <a href="http://cascadecms.com" rel="noreferrer" target="_blank">cascadecms.com</a> line, they can!<br>
<br>
</span>If I understood you correctly they're using new/separate entityIDs. So<br>
in effect they're completely separate, new SPs for your IDP.<br>
Then you don't modify any of the existing ones, and simply add<br>
metadata (and filter rules) for the new ones. That's your "migration".<br>
<br>
Now if the new ones "don't work" (e.g. as in the failure you're<br>
getting the metadata you have on record is "wrong" -- "wrong" as in:<br>
doesn't match their SP configuration. Obviously (?) your IDP encrypted<br>
data to their SP with a key the SP doesn't have available.<br>
So the SP could be misconfigured, or you could have messed up the<br>
metadata describing their SP(s), or both.<br>
<br>
If there are no new entityIDs involved and this is all about changing<br>
the existing metadata then there'd be no reason for you to touch<br>
metadata-providers.xml? If all they're doing is adding (ignore<br>
removing anything until later) new protocol endpoints to take care of<br>
new/different vhosts/host names, that's what you'll need to do: Add<br>
endpoints for any DNS names the service expects to be sent SAML<br>
protocol messages you don't have in there yet.<br>
If they're also at the same time adding keys you'll need to add those<br>
too. Now if there's only a single entityID spread across more than one<br>
system on their side, and not all of their systems share the same key<br>
pair for SAML purposes, this cannot work, I think. I.e., the IDP<br>
wouldn't know which key to pick based solely on the protocol endpoint.<br>
<br>
Sorry if none of this helps, I guess you'll need to be more explicit<br>
about the status quo and the chnages, then.<br>
<span class="HOEnZb"><font color="#888888"><br>
-peter<br>
--<br>
For Consortium Member technical support, see <a href="https://wiki.shibboleth.net/confluence/x/coFAAg" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/<wbr>confluence/x/coFAAg</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.<wbr>net</a><br>
</font></span></blockquote></div><br></div>