On 05/26/2011 02:01 PM, Simo Sorce wrote:
On Thu, 2011-05-26 at 12:53 -0400, Adam Young wrote:
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,
Can you expand the reasoning about NFS home directories ?

As Stephen Gallagher points out, Secure cookies are held in memory, not on disk. However, the ipa client is a complete process, and it would need to be able to store the cookie somewhere for CLI to use.

  and
root users being able to get  access to the session cookies, allowing a
replay attack.
Root can simply steal your TGT, that is not a concern we have any reason
to raise here.

I might have root on a machine that can mount via NFS, and thus allow me to su to your account, and get read access to your home directory. I don't need root on your machine. BBut again, only an issue if the session cookie got written to disk, which shouldn't happen with session cookies.
   Note that this is a problem with the userid/password
fall-back as well.  We are not going to pursue this right now.
We are not going to pursue using sessions ? Or concerning ourselves with
these issues ? :)

I think we are not going to pursue the mod_auth_kerb streamlining I outline, at least not in the short term. An additional issue is getting the update to mod_auth_kerb accepted. I'd say we can purse this in parallel, as I think it will be a valuable performance optimisation, but it does not have to be part of the IPA work per-se.

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

      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.
This should be possible, but there is no client that can do that right
now, and changing clients is simply out of our reach in most cases.
Yes, and thus we are not going to pursue that approach.

3.  File Upload.  Session time out provides a means to automate the
clean up of files that might otherwise be orphaned.
What kind of files ?
Certificates and automount maps are the two we've discussed recently.

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.
The cursor need also to be associated to a specific query, cannot be
just a session-global variable.
Agreed. It means that subsequent API calls can reuse a specific query. But we want it to be optional, or there would be significant overhead, and thus we'll postpone this approach for now.


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.
Very good, thanks for taking up on this analysis task.

Simo.


_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to