| Hi Daniel,
I've come with the idea of server side current time matching more than 3 years ago when trying to solve a customer issue with access controls. I've actually discussed the idea with Kurt Zeilenga at one of the last IETF we've attended together. But I never got the time to get to implement it.
My requirement is also an authorization purpose, which is to be able to create time based access control rules not based on an absolute time, but a relative one, i.e. relative to the current server time.
I believe all of your requirements are matched with our implementation, if the matching rule is only used in access control rules defined in the server.
Adapting the computation of the current time based on some timezone attribute in the user entry seems way beyond the implementation of the matching rule itself.
However, I think there is a work around to it, which is not in the matching rule but with the attribute you use to determine if the entry is in the future or not.
Let's assume you are using the CreateTimestamp attribute as the attribute to measure if the entry is in the future or stale. When matching this attribute against the current time, everything is based on GMT time.
Rather than computing the current time in the client time zone based on a timezone attribute of the client entry, what about computing the "create local time stamp" based on the GMT value, the client timezone and the server timezone ? In OpenDS and Sun Directory Server, it is quite simple to create extension modules that generate Virtual attributes whose values are computed from other attributes. I'm sure the same can be done with a simple overlay in OpenLDAP. As a result, you can still apply the same relative time matching rule, but on a timestamp computed to take into account some possible time differences between the client and the server.
What do you think ?
Regards,
Ludovic.
On Sep 29, 2009, at 4:07 PM, Daniel wrote: 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/
--- Ludovic Poitou Sun Microsystems Inc. OpenDS Community Manager Directory Services
Sun Microsystems requires the following notice: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|