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.that's right. It matches at least partially for our whole scenario but even nearly 100% regarding our minor aim in direction of access controlI 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.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.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.What do you think ?
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 set2.) 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 tojump 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/