On 05/26/2011 02:19 PM, Dmitri Pal wrote:
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 ?
Cookie can be stored on the home directory of the user and user home
directory can be NFS mounted so if we save anything important in the
cookie the NFS root would be able to impersonate the user. It assumes
that TGTs are not stored on the NFS in this case so replacing the TGT
auth with fast session cookie auth would be a security issue.
I hope I understand the issue correctly.
NOt secure cookies, so it is only an issue for the CLI. If the CLI can
store the cookine in the key store, then we don't havea problem.
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.
NFS root?
Root user on a different machine that is allowed to mount NFS has pretty
much complete access to the NFS directories. The root user can su to an
user on the system.
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 ? :)
We are not going to try to avoid kerberos renegotiation on every request.
Hm should we consider something like Oauth in this case?
OAuth suffers from the same issues.
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.
In any case if we cache the ldap ticket we need to get it from the cache
before finishing the request.
The question came up: is the python-kerberos/krbV packages provide the
interface to the CC to get 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.
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.
We can do it in the XML-RPC/JSON outside of kerberos but is it worth it?
We need to extract the ticket first.
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 ?
Entitlements
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.
You can limit it to have one cursor open per session at a time so you
can use it as session global.
You do not need to have to queries paginated at the same time from UI so
there is no need to keep more than one cursor.
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
