[Freeipa-devel] Summary of Session discussion

[Adam Young]

   There are four cases where we've discussed using sessions for 
optimizations.  During today's phone discussion we analysed them.

1.  Avoiding the negotiate round trip.

Requesting a page protected by Kerberos requires two round trips to the 
server:  1 for the initializ request, which gets denied with the 
negotiate challenge, and one for the negotiate response.  mod_auth_kerb 
can fall back to userid/password.  THe suggestion was t hat we allow 
mod_auth_kerb to set a session cookie after a successful negotiate 
request.  Future requests can use that cookie to bypass the negotiate 
handshake.  The problem with this approach is NFS home directories, and 
root users being able to get  access to the session cookies, allowing a 
replay attack.  Note that this is a problem with the userid/password 
fall-back as well.  We are not going to pursue this right now.

2.  Caching the service ticket.  Once the http request has gone through, 
the ipa web server needs to request a service ticket for LDAP.  If the 
session contained the service ticket, the could be bypassed for 
additional requests.  Since the request has to be validated by Kerberos 
for the initial negotiate call, there is no additional loss of security 
in caching the ticket.
     A potential alternative to server side caching is for the client to 
request the service ticket and send it in the negotiate handshake.  
There is some question as to whether the web server would be able to 
acces this ticket, and also whether the client can somehow request a 
ticket that the server can use, and still comply with the Kerberos 
standards.

3.  File Upload.  Session time out provides a means to automate the 
clean up of files that might otherwise be orphaned.

4.  Windowing search results.  the 'find' APIs as implemented by LDAP 
limit the responses to 200 records by default.  One request we've had is 
to provide sorting and windowing.  Windowing here is defined as, for a 
sorted response, return a delimited number of records starting at an 
offset greater than 0. The LDAP implementation requires the equivalent 
of a cursor from the requester, in this case the Apache server.  To 
maintain association between the user and the cursor, the cursor 
identifier would be stored in the session.   Implementing this correctly 
will require further design.  It will likely be done in the future.

In summary, the caching of the service ticket alone provides a 
compelling reason to implement sessions.  File upload will take 
advantage of them.  Other uses may be found over time.