Shibboleth Developers

[Chad La Joie <>]

We're not talking cookies here, but yes, the Handler could write out its 
own cookies.

Yes, I am talking about the HttpSession object.  The IdP may, or may 
not, use additional internal data structures that may or may not be 
"replicated" across a cluster.  However, with some containers, if you 
turn on clustering support they will require the session be replicable 
and some one puts information into the HttpSession object that is nor 
replicable (and that means different things on different containers) the 
container will stop answering requests for that user.

So, to safe-guard the state of the system I'm not letting people touch 
it, by policy.  That said, I'm fully aware that there is nothing 
stopping a developer from doing it anyways.  I can't prevent it (well, I 
could but it'd be pretty rough).

Scott Cantor wrote:
> > Now, that said, I'm not sure why a developer would need to touch the 
> > *IdP* session in order to integrate with another AuthN system.  I can 
> > understand them needing to touch the session from the something like 
> > another SSO system, but that's not what I'm talking about here.  I'm 
> > only referring to the HttpSession maintained by the IdP.
>
> In other words, this restriction doesn't preclude the handler dropping
> cookies on its own, but it can't manipulate any state associated with the
> IdP's cookie?
>
> Also, correct me if I'm wrong, but I think the IdP session you're talking
> about is using its own session mechanism (to make sure clustering is
> handled) and not the servlet session.
>
> -- Scott

--
Chad La Joie             2052-C Harris Bldg
OIS-Middleware           202.687.0124