Hi Ludo,
first of all sorry for my late answer.
Ludovic Poitou wrote:
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. [...] 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 requirements
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
implementation:
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,
nothing else
- 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
the gap
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 rule,
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!
Best regards,
Daniel
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/
