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
http://blogs.sun.com/Ludo/ Grenoble Engineering Center - France
Join OpenDS,
https://opends.dev.java.net/servlets/ProjectMembershipRequest
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.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~