Shibboleth Developers

[Chad La Joie <>]

We actually do something a bit different.  Our WebISO can be aware of 
whether you logged in from a "public" system or a "private" one and 
adjust the session time outs accordingly.  The reason we try to force 
this session timeout is because a lot of apps don't do it or have way to 
long of a timeout.  So this sort of model allows us to impose better 
practices then might otherwise be followed.  The other reason, and 
probably the more important one for this discussion, is that if a user 
clicks the "log me out of everything" link that appears in our webapps, 
the WebISO needs a way to tell all the apps a user is logged into to log 
that user out.

Now, as I said, if an app doesn't want to have our WebISO tell it when 
to log a user out, for whatever reason, it can simply drop the message 
and do nothing.  I think though that you really want the ability to do 
this.  We got hammered on this issue for a while by our users because 
they wanted to see it.  It was kind of the thought that single sign-on 
is supposed to make their lives easier, so make it as easy as possible 
by going this extra step.

David L. Wasley wrote:

> 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

--
Chad La Joie
Project Manager           (540) 231-6853
Middleware Services       http://www.middleware.vt.edu