Shibboleth Developers

[Chad La Joie <>]

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.  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).  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. 
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.

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).

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