Shibboleth Developers

[Chad La Joie <>]

Well, I can address the IdP side of things, Scott can answer the SP better.

Let me start with how sessions work in Shib 2, as both SSO and SLO are 
tied to that underlying mechanism.  First, Shib 2 actually has a notion 
of a user session (previously it was only the container that did). 
Within these sessions two basic things are tracked.  Authentication 
method information (has the user authenticated with username/password, 
one time password, digital cert, etc., when did they authenticate, when 
does that authentication method timeout).  It also tracks which services 
the user has been logged into, or more correctly, which services an 
successful authentication response has been issued to.  Then it tracks 
the relationship between these two things (which authentication method 
was used to log the user into which service).  A few bits of additional 
information are tracked as well, but are not of interest for this 
discussion.

Now, two relevant bits about authentication in SAML 2.  First SP may 
request a user be logged in via one any number of mechanisms.  So, for 
example, and SP may indicate the user should be logged in via one time 
password or digital cert (and so implicitly not other means).  Second an 
SP may request the user be re-authenticated.

So, as I said in the thread you had on users it doesn't make a lot of 
sense to talk about per-SP timeouts on the IdP side.  If they did exist 
the following would occur.  At expiration time the IdP would send a 
logout request the SP causing the SP to destroy the user session (maybe, 
see the logout discussion below for why there is a good chance that this 
won't work).  The user would then hit the SP, the SP would treat this a 
new user (since the session is now gone) and send the user, with an 
authentication request, to the IdP.  If any authentication method that 
meets the SPs requirements hasn't expired the IdP will send the user 
back to the SP with a successful authentication response.  This is 
*single* sign-on.

So the basic division of control between the IdP and SP is that the IdP 
is presumed to know how long it's safe for a particular authentication 
"session" to live.  The SP is presumed to know what authentication 
method it wants in order to achieve some level of security that it is 
comfortable with.  If the SP wants the user re-authenticated after a 
certain period of time then it can force this with the re-authentication 
flag in its authentication request.

So, no, the Shibboleth 2.0 IdP won't have a notion of per-SP session 
timeouts, but it does have the notion of authentication methods only 
being active for a specified period of time.

Now, logout.  Logout in SAML 2 has a sort of matrix of functionality, 
you can have either front-channel (browser post/redirect) or 
back-channel (SOAP) requests and you can have SP or IdP initiated 
requests.  Let me start with the back-channel ones because they are 
actually the easiest in some respects.  If the SP initiates the logout 
process, by sending a logout request to the IdP, then the IdP runs down 
the list of services the user is logged into and sends back-channel 
logout requests to all be the initiating service and then finishes up 
with a logout response to initiating SP.  If it's an IdP initiated 
logout the same thing happens except the logout response step, obviously.

Now, the major problem here is that most applications want to store 
their session information in a cookie which won't be available on a 
back-channel SOAP request.  However, if your application can support 
back-channel requests there is a much higher chance that the logout 
requests will be successful, for reason which will become clear next.

Front-channel logout requests work like the back-channel in regards to 
the logical message flow except the logout requests (and response if 
it's an SP initiated flow) are sent the services via the browser to the 
services.  This may solve the problem of the application not having 
access to its session cookie but introduces two new problems.  First, 
the IdP loses control of the processes every time it send the browser 
out to a service.  If you service A, B, C and the browser is sent out to 
A and returns and then sent out B and the service is down you're left 
with C still having a session for the user and no way to inform that the 
user that there was a problem.  Now there are some tricks we might use 
to deal with this but none of them are handicap-accessible as they 
require tricks with frames and lots of ECMAScript.  I can't believe I'm 
advocating this, but it's possible that AJAX could be useful here but 
that doesn't remove the requirement for ECAMScript.  The second problem 
is that it's possible the browser being sent to the SP isn't actually 
the user whose session is being destroyed and so the session cookie may 
not be there anyways.  This occurs during administrative logouts; an 
admin logins into the IdP picks an active session and forces a logout.

So, while logout is the most often requested feature for Shibboleth 2.0 
I don't believe people actually understand the implications of it. 
While the picture painted above is modestly bleak I should note that I 
have experience with single logout working pretty well within a 
controlled environment; robust applications within a campus.  I think 
this describes what many people want to do so in that case logout 
support may be great for them.

As far as load balancing on the IdP goes will probably offer a couple 
options.  One option *may* be storing session information in a cookie 
(or chunked across a set of cookies), this will depend on if we can pack 
enough information into the max space we have.  Other options will be 
in-memory replication (the current HA-Shib functionality) or support for 
writing the information to a database.

Hope this helps even if it's not the answers you were probably hoping for.

André Cruz wrote:
> Hello all.
>
> I have a few questions/suggestions regarding the development of shibboleth.
>
> One of the main features that I need from Shib 2.0 is the single logout 
> feature. Right now we logout from the current application the user's in 
> and the IdP, but all the other applications the user has logged into 
> remain oblivious to the logout (we suggest out users to close the 
> browser but not all of them do it).
>
> What I would like to know is how this will be implemented in Shib 2.0. 
> Will the IdP store which applications have requested the attributes and 
> notify them on a logout? How will this information be shared among an 
> IdP cluster? Maybe on some scenarios (small number of SPs and lots of 
> users) it would be better just to notify all SPs and this way no state 
> would have to be stored/shared?
>
> Another feature that I would like is to be able to set an SSO lifetime 
> per Application (and force a re-auth at the IdP). I have been working on 
> this with Shib1.3 (I sent some emails to the -users list but the 
> solution is not really perfect). Since Shib will be handling the Auth as 
> well I think this feature should not be too hard to implement?
>
> Another problem I'm having now is regarding the load balancing of the 
> SPs. Our applications normally have more than one front-end behind a VIP 
> and a cluster os Perlbals. What this means is that sticky sessions would 
> not be very efficient. So, the redirects from the SPs most of the time 
> end up on another SP and some redirects happen that could have been 
> avoided. Most of the applications use a database to store their sessions 
> so a session cache plugin that used this database would be a good option 
> I think. I read in the wiki that Shib2.0 would include a cache plugin 
> that supports ODBC, this will solve my problem right?
>
> Thanks and keep up the good work. :)
>
> André

--
Chad La Joie             2052-C Harris Bldg
OIS-Middleware           202.687.0124