Shibboleth Developers

["David L. Wasley" <>]

Chad,  A few observations/questions.

Why would you force a logout with a third party application?  Do you 
know that JSTOR wants users logged out after some period?  What 
period?  Why not let the app handle that case?  I would assume that 
different apps would want different timeouts depending on a number of 
possible variables.

The origin might provide advice, for example that "we believe user 
sessions with you should be timed out after 20 minutes of inactivity" 
but I think that's a fringe idea.

It seems to me the real use case is when the user explicitly wants to 
log out of all their sessions.  In that case, they need some way to 
tell the HS/logout daemon "please tell all apps I've gone to to kill 
my session."  Of course, it might not know all the apps you've gone 
to (depends on how it maintains state) and a user might have sessions 
via more than one origin.
-----
At 9:55 AM -0600 on 7/2/04, Chad La Joie wrote:

> Throughout the week here at CAMP I've heard comments and questions 
> about how one "logs out" of Shib, if such an action would also log 
> you out of applications you logged into though Shib, if there are 
> session timeouts, and other session management related topics. 
> Daniel, the developer of our WebISO, and I were talking about this 
> and we'd like to propose a means for accommodating these sorts of 
> functions.  Our proposal is based on what our current WebISO does 
> already to meet these requirements here at Virginia Tech.  I looked 
> through this years list archives to see if anyone was talking about 
> this and I didn't see anything so I wanted to propose the results of 
> mine and Dan's conversations.  If I missed a previous discussion 
> about this I'm sorry.
>
> So here is the new flow we propose (please forgive my mixed 
> vernacular of old and new Shib terms that will follow).  User comes 
> from a resource to the Handle Service, either via WAYF or a direct 
> link, and they authenticate in some fashion, end up with a handle, 
> and get sent back to the resource.

This could include the advice about an appropriate timeout.

> So, same model as exist now.  The only difference here is what the 
> handle service stores, instead of just making a handle to user 
> mapping that the AA will user later it stores a handle/user/resource 
> mapping.
>
> Once the user gets to the resource the thing formally know as the 
> SHIRE takes the handle and does its thing.  At this point an out of 
> band call could be made back to the Handle Service to verify that 
> the handle is indeed valid (which could mean something like checking 
> to make sure an expiration timeout hasn't passed).

If the user has just been redirected there by the HS, then the 
timeout probably has not expired since the handle has just been made.

> This might add just a bit more assurance to this exchange though it 
> may not be necessary.
>
> Things progress as they do now as the user moves from one 
> Shib-enabled app to another with each contact to the Handle Service 
> being recorded in the format noted above.  Now once the user decides 
> to log out they can click on some link that indicates they wish to 
> log out of everything.

The implication here is that they would be redirected back to the HS. 
But the SHAR doesn't know where the HS is (the WAYF does) and it 
would mean placing dynamic links in pages based on the assumed URL of 
the HS.

> At this point the Handle Service would send to each SHIRE a "log 
> handle X out" message.  To do this it would need to resolve the 
> resource id to a SHIRE URL which could be done in a whole lot of 
> ways, both dynamic and static.  The SHIRE now would need one 
> additional function, the ability to accept a "log handle out" 
> request.  This request could be done either as an out of band 
> message from the Handle Service to each resource's SHIRE or by 
> redirecting the user's browser back and forth between the Handle 
> Service and each SHIRE.  That's it you're now logged out of all apps 
> and your Shib session.
>
> Now, session timeouts.  If you want session timeouts these are 
> pretty easy to accomplish with this architecture and can be done in 
> a few ways.  First you could have a single global timeout that after 
> so long of inactivity just kicks off the logout process (done more 
> easily if you use the out of band communications to send the logout 
> request to each SHIRE).  Or you could have resource specific 
> timeouts which is a nice feature.  For example,if you're logged in 
> to, say, an electronic journal the library is offering and your 
> student information system account it's probably okay if you leave a 
> terminal for a bit and someone gets access to the journal through 
> your account but you probably don't want them getting access to your 
> student system account.  If you want resource specific timeouts then 
> where you made the association between the resource ID and the SHIRE 
> URL you could add a session time out value. Then you just need a 
> session reaper thread on the Origin side to occasionally go through 
> the sessions and logout the ones that have been inactive for a 
> period of time.  This resource specific timeout could even be set 
> and given to the Origin by the resource provider giving them a nice 
> level of control over this particular security issue.

Again - I think the resource needs to decide when to do session 
timeouts.  In some cases, the app may want to know when the 
"authentication event" occurred and time out on that basis, vs the 
inactivity period.

> So, I've mentioned inactivity a few times now and if you've been 
> reading closely and thinking about this you're probably wondering, 
> how you track activity across applications that you don't manage. 
> This is the one minor sticky points that may or may not be that 
> sticky.  At VT we serve up an image from our WebISO server on each 
> webapp.  Each time the user reloads a page in any app we update the 
> last activity timestamp.  The image, in my opinion, is a really good 
> idea because it allows you to give the user a visual clue that says 
> "Hey, just FYI, your logged on in such a way that you can get to any 
> other webapp without re-authenticating". This gives our security 
> people warm fuzzies and, for users with a clue, keeps them aware of 
> the situation.
>
> Now I can see some app provider saying "I don't want you to put no 
> stinkin graphic on my site, you'll mess up my look and feel" because 
> I've heard it here at VT.  This is a very valid point so a single 
> pixel transparent gif can be served up for them (and you thought web 
> bugs were just for spam and slimey marketing stuff).

Cute.

> So, in the end this gives you:
> 1. The ability to do global logouts
> 2. The ability to have global session timeouts
> 3. The ability to have resource specific timeouts (not mutually 
> exclusive with item 2)
> 4. That ability to ask questions like "Which services am I currently 
> logged in to?"
> 5. And possibly a minor bit of security gain in the authentication 
> process through SHIRE to Handle Service handle verification
>
> Just a short comment about naming.  In this model it MAY be a good 
> idea to call the thing on the Origin side that handles session stuff 
> something other then the Handle Service and it MAY be a good idea to 
> call the thing on the resource side that handles session stuff 
> something other then whatever the SHIRE is now called.  It may just 
> ease communication when talking about them.  They may be implemented 
> as one thing but they could still be talked about as separate 
> logical concepts.
>
> --
> Chad La Joie
> Project Manager           (540) 231-6853
> Middleware Services       http://www.middleware.vt.edu