funny AssertionConsumerService URL

[Martin Haase]

Thank you, Scott, highly appreciated.

Am 13.02.2014 19:41, schrieb 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
>
>
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net

-- 
Dr. Martin Haase, Solutions Engineer

DAASI International GmbH        
Europaplatz 3                   
D-72072 Tübingen                
Germany                    

phone: +49 7071 407109-6
fax:   +49 7071 407109-9  
email: martin.haase at daasi.de
web:   www.daasi.de

Sitz der Gesellschaft: Tübingen
Registergericht: Amtsgericht Stuttgart, HRB 382175
Geschäftsleitung: Peter Gietz


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2345 bytes
Desc: S/MIME Cryptographic Signature
Url : http://shibboleth.net/pipermail/users/attachments/20140214/ca1670c5/attachment.bin