funny AssertionConsumerService URL

[Cantor, Scott]

On 2/13/14, 1:22 PM, "Martin Haase" <Martin.Haase at DAASI.de> wrote:

>> Because otherwise you end up with a loop when the ACS and final resource
>> don't share cookies.

>> 
>Dont' get me wrong, I'm not expecting google and mysp sharing cookies ;)
>- and why should they loop back to me?

Google won't of course, but if target is to your own vhost, but not the
one you just invoked, then it will loop or result in a confusing no-op
login that people constantly get thrown by.

- invoke SessionInitiator on host A, target host B
- request login response back to host A
- redirect to target host B
- can't access session (cookie's on A) so you either get no indication
there's a problem (passive case), or something triggers a login request
again, probably by invoking that same SessionInitiator on host A because
there's proabably something hardwired mistakenly to do that
- repeat

Where this can come into play more often is with something doing discovery
through the use of links or by pointing to a DS in some way that's
explicit rather than on the fly using requireSession.

>>There are also settings to limit off-host redirects, but I don't recall
>> when they come into play. They may prevent feeding in a target like
>>that,
>> but I'm not certain.
>
>Given these settings, wouldn't it be sensible to rather put the real ACS
>URL into the Request?

If you limit redirects, and assuming that actually applies here, you might
trigger an immediate error by passing a target it won't accept, but it
will certainly not just generate a useless ACS in the face of that. If the
target *is* acceptable, then it has to be handled in a way that can
eventually result in success, and the only way that can happen is by
computing the ACS from the target (unless handlerURL were set with a
hardcoded scheme/host, it's the use of a relative path there that causes
the schema and host to be derived from the target).

There is no "real" ACS outside of knowing the eventual target resource
because the ACS MUST share the cookie domain of the target (so in the
absence of special set up, that's host equivalence). Invoking a
SessionInitiator doesn't tell it what the ACS is.

(Of course, that's not a SAML thing, that's a consequence of implementing
by setting a cookie only during the ACS processing step and reading it
back from target. Sharing session state some other way like a file or
something is how you avoid ACS proliferation based on vhosting, but I
don't do that.)

-- Scott