session storage

Russell Beall beall at usc.edu
Wed Feb 24 20:41:06 EST 2016


Thanks Scott.  Hopefully I can just get to v3 poste haste. :-)  In the meantime I’ll just have to hack this in some way or another to get by.

Regards,
Russ.

> On Feb 24, 2016, at 4:37 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> 
>> I feel like I should have long ago known the answer to this question given all
>> the custom shib plugin work I’ve done.  Somehow I have missed the right
>> way to store an attribute on a user session and have run into trouble because
>> I stored the information in the tomcat session object which isn’t being
>> clustered.  So the data is being forgotten about when a user switches nodes
>> or the tomcat session times out.  I’m still in V2-land by the way.
> 
> V2 doesn't make any use of the container session for anything as far as I'm aware.
> 
>> I’m storing a timestamp on the last successful 2FA event so it can be
>> selectively reused, and I’d like to store it in the
>> "edu.internet2.middleware.shibboleth.idp.session.Session” object, but that
>> doesn’t seem to have a way to store properties.  Is there a storage service
>> for such data?
> 
> I don't think so. I don't think there's any particularly "blessed" way to do anything like that. I'm not sure the V2 session really stores much of anything because it relied on TerraCotta to just replicate the Java objects. There's no explicit storage happening like there is in V3.
> 
>> Should I just be looking at a DataSealer-enabled cookie instead for this?
> 
> Well, I guess so, assuming you're ok just doing what I did and throwing out the entire V2 session and login layer. I don't really know how to use it, because I never did.
> 
>> In a related question, if I match the timestamp of the 2FA event and link it to
>> the ID of the edu.internet2.middleware.shibboleth.idp.session.Session, will
>> that ID stay consistent through the duration of the IdP session for the user,
>> which we currently have set to last for 8 hours?
> 
> I assume so.
> 
> -- Scott
> 
> -- 
> To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net



More information about the dev mailing list