|
> A general comment about the approach:
> The method described using special purpose controls and
responses
> means that every ldap enabled program will need to
be "cache
> enabled". IOW, they will not be to able to make use
of the cache unless
> programmed to do so. Would it not be better to use
some sort of flow
> through model where an ldap enabled program that is
*not* "cache
> enabled" would attempt to bind to the local cache
which would either use
> its cache or flow through to the "real" server? Then
mobile users would
> only need one "cache enabled" program to easily
add/remove things
> from the cache.
Good point. Support for a flow-through model is indeed
desirable to transparently support non "cache enabled"
programs. However, LDAP apps that bind to the local cache must
at a minimum specify the real/remote server and port no. to the
caching proxy. LDAP apps can choose to support the
proxyServerBindControl alone. This could even be integrated in the LDAP SDK
so that it is transparent to apps using the LDAP SDK. The LDAP library/DLL could
add the proxy control before sending it to the caching proxy. Another
option is to pass the remote server and port info. as part of the Bind DN
when binding to the local cache but this makes it a non-standard solution.
> 3.1 proxyServierBind Controls: > disconnectedMode > Why ignore the serverPort field when in disconnected
mode? This makes
> it impossible to differentiate between the LDAP servers when there are > multiple servers running on the same serverName. Agreed.
> 4.1 Caching logic...
> base search > "Results returned to the client, however, will be based on the search > filter specified." > The filter only is used to determine which objects
qualify. The
> attributes and typesOnly fields determine the results sent to the client. Yes. It will be based on the attributes and typesOnly
field.
> "The entire object shall be fetched and
cached."
> What is the reason behind caching the whole object? The
search
> request shows that the only the attributes named in the filter and > attributes fields are of interest... If this is intended, then put * in the > attributes field. If the object is large over a slow (dialup?) link this > could be painful. If we attempt caching a partial object, it may violate schema
rules wrt mandatory attributes, since the caching proxy itself would
include an LDAP server and enforce schema.
The caching proxy aims at working transparently with existing
applications and use base searches as a hint to cache objects. We could say that
the caching proxy will use the attribute filter to access the object from the
remote server and cache the object only if all mandatory attributes are
requested. However, while this would address the slow link scenario, we lose the
caching benefit.
> 5. Authentication and access control...
> Access control and authentication in a discretionary
access control
> system such as LDAP (in the current ID) only control
how the information is
> released or modified in the system. It does not control
what can be done
> with it. IOW, once you have read information, LDAP does not control or > dictate how you will use it or where you will store it. If the > administrator does not trust you to treat the information appropriately (as > he defines it), he should not give you access. RFC 2251 does recommend how you should store the
retrieved information. Please take a look at this last paragraph from the
Security Considerations section of RFC 2251.
"Implementations which cache attributes and
entries obtained via LDAP
MUST ensure that access controls are maintained if that information is to be provided to multiple clients, since servers may have access control policies which prevent the return of entries or attributes in search results except to particular authenticated clients. For example, caches could serve result information only to the client whose request caused it to be cache." > Having said that, I agree that the cached objects
should be protected (if
> possible). I am very concerned that you seem to be storing the identity > and keys to access the directories in the proxy
server (so that the user
> can be authenticated in disconnected operations). If the
mobile system
> falls into the wrong hands, all objects accessible
by those identities/keys
> are vulnerable. If you don't store the identities
and keys, then only the
> objects in the cache are exposed. I would rather
deal with the later and
> restrict what I cache, than deal with the former. Again, it is important to authenticate the user in offline
mode before allowing access to cached content. With secure authentication
methods like Message Digest and Certificate authentication, the stored info.
pose little risk since they cannot be used to authenticate to the remote
directory. For simple, password based authentication, the
caching proxy will store a one-way hash to verify the password - but not store
the actual password itself (as discussed
in <draft-zeilenga-ldap-authpasswd-03.txt>) .
Vijay
|