first of all sorry for my late answer.
Ludovic Poitou wrote:
I've come with the idea of server side current time matching more
3 years ago when trying to solve a customer issue with access
controls. [...] But I never got the time to get to implement it.
As usual that has
been exactly the same situation over here - but
finally we took the time, also for this "short" answer... ;-)
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.
that's right. It matches at least partially for
our whole scenario but
even nearly 100% regarding our minor aim in direction of access control
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.
A possible need for this mechanism arise from our special
regarding different timezones. If I've understood your intention
correctly (interpolated from the following paragraph of your answer) you
are just using one attribute to determine the starting point in time. To
determine some kind of delta (time period) the matching rule is used to
specify (negative/positive) time deltas like +/-4d?
Let's assume you are using the CreateTimestamp attribute as the
attribute to measure if the entry is in the future or stale.
I currently do not
know your implementation and I do not understand this
point in regard to our implementation. I think the createTimestamp
cannot be of any use to detect entries in the future, because the
createTimestamp (and the entry) only exists when it exists. ;-) Or do
you modify (fake) the createTimestamp in any way? Our approach is
independent from "existing" operational attributes like createTimestamp.
Please let me try to explain the possible differences regarding our both
Thus we are using two additional (might be operational?) attributes that
exactly specify an entry's "lifetime" we do not need to specify some
kind of delta time in our matching rule's assertion value at all.
In our opinion the differences (perhaps advantages?) of our idea are:
- strictly focusing the matching rule to determine the current time,
- forbid the client to (indirectly) manipulate the current server's time
using any kind of offsets and the like
- even without our special needs regarding data privacy concerns we
could request (just informational) an entry's lifetime without using the
matching rule or even ACL processing first.
When matching this attribute against the current time, everything is
based on GMT time.
yes that's possible
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.
Before this matching rule implementation we've
developed a very powerful
(not yet contributed) overlay which took a request's searchfilter and
replaced a distinct "virtual" attribute's PRESENT filter expression by
an AND filter using the current time to compare the two attributes. It
works very well and is internally configurable (schema, aka attribute
names to compare and its logic) during runtime to control the search
filter replacement (or bypassing) depending on the different conditions
(e.g. relative position in DIR, local entry properties, centralized
group information local entry stored dn- and group-list information for
exclusion and inclusion into bypass list etc pp.)
The only (major) disadvantage is that using the current slapd API it is
not (cleanly?) possible to influence slapd's ACL definitions on an
operation basis using an overlay. Also triggering some kind of overlay
logic from inside ACL processing is not available (because a ACL filter
is of course not invoked like a search operation). As a result the
virtual attribute's filter expression cannot be replaced dynamically
using the operation's time for ACL filter statements.
As an intermediate conclusion our overlay approach in comparision to the
currently contributed matching rules has the following difference:
Using the overlay-mechanism there's no timedrift during slapd's internal
entry processing. The filter get's replaced once (at the beginning of a
request). Ok, time still moves on but the result set contains at least
the entries that have been valid during the initial request.
In contrast, the matching rule (as noted in our README, especially in
combination with ACL filter statements) get's evaluated sequentially for
each entry of a search's result set. This results in some kind of
internal "timedrift" between entries. It could happen that entries with
the same validity period could be delivered to a cient while other
entries (with the same validity period attribute values) get excluded
aka do not match the matching rule anymore.
==> As a result the matching rules result's are "more exact" in relation
to the actual delivery point in time.
==> The overlays results are "more exact" in relation to a client
request's point in time.
==> a possible combination: overlay + matching rule could perhaps close
So both methods do have their own special effects (each effect can be
taken as advantages as well as disadvantages, depending on the
requirements and scenarios).
A matching rule at least has the advantage to be more portable. Not
every (only the best ;-) ) directory server implementation offer the
possibility to implement modular extension.
<common slapd api question>
During the discussion in ITS6247 a "small" API extension (might be
targeting in direction of slapd 2.5?) has been mentioned, too: similar
to the above mentioned might be useful overlay trigger from within ACL
filter processing a pointer pointing to the current operation from
within the matching rule processing function could be perhaps helpful, too?
</common slapd api question>
As a result, you can still apply the same relative time matching
but on a timestamp computed to take into account some possible time
differences between the client and the server.
What do you think ?
All I've understood until now and as I've written in my
last posting, in
general both approaches (your matching rule that offer some kind of
helpful integrated offset calculation as well as our matching rule that
explicitly does not offer any kind of client side manipulation, just the
server's current time) seem do have similar goals - at least regarding
simple time based access control scenarios. Please don't understand me
wrong, currently I don't know exactly which method I would prefer (for
access control only), possibly both matching rules are helpful.
In my opinion the approach using two distinct attributes for "ldap
server side entry period lifetime evaluation" (as we are calling our
overall goal) would possibly be of a slightly more general use in regard
to the sense of LDAP in common:
Both attributes can be requested, even without the matching rule taking
effect the returned entry's validity-period can be evaluated
(independently on client side). Only if I've understood your
solution/suggestion the right way your entries do not offer this kind
of "offline" lifetime evaluation, because you are just using a starting
point in time +/- variable offset which could differ from entry to entry
depending on the ACL that a distinct entry is currently processed by...
? (BTW: a negative offset in combination with createTimestamp (as
stating point in time) seem to make no sense to me.
Nevertheless your approach is also very interesting, and based on our
current presentation there seem to be no problem to integrate your
presented functionality into OpenLDAP, too. As you've mentioned, in
combination with some kind of additional software-component
(module/overlay) it could perhaps be extended into our originally
intended direction. In contrast, our goal would be to avoid any
additional module processing (resulting in a better portability into
other LDAP servers that are not extensible by modules?).
Hopefully I got your point and you could follow my fuzzy explanations.
As Howard already has written before, could you please provide us some
link to your matching rule implementation's source to get a better
understanding of what you are doing within OpenDS? Thanks a lot!
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'
> 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
>>>> 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/