Native SP + DS redirect target

[Quint Van Deman]

Hi Rod--

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)
qvandeman at emergent360.com
Visit us at www.emergent360.com



On Mon, Mar 26, 2012 at 12:37 PM, Rod Widdowson
<rdw at steadingsoftware.com> wrote:
> 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
>
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net