SP unable to decrypt assertion

[Mohamed Lrhazi]

Thanks a lot Peter. That will help figure out where to look further...

On Tue, Jan 16, 2018 at 12:44 PM, Peter Schober <peter.schober at univie.ac.at>
wrote:

> * Mohamed Lrhazi <lrhazi at cua.edu> [2018-01-16 18:31]:
> > An SP asked us to update their metadata and add new one for when
> > they will switch dns names...
>
> If that also involves changing the entityID (as I understand you're
> saying):
> Short of selling the domain from the old entityID there's no reason to
> ever do that, of course.
>
> > I made the updates in the metadata [...]
> > With this config, the SP is unable to decrypt the messages... but if I
> > remove the cascadecms.com line, they can!
>
> If I understood you correctly they're using new/separate entityIDs. So
> in effect they're completely separate, new SPs for your IDP.
> Then you don't modify any of the existing ones, and simply add
> metadata (and filter rules) for the new ones. That's your "migration".
>
> Now if the new ones "don't work" (e.g. as in the failure you're
> getting the metadata you have on record is "wrong" -- "wrong" as in:
> doesn't match their SP configuration. Obviously (?) your IDP encrypted
> data to their SP with a key the SP doesn't have available.
> So the SP could be misconfigured, or you could have messed up the
> metadata describing their SP(s), or both.
>
> If there are no new entityIDs involved and this is all about changing
> the existing metadata then there'd be no reason for you to touch
> metadata-providers.xml? If all they're doing is adding (ignore
> removing anything until later) new protocol endpoints to take care of
> new/different vhosts/host names, that's what you'll need to do: Add
> endpoints for any DNS names the service expects to be sent SAML
> protocol messages you don't have in there yet.
> If they're also at the same time adding keys you'll need to add those
> too. Now if there's only a single entityID spread across more than one
> system on their side, and not all of their systems share the same key
> pair for SAML purposes, this cannot work, I think. I.e., the IDP
> wouldn't know which key to pick based solely on the protocol endpoint.
>
> Sorry if none of this helps, I guess you'll need to be more explicit
> about the status quo and the chnages, then.
>
> -peter
> --
> For Consortium Member technical support, see https://wiki.shibboleth.net/
> confluence/x/coFAAg
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20180116/4ad87e25/attachment.html>