Announce: Database Backed Storage Service

[Wessel, Keith]

Paul and others,

One more email, and I think we'll be good to go with this excellent addition to the IDP.

We put this in production last night, and everything seems to be going to the database fine with one significant exception: login_id is not being populated. Of course, with out that, the other IDP node can't do much with an existing session.

I know SSO is working within the same node, so it's something with it being written to the database. The session is being created with the correct session_id and session_expire_time columns in the database... just no login_id.

Oddly, I'm now seeing this behavior on our test environment, too, and I know login_id was being populated yesterday when I was dealing with the other objects logging to the database that correctly had null login IDs.

Before I go pointing fingers at our DBA for accidentally changing something in the database when the extra scheduled procedure for deleting rows when the create_date was old enough and there was no session_expire_time, I'm trying to find something else to check here.

Any suggestions why login_id might not be getting populated in the database?

Thanks,
Keith


-----Original Message-----
From: Wessel, Keith 
Sent: Monday, January 06, 2014 4:16 PM
To: 'Shib Users'
Subject: RE: Announce: Database Backed Storage Service

Thanks, Paul. This is what I suspected.

We'll add that to the stored procedure for removing the rows with session_expire_times in the past that don't get cleaned up automatically, and we should be all set.

Keith

-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Paul Hethmon
Sent: Monday, January 06, 2014 4:01 PM
To: Shib Users
Subject: Re: Announce: Database Backed Storage Service

Keith,

I just looked back over the code and I see two different Java objects I
recognize:

1. SessionManagerEntry. This one has an expire time and login ID in the
object and both are stored.
2. SessionID. This one does not have an expire time or login ID value. So
I just save the object itself.

If I get anything else passed to me, I just store it as a blob. In that
case, it won't have a value in the session ID column.

>From memory, I think Shib stores the session under three different index
values. At least if you have the SLO stuff installed (the original from
Hungary).

I'm thinking the algorithm would be to delete those that are blank and the
create date is in the past, longer than your session time setting.
Overall, the worst you can do is cause the user to have to login again.

Paul

On 1/6/14 3:42 PM, "Wessel, Keith" <kwessel at illinois.edu> wrote:

>Paul,
>
>I've been doing some further experimenting with this, and hopefully it'll
>help explain something.
>
>First, seems to do no harm to delete the rows with no session_expire_time
>while the session is still valid. The other IDP node still recognizes the
>session.
>
>As for why they're being created, I still can't grasp that. They have th
>same session_id from the IDP as the other row that has a valid
>session_expire_time. But in addition to missing a session_expire_time,
>they're also missing a login_id. I seem to get two of these odd rows in
>addition to the valid row when a user logs in and creates a new session.
>Then, each time the user hits the IDP while the session is still valid, I
>get another of these odd rows.
>
>Any thoughts?
>
>Keith
>
>
>-----Original Message-----
>From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net]
>On Behalf Of Wessel, Keith
>Sent: Thursday, January 02, 2014 3:14 PM
>To: Shib Users
>Subject: RE: Announce: Database Backed Storage Service
>
>Paul,
>
>We're finally getting ready to put the database stored session code in
>production next week, insufficient load testing held us up longer than
>we'd hoped.
>
>I do need to reserect this old thread once more, though. I ran into one
>little issue. Looking back at our database, I see a hand full of rows
>where the session_expire_time is null. Seems these are perhaps
>insignificant. But before I jump to conclusions, have you seen this? Is
>it a sign of a problem? And if it isn't, can we add to our stored
>procedure that deletes orphaned rows? Right now, it deletes orphaned rows
>for sessions that have expired. Can it also delete orphaned rows where
>the session_expire_time is null? Or do we need to be smarter and delete
>rows where the expire time is null and the create date is significantly
>in the past?
>
>Thanks,
>Keith
>
>
>-----Original Message-----
>From: Wessel, Keith
>Sent: Monday, October 21, 2013 10:15 AM
>To: Shib Users
>Subject: RE: Announce: Database Backed Storage Service
>
>Perfect. Thanks.
>
>Keith
>
>
>-----Original Message-----
>From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net]
>On Behalf Of Paul Hethmon
>Sent: Monday, October 21, 2013 10:06 AM
>To: Shib Users
>Subject: Re: Announce: Database Backed Storage Service
>
>Yep, that's all it does. The table has a column for session expire time,
>so it's just delete any where that time has passed, padding it a bit. So
>something like delete all rows where expire time is more than an hour old.
>
>Paul
>
>On 10/21/13 10:56 AM, "Wessel, Keith" <kwessel at illinois.edu> wrote:
>
>>Does your cleanup job just delete rows with a modify date older than
>>the max IDP session lifetime or something along those lines?
>>
>
>--
>To unsubscribe from this list send an email to
>users-unsubscribe at shibboleth.net
>--
>To unsubscribe from this list send an email to
>users-unsubscribe at shibboleth.net
>--
>To unsubscribe from this list send an email to
>users-unsubscribe at shibboleth.net

--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net