Native SP + DS redirect target

[Rod Widdowson]

Which version of the CDS are you running?  There is an issue with version 1.2.0 which can affect this (and a fix will be released
shortly)

Rod

> -----Original Message-----
> From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Quint Van Deman
> Sent: 26 March 2012 17:08
> To: users at shibboleth.net
> Subject: Re: Native SP + DS redirect target
> 
> Thanks Scott, I appreciate the explanation.
> A couple of quick follow up questions to help me track down the issue:
> 
> Should I expect the "target" and the "RelayState" to match?
> I'm looking at tcpdump, they do not:
> target=ss:mem:61b4c92f5d5f40ce49fe4f3695d1bf4e06240377
> RelayState=ss:mem:ded775541f4f3af5e0dbddbfce1dabc0
> 
> I do see where the RelayState reference persists all the way through to where:
> /SAML2/Redirect/SSO -> contains RelayState as a hidden form field.
> /SAML2/POST -> contains RelayState as a POST parameter
> 
> So it seems as though some version of the RelayState makes it through, but how can I inspect the
> contents of those references to see where things might be going south?
> 
> Perhaps also of note:
> 1. If I switch from SAMLDS to WAYF, the issue does not occur (however all attributes are lost).
> 2. Both the IdP and the DS are running in the same container, should that matter?
> 3. I've specified /WAYF as the path for the discoveryURL in the SSO tag of shibboleth2.xml, this seems
> to be in line with the conf, and I see mention that the prototcol is dynamically determined, but
> should this be set to something specific for SAMLDS? I tried /DS but saw the same results.
> 
> Thanks again to anyone who might have any suggestions.
> 
> -Quint
> 
> >> The only trick is that the post authentication redirection (since
> >> introducing the DS) is dropping the path portion of the url.
> >> The browser gets forwarded to https://sso1.private.net/ instead of
> >> https://sso1.private.net/secure/index.php.
> >> If I manually append the path, SSO works fine, but I'm a bit stumped
> >> as to where the redirect target is getting mangled.
> >
> > Track the target parameter and then the RelayState. Assuming default
> > settings, the relay state is tracked in memory with no cookies
> > involved, so that eliminates various potential problems and is a
> > simple matter of tracking that the relay state is properly preserved
> > and sent to the IdP and back.
> 
> > It's not chopping the path, either, it's just losing the state. Then
> > it lands you at homeURL or in its absence the vhost root. If you set
> > homeURL explicitly, that will change where it defaults to.
> 
> > -- Scott
> 
> >On Wed, Mar 21, 2012 at 6:03 PM, Quint Van Deman <qvandeman at emergent360.com> wrote:
> >> Hello--
> >>
> >> I've been constructing a proof of concept implementation over the
> >> recent days, and I'm seeing some odd behavior that I'd like to
> >> consult the list on.
> >> My original setup was a simple native SP + IdP, and everything was
> >> working great.
> >> I hit my 'app' which was just a simple php page, got forwarded to the
> >> IdP for auth, and then redirected back to the original URL
> >> (https://sso1.private.net/secure/index.php).
> >>
> >> Today I went about integrating in a the discovery service in advance
> >> of bringing a 2nd IdP into the equation.
> >> Everything largely works, I hit the app, get forwarded to WAYF
> >> selector, choose my IdP, and authenticate.
> >> The only trick is that the post authentication redirection (since
> >> introducing the DS) is dropping the path portion of the url.
> >> The browser gets forwarded to https://sso1.private.net/ instead of
> >> https://sso1.private.net/secure/index.php.
> >> If I manually append the path, SSO works fine, but I'm a bit stumped
> >> as to where the redirect target is getting mangled.
> >>
> >> Any advice?
> >>
> >> Thanks in advance,
> >>
> >> -Quint
> >>
> >> ---------------------------------------------------------------------
> >> ------------------------------- Quint Van Deman | Director, Open
> >> Source and Cloud Solutions | Emergent, LLC Red Hat Certified
> >> Architect, Engineer, and Data Center Specialist
> >> 1439 N. Great Neck Rd. | Virginia Beach, VA 23454
> >> 757-416-6535(O) | 757-287-1738 (M) | 757-412-1060 (F)
> >> qvandeman at emergent360.com Visit us at www.emergent360.com
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net