[Date Prev][Date Next]
Re: random topics
I've already seen your slides from LDAPcon2009 and I'm very fascinated
to see that there seems to be a general demand for some kind of ldap
server side current time evaluation. ;-)
I think the discussion during the conference would have been very
interesting, unfortunately I could not participate. So please let me
explain our intentions behind the currently contributed matching rule
and the requirements of our scenario:
We have been searching for a possibility for some kind of ldap server
side enforced data privacy and authorization feature that can take the
ldap server infrastructure's (including replicas) current time into
account. The current contribution represents the first stage of
development regarding our target and is indeed very similar to your
implemented solution in OpenDS. ;-)
We have focused our requirements in the direction of data privacy and
1.) Stale and/or future entries should not be contained in a result set
2.) Strictly the server should decide whether a distinct entry should be
currently contained in a search's result set or not.
3.) A client should not be able to "tweak" the server's current time
(even tweaking it indirectly using some kind of interval or offset as
assertion value, should not be possible at all).
On the other hand the above relatively easy terms produce new challenges
especially in combination with large scale replicated environments where
replica servers are located all around the world in different time
zones. The location of a client cannot be determined by the server
because the client is not allowed to influence/specify its timezone.
There are at least two possible solutions we have discussed at our site:
a) Allow a client to specify some kind of "offset" (e.g. limited to +-23
hours to tackle all kind of timezones).
b) Take the bind dn's entry into account to determine it's current
timezone based on one of its attribute values in combination with some
kind of replication mechanism (probably an enhancement of
syncrepl/-prov) which is able to take any server's "timezone location"
into account to manipulate distinct attributes' syntaxes/values.
Because a) violates our above mentioned primary goal regarding our data
privacy and authorization requirements we've decided to further
investigate into the direction of b). Nevertheless the approach a) would
be of course a "very nice to have" openldap feature, too. In my opinion
it would be worthwhile to align the current contribution with of the
current OpenDS functionality.
Any discussion would be very welcome.
Ludovic Poitou wrote:
I'd be more than happy to help align the contribution to our
One detail is that our matching rules have an assertion value which is
not empty. It's a string which represents an "Offset" to the current time.
Now +/- Offset, where the offset can be specified in seconds, minutes,
hours, days or weeks (s, m, h, d, w).
The offset can be used to deal with client timezones.
On Sep 27, 2009, at 10:51 PM, Howard Chu wrote:
Howard Chu wrote:
OpenDS also has matching rules defined for comparing timestamp
"current server time". This is extremely handy for a lot of things.
this is a small, self-contained project that should be simple for
jump in on.
Of course we've had this as a contribution in ITS#6247 for more than
a month. It seems all that's needed is to align the matching rule
name and OID with the ones that OpenDS is using.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/