Re: random topics

Hi Ludo, 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 authorization purposes: 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. Cheers Daniel Ludovic Poitou wrote: > Howard, > > I'd be more than happy to help align the contribution to our > implementation. > 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. > > Ludovic. > > > > On Sep 27, 2009, at 10:51 PM, Howard Chu wrote: > >> Howard Chu wrote: >>> OpenDS also has matching rules defined for comparing timestamp >>> attributes to >>> "current server time". This is extremely handy for a lot of >>> things. Again, >>> this is a small, self-contained project that should be simple for >>> someone to >>> 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/