Some of these should go onto the roadmap or TODO list. Just scribbling them down here before I forget.
Had a chat with tridge and abartlet about the LDAP TXN support they're looking for with Samba4. One of their requirements was being able to do reads inside the TXN, and that is explicitly not supported by the LDAP TXN draft. But after talking a bit more about how they do things in LDB, we decided to take the same approach here - LDB only allows one writer when a TXN is active. We can write a (global) overlay that gives this same behavior, and then not have to worry about any of the other TXN details.
While thinking about back-mdb, I realized that since we're mapping storage to memory we don't really need a traditional disk-DB structure. Instead we can just manage the space as its own heap and use in-memory structures like AVL trees and such. I've been thinking about extending our current AVL library to a T-tree implementation. Further reading along those lines led me to Cache-Sensitive T-trees (CST-Trees) which also have the important property of being friendly to CPU cacheline sizes, and so behaving a lot better in multi-processor systems. This is a pretty generic project - if anyone's been looking for a relatively self-contained bit of work they could contribute, this would be ideal. You can get the paper here:
http://ids.snu.ac.kr/wiki/CST-Trees:_Cache_Sensitive_T-Trees
(Note that these things are only good because they can fit all the keys into a single node - i.e., they only have their most desirable properties when keys are small. We could certainly use them for the id2entry index, and maybe a few others, but in the general case we need to be able to use pointers to arbitrary data as keys.)
ITS#6301 also fed into this search, but I think we just want to use threaded AVL here instead of the Red-Black tree code. That would shrink the size of the patch down considerably, which would also be a good thing. Again, anyone looking for a relatively small project, this one is pretty straightforward.
Also a completely fringe topic, but still interesting - we've got OpenLDAP running well on Android now; on a G1 phone. But it's still just a set of command-line tools. UnboundID showed off their Java LDAP SDK in a simple app also running on Android. A combination of these two would make an extremely powerful package:
Develop a canned slapd config that uses syncrepl to sync with a remote LDAP address book. Use proxied multimaster, to allow local changes to be propagated back to the remote directory. Write a java app that uses LDAP for the G1's contact book backend instead of the SQLite ****stuff that it's currently using. Accomplishing this will necessitate writing a few GUI menus for configuring the handful of variables needed for the slapd config.
This also brings me to another topic - adopting features from OpenDS... They expose a cn=Tasks tree which can be used for submitting tasks via LDAP. Currently we expose our runqueue under cn=Monitor but that's only read-only. It would be nice to be able to submit/schedule/trigger tasks on the fly... In particular, it would be nice to have a defined task for triggering a syncrepl refresh.
The Android slapd config would be a refreshOnly syncrepl consumer. It would also have a hidden back-ldap refreshOnly consumer replicating from its local database and writing to the remote master. This way both push and pull would be under control of the Android device. (You have no idea how much of a bill you can rack up with fully automatic background synching. It's much better to have this under complete user control.) The GUI would just submit a request to cn=Tasks to trigger a synch.
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.
More ideas later...
----- "Howard Chu" hyc@symas.com wrote: <snip>
This also brings me to another topic - adopting features from OpenDS... They expose a cn=Tasks tree which can be used for submitting tasks via LDAP. Currently we expose our runqueue under cn=Monitor but that's only read-only. It would be nice to be able to submit/schedule/trigger tasks on the fly... In particular, it would be nice to have a defined task for triggering a syncrepl refresh.
That would be nicer that having to remove and then add a syncrepl statement.
The Android slapd config would be a refreshOnly syncrepl consumer. It would also have a hidden back-ldap refreshOnly consumer replicating from its local database and writing to the remote master. This way both push and pull would be under control of the Android device. (You have no idea how much of a bill you can rack up with fully automatic background synching. It's much better to have this under complete user control.) The GUI would just submit a request to cn=Tasks to trigger a synch.
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.
More ideas later...
All very cool and very handy. I soo wish I could have made it. Any ideas of next years venue? Europe (London ;-) )?
Howard Chu wrote:
This also brings me to another topic - adopting features from OpenDS... They expose a cn=Tasks tree which can be used for submitting tasks via LDAP. Currently we expose our runqueue under cn=Monitor but that's only read-only. It would be nice to be able to submit/schedule/trigger tasks on the fly... In particular, it would be nice to have a defined task for triggering a syncrepl refresh.
Yupp. That would be nice. May I propose to use another DN for this backend?
In web2ldap you can configure many templates and other stuff for a given name space (besides other configuration granularity). E.g. if this would be "cn=OpenLDAP Tasks" I could ship a better default config in web2ldap's source configuration.
See http://www.web2ldap.de/web2ldapcnf_hosts.html#cascaded_config
BTW: Same for cn=config. If it would be "cn=OpenLDAP Config" I could ship with a better default configuration. By now I only have commented examples. Maybe in 2.5?
Ciao, Michael.
Howard Chu wrote:
Some of these should go onto the roadmap or TODO list. Just scribbling them down here before I forget.
Had a chat with tridge and abartlet about the LDAP TXN support they're looking for with Samba4. One of their requirements was being able to do reads inside the TXN, and that is explicitly not supported by the LDAP TXN draft. But after talking a bit more about how they do things in LDB, we decided to take the same approach here - LDB only allows one writer when a TXN is active. We can write a (global) overlay that gives this same behavior, and then not have to worry about any of the other TXN details.
Interesting. Just out of curiosity, this won't change or expand the core spec since it's going to be implemented as an overlay, correct?
While thinking about back-mdb, I realized that since we're mapping storage to memory we don't really need a traditional disk-DB structure. Instead we can just manage the space as its own heap and use in-memory structures like AVL trees and such. I've been thinking about extending our current AVL library to a T-tree implementation. Further reading along those lines led me to Cache-Sensitive T-trees (CST-Trees) which also have the important property of being friendly to CPU cacheline sizes, and so behaving a lot better in multi-processor systems. This is a pretty generic project - if anyone's been looking for a relatively self-contained bit of work they could contribute, this would be ideal. You can get the paper here:
http://ids.snu.ac.kr/wiki/CST-Trees:_Cache_Sensitive_T-Trees
Thanks for the reference. Anything in particular you think would help acclimate those unfamiliar with the existing code base to our current AVL libraries and implementations?
Also a completely fringe topic, but still interesting - we've got OpenLDAP running well on Android now; on a G1 phone. But it's still just a set of command-line tools. UnboundID showed off their Java LDAP SDK in a simple app also running on Android. A combination of these two would make an extremely powerful package:
Develop a canned slapd config that uses syncrepl to sync with a remote LDAP address book. Use proxied multimaster, to allow local changes to be propagated back to the remote directory. Write a java app that uses LDAP for the G1's contact book backend instead of the SQLite ****stuff that it's currently using. Accomplishing this will necessitate writing a few GUI menus for configuring the handful of variables needed for the slapd config.
Neat! I'd love to configure my G1 to behave this way. So, is there an open invitation to brainstorm/make suggestions for/write a GUI front-end in collaboration with the Project's developers (mostly for their approval, review, et cetera)?
More ideas later...
All really good stuff, Howard, thanks for sharing it! Wish I could have been there, sounds like it was a really interesting collection of dialogues. Looking forward to hearing more from you and the other attendees!
Respectfully, Ryan
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,
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. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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.
Hey Ludo, sounds great. I think a good start would be just pointing out which source files contain your implementation. (Of course a spec will have to be published too, but working code is always a good starting point.) Also if you already have any test scripts for it. Thanks!
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.
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/
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. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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/
-
Daniel -
Gavin Henry -
Howard Chu -
Ludovic Poitou -
Michael Ströder -
Ryan Steele