<div dir="ltr">We essentially did that kind of transition.<div><br></div><div>We setup a new IdP on the 3.x branch. New hostname, new certificates, new URL bindings, etc; but responding as the same entityID as the old IdP on the 2.x version.</div><div><br></div><div>Then we went one-by-one through each SP and federation having them update their metadata to the new server. SPs with the old metadata continued to run just fine. SPs with the new metadata that hit operational issues were rolled back to the old IdP while the issue(s) were corrected. We ran both in parallel while we went through the whole list.</div><div><br></div><div>It took a while, but we got everyone moved over. And whilst doing that, shed all the old SAML 1.1 bindings and backchannel communications. Even when it was a bit painful for the SP.</div><div><br></div><div>Lessons learned:</div><div><br></div><div>1) There are **A** **LOT** of SPs that demand SHA1. They may advertise in their metadata support for almost a dozen accepted signature algorithms. Their metadata is lying. When asked to correct their metadata, they responded with "we'll have to engage our developers." It always turned out easier to override them in relying-party.</div><div><br></div><div>2) The favorite format for NameIDs is, by far, "unspecified." And no, you have to send it over as "unspecified." But they are very specific in the value they want in there. That's fun.</div><div><br></div><div>3) The various federations that do inter-federation consumption of metadata from InCommon (SWAMID, UK Access Fed, ...) are painfully slow in updating. You would think 48 hours after publishing in InCommon, the others would update. Okay, maybe 96 hours is more reasonable. Okay, it's been a week, what they heck?</div><div><br></div><div>4) There's a couple of "high profile" SPs in InCommon that don't automatically update the metadata. You have to open a case with their service desk and sit on your hands for a week hoping for a response. You discover who those are by tailing the logs on the old IDP after updating InCommon and wondering what went wrong.</div><div><br></div><div>Hopefully, what I described is more helpful than off-putting.</div><div><br></div><div>--</div><div>Jeremy</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 1, 2016 at 11:03 PM, Reid Watson <span dir="ltr"><<a href="mailto:reid.watson@auckland.ac.nz" target="_blank">reid.watson@auckland.ac.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Experts,<br>
<br>
Im wondering if I could get some advice and if I’m going down the wrong path / wiil my idea work<br>
<br>
1. Situation<br>
<br>
- Old IDP v2 system (not an option to upgrade to IDP3)<br>
- We currently have 122 plus external cloud services currently integrated into our IDP<br>
<br>
Current IDP3 Version<br>
- Jetty 9.3.2.v20150730<br>
- shibboleth-identity-provider-3.2.1<br>
<br>
2. Problem<br>
<br>
- 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<br>
<br>
 3. My Idea - Configure an Apache Reverse Proxy from IDP2 to IDP3 for the SAML request<br>
<br>
No I have already setup the Reverse Proxy but I’m returned this error IDP3 server<br>
<br>
2016-07-02 14:38:26,955 - ERROR [org.opensaml.saml.common.binding.security.impl.ReceivedEndpointSecurityHandler:200] - Message Handler:  SAML message intended destination endpoint '<a href="https://iam.dev.auckland.ac.nz/profile/SAML2/Redirect/SSO" rel="noreferrer" target="_blank">https://iam.dev.auckland.ac.nz/profile/SAML2/Redirect/SSO</a>' did not match the recipient endpoint '<a href="https://iam.dev.auckland.ac.nz/idp/profile/SAML2/Redirect/SSO" rel="noreferrer" target="_blank">https://iam.dev.auckland.ac.nz/idp/profile/SAML2/Redirect/SSO</a>'<br>
2016-07-02 14:38:26,957 - WARN [net.shibboleth.idp.profile.impl.WebFlowMessageHandlerAdaptor:182] - Profile Action WebFlowMessageHandlerAdaptor: Exception handling message<br>
org.opensaml.messaging.handler.MessageHandlerException: SAML message failed received endpoint check<br>
        at org.opensaml.saml.common.binding.security.impl.ReceivedEndpointSecurityHandler.checkEndpointURI(ReceivedEndpointSecurityHandler.java:202)<br>
2016-07-02 14:38:26,959 - WARN [org.opensaml.profile.action.impl.LogEvent:76] - An error event occurred while processing the request: MessageAuthenticationError<br>
<br>
 - Looking at the error “destination endpoint '<a href="https://iam.dev.auckland.ac.nz/profile/SAML2/Redirect/SSO" rel="noreferrer" target="_blank">https://iam.dev.auckland.ac.nz/profile/SAML2/Redirect/SSO</a>' did not match the recipient endpoint '<a href="https://iam.dev.auckland.ac.nz/idp/profile/SAML2/Redirect/SSO'" rel="noreferrer" target="_blank">https://iam.dev.auckland.ac.nz/idp/profile/SAML2/Redirect/SSO'</a>” the path is causing, so the server itself dosen’t match the urls being given in the SAML messages<br>
<br>
IDP2 Path: /profile/SAML2/Redirect/SSO<br>
IDP3 Path : /idp/profile/SAML2/Redirect/SSO<br>
<br>
Questions<br>
<br>
- Has anyone been in a similar situation and could advise if my solution is viable<br>
- Has anyone updated IDP3 path to remove “idp”, is this best solution to investigate ?<br>
- Will I run into more issue using a reverse proxy ?<br>
<br>
Any tips or advice would be great<br>
<br>
Cheers<br>
<span class="HOEnZb"><font color="#888888"><br>
Reid<br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a></font></span></blockquote></div><br></div>