Shibboleth Developers

[Chad La Joie <>]

There are a couple reasons.

First, and most importantly, in a clustered environment where this 
information must be replicated from node to node the application needs 
to be careful what goes into the session.  If the authentication handler 
is stuffing data into the session it might break violate the 
restrictions of your app server of choice.

Second, while I definitely understand the need for more data to be 
available to components deeper within the IdP, I don't want people 
thinking the session is the way to do that.  The IdP may write over data 
a handler placed there, at some point it may clear the whole session for 
some reason, etc.  Basically I don't want anything else but the internal 
IdP code relying on that object.

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.

Velpi wrote:
> > http://svn.middleware.georgetown.edu/view/trunk/src/edu/internet2/middleware/shibboleth/idp/authn/AuthenticationHandler.java?root=java-idp&view=markup 
>
>
> > Comments/Questions?
>
> ----
> AuthentcationHandlers <strong>MUST NOT</strong> change or add any data 
> to the user's {@link HttpSession} that persists past the process of 
> authenticating the user, that is no additional session data may be added 
> and no existing session data may be changed when the handler redirects 
> back to the return location.
> ----
>
> This may a problem in some cases where deep integration is required. Is 
> there a special reason why modifying the session is prohibited or is it 
> just a precaution? ("you have been warned"?)
>
>
> -- Velpi

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