SAML message intended destination endpoint did not match the recipient endpoint

[Cantor, Scott]

> - Remove Shibboleth IDP V2 from the Registry Application (This application
> needs keep the same Cname)

I would bet significant money that the cost of changing SAML endpoints (given all the non-Shibboleth SPs you'll have to fight with) is orders of magnitude higher than whatever impact the change would be to anything else.

> I wish I had the luxury of using cname’s to manage the switch over but i don’t
> in this situation, it was a mistake to integrate the systems but thats another
> story.. Im looking at a workaround with Apache / Reverse Proxy

I belive you will find that practically impossible, and not particularly helpful anyway.

At minimum, you will have to change code or make unsupported/undocumented changes to policy rules in the IdP to bypass the destination checks, or you'd have to get the new IdP to be operating at both the old and new names in a virtual sense. It would have to believe it's the old name to avoid breaking on requests to the old name. It's a mess.

You're better off just giving up on SSO between them IMHO and running both in parallel.

You should not change the entityID in any case, BTW. It doesn't matter what's in it, it's a name, not a location. It should never change unless you sell your domain.

-- Scott