Shibboleth Developers

["Scott Cantor" <>]

I dug back in the list and reread some of the earlier exchanges about the
design and how the cookies would fit together, and I guess I'm still trying
to understand the use case.

In a typical situation, why would an application session need to spread
itself across multiple vhosts? And if it did, why would it be a problem to
just do SAML and set up concurrent sessions given that the WAYF/etc. logic
would be bypassed and usually the login would be invisible?

I take it the CAS/etc. issue fits in here somewhere, but I guess I'm not
seeing the connection to that.

I suppose an extra redirect isn't the end of the world, but I'm just
wondering why it's so important to do. It seems like a really uncommon case,
unless you're trying to proxy a session on one box on to other servers, in
which case you can't relay the session easily anyway (in effect, you're
reinventing an SSO protocol again).

For clarification, I was just proposing that the target parameter would be a
session key that was generated and stored before the initial redirect away
and then recoverable into the original target value (and whatever other SAML
request state) by the assertion consumer service. So there's shared data
internally between the filter and the "SHIRE", but they already do.

Also, I'm not sure how that affects the possibility of embedding an
intra-server SSO flow (if you will) from one vhost to another, since that
particular flow would be proprietary to our implementation and would have to
share state internally anyway. Whatever information was represented by the
target value while it's in use would be available to any code we make part
of the implementation.

-- Scott