Native SP + DS redirect target

[Quint Van Deman]

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