SAML message intended destination endpoint did not match the recipient endpoint

[Jeremy Smith]

We essentially did that kind of transition.

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.

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.

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.

Lessons learned:

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.

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.

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?

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.

Hopefully, what I described is more helpful than off-putting.

--
Jeremy

On Fri, Jul 1, 2016 at 11:03 PM, Reid Watson <reid.watson at auckland.ac.nz>
wrote:

> Hi Experts,
>
> Im wondering if I could get some advice and if I’m going down the wrong
> path / wiil my idea work
>
> 1. Situation
>
> - Old IDP v2 system (not an option to upgrade to IDP3)
> - We currently have 122 plus external cloud services currently integrated
> into our IDP
>
> Current IDP3 Version
> - Jetty 9.3.2.v20150730
> - shibboleth-identity-provider-3.2.1
>
> 2. Problem
>
> - 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
>
>  3. My Idea - Configure an Apache Reverse Proxy from IDP2 to IDP3 for the
> SAML request
>
> No I have already setup the Reverse Proxy but I’m returned this error IDP3
> server
>
> 2016-07-02 14:38:26,955 - ERROR
> [org.opensaml.saml.common.binding.security.impl.ReceivedEndpointSecurityHandler:200]
> - Message Handler:  SAML message intended destination endpoint '
> https://iam.dev.auckland.ac.nz/profile/SAML2/Redirect/SSO' did not match
> the recipient endpoint '
> https://iam.dev.auckland.ac.nz/idp/profile/SAML2/Redirect/SSO'
> 2016-07-02 14:38:26,957 - WARN
> [net.shibboleth.idp.profile.impl.WebFlowMessageHandlerAdaptor:182] -
> Profile Action WebFlowMessageHandlerAdaptor: Exception handling message
> org.opensaml.messaging.handler.MessageHandlerException: SAML message
> failed received endpoint check
>         at
> org.opensaml.saml.common.binding.security.impl.ReceivedEndpointSecurityHandler.checkEndpointURI(ReceivedEndpointSecurityHandler.java:202)
> 2016-07-02 14:38:26,959 - WARN
> [org.opensaml.profile.action.impl.LogEvent:76] - An error event occurred
> while processing the request: MessageAuthenticationError
>
>  - Looking at the error “destination endpoint '
> https://iam.dev.auckland.ac.nz/profile/SAML2/Redirect/SSO' did not match
> the recipient endpoint '
> https://iam.dev.auckland.ac.nz/idp/profile/SAML2/Redirect/SSO'” the path
> is causing, so the server itself dosen’t match the urls being given in the
> SAML messages
>
> IDP2 Path: /profile/SAML2/Redirect/SSO
> IDP3 Path : /idp/profile/SAML2/Redirect/SSO
>
> Questions
>
> - Has anyone been in a similar situation and could advise if my solution
> is viable
> - Has anyone updated IDP3 path to remove “idp”, is this best solution to
> investigate ?
> - Will I run into more issue using a reverse proxy ?
>
> Any tips or advice would be great
>
> Cheers
>
> Reid
>
> --
> 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/20160702/22ba3350/attachment.html>