[FORGED] SAML message intended destination endpoint did not match the recipient endpoint

Reid Watson reid.watson at auckland.ac.nz
Sun Jul 3 17:06:08 EDT 2016


> On 4/07/2016, at 5:15 am, Cantor, Scott <cantor.2 at osu.edu> wrote:
> 
>> - Old IDP v2 system (not an option to upgrade to IDP3)
> 
> Why? Just saying that doesn't really mean anything.
> 

About 5 years ago the company integrated shibboleth IDP v2 into a user registry application (they are bundled together at a code level) — Im working on the project to decouple the systems

- Remove Shibboleth IDP V2 from the Registry Application (This application needs keep the same Cname)
- Install and configure IDP v3 out of the box with a new Host and Cname 
- Integrate the registry application into Shibboleth IDP V3
- Figure out how to manage external SP still pointing to the decoupled Register Application 


>> - On Go live I wouldn’t be able to communicate with 100 plus vendors to
>> update the Entity ID and AuthnRequest URL to point to the new IDP3
> 
> Which is why you do not do that. Do not change your entityID, and do not change the server name and endpoints or key.
> 
> If you want to change servers, that's absolutely fine (I went from V1 to V2 that way). Test it all out, and then flip the switch in DNS. If this is all SAML 2, or mostly, then you can test everything ahead of time very easily with a simple /etc/hosts change on your client.
> 

- The problem with Cname’s is detailed above  


>> - Has anyone been in a similar situation and could advise if my solution is
>> viable
> 
> It is not the right solution.

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



> -- Scott
> 
> -- 
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net



More information about the users mailing list