Native SP + DS redirect target
Quint Van Deman
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)
qvan...@emergent360.com
Visit us at www.emergent360.com
--
To unsubscribe from this list send an email to users-un...@shibboleth.net
Cantor, Scott
>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
Rod Widdowson
shortly)
Rod
> -----Original Message-----
> From: users-...@shibboleth.net [mailto:users-...@shibboleth.net] On Behalf Of Quint Van Deman
> Sent: 26 March 2012 17:08
> To: us...@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 <qvan...@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
Quint Van Deman
I am using 1.2.0. Let me know if there's an alternative (even dev)
version I should pull down, I'm happy to help test or provide any data
that might be useful.
Thanks,
-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)
qvan...@emergent360.com
Visit us at www.emergent360.com