[ANN] Net::LDAP 0.0.4 released

Rails
1

Announcing version 0.0.4 of Net::LDAP, the pure-Ruby LDAP library.

Thanks to the many people who have used this library and sent in
comments,
suggestions, feature requests, and patches. An even bigger thank-you to
the
folks who have made themselves available to help with testing.

Net::LDAP has been quite stable for several months now, so we bumped
the development status of the library up to Beta. We will still be
adding
features and API improvements, but you can assume that the current
APIs and features will remain stable.

We’ve noticed that the Rails list gets regular chatter about
authentication
and authorization. To address what seems to be a clear need, we’d like
to create some Rails integration (probably a plugin) based on Net::LDAP.
I’d love to hear your ideas and insights on what would be the most
useful
set of features to provide. Additionally, we’re thinking ahead to adding
presence
and directory-aggregation to Net::LDAP, possibly through an additional
set of packages.

Version 0.0.4 adds an implementation of Net::LDAP#bind_as, which allows
you to authenticate users who log into your applications using simple
identifiers like email addresses and simple usernames. Thanks to Simon
Claret
for suggesting the original implementation in his page on the
Rails-Wiki,
and for valuable comments and help with testing.

We have un-deprecated Net::LDAP#modify, which can be useful with
LDAP servers that observe non-standard transactional and concurrency
semantics in LDAP Modify operations. Note: this is a documentation
change,
not a code change. Thanks to Justin F. for providing the rationale
for this change.

We added a larger set of special characters which may appear in RFC-2254
standard search filters. Thanks to Andre N. for this patch.

We fixed a bug that was preventing Net::LDAP#open from being called more
than once on the same object.

Net::LDAP is a feature-complete LDAP client which can access as much as
possible of the functionality of the most-used LDAP server
implementations.
This library does not wrap any existing native-code LDAP libraries,
creates no
Ruby extensions, and has no dependencies external to Ruby.

If anyone wants to contribute suggestions, insights or (especially)
code, please email me at garbagecat10 … … gmail.com.

2

Excellent! Keep up the good work.

The Tivoli Directory Server saga continues on my current project - it’s
impossible to meet the security architect’s requirements that we use TDS
to implement password policy without deviating from the (signed-off)
Functional Requirements Spec.

regards

Justin

3

Justin F. wrote:

So, while it may be true that many LDAP servers don’t conform to the
specification (you are the one with the experience here), it isn’t
correct to say “this is a limitation of the LDAP protocol”, or
“…transactional atomicity, which LDAP does not provide”.

regards, and thanks for removing the deprecation

Justin

Would you like to have a go at patching the document?

4

Francis C. wrote:

Would you like to have a go at patching the document?

Yes, I’ll propose a patch.

Since I have access to OpenLDAP and TDS, and to satisfy my curiosity,
could you suggest the type of test I could use for atomicity?

I had a look at the free interoperability tests downloadable from the
Open Group, but they only included simple uses of modify.

regards

Justin

5

Justin F. wrote:

Excellent! Keep up the good work.

Francis C. wrote:
[…]

We have un-deprecated Net::LDAP#modify, which can be useful with
LDAP servers that observe non-standard transactional and concurrency
semantics in LDAP Modify operations. Note: this is a documentation
change,
not a code change. Thanks to Justin F. for providing the rationale
for this change.

The documentation comment for modify still says:

"Itâ??s essential to keep in mind that if you specify more than one
operation in a call to modify, most LDAP servers will attempt to perform
all of the operations in the order you gave them. This matters because
you may specify operations on the same attribute which must be performed
in a certain order.

Most LDAP servers will stop processing your modifications if one of them
causes an error on the server (such as a schema-constraint violation).
If this happens, you will probably get a result code from the server
that reflects only the operation that failed, and you may or may not get
extended information that will tell you which one failed. modify has no
notion of an atomic transaction. If you specify a chain of modifications
in one call to modify, and one of them fails, the preceding ones will
usually not be “rolled back,” resulting in a partial update. This is a
limitation of the LDAP protocol, not of Net::LDAP.

The lack of transactional atomicity in LDAP means that youâ??re usually
better off using the convenience methods add_attribute,
replace_attribute, and delete_attribute, which are are wrappers over
modify. However, certain LDAP servers may provide concurrency semantics,
in which the several operations contained in a single modify call are
not interleaved with other modification-requests received simultaneously
by the server. It bears repeating that this concurrency does not imply
transactional atomicity, which LDAP does not provide."

whereas the LDAP RFCs are very clear that:

  • operations must be carried out in the order in
    which they were specified

  • the entire modify operation must succeed or
    fail atomically

  • individual operations within the set may violate the schema, so
    long as applying the whole set doesn’t.

So, while it may be true that many LDAP servers don’t conform to the
specification (you are the one with the experience here), it isn’t
correct to say “this is a limitation of the LDAP protocol”, or
“…transactional atomicity, which LDAP does not provide”.

regards, and thanks for removing the deprecation

Justin

6

Francis C. wrote:

regards

Justin

Thanks, looking forward to your documentation patch. You can post it
here or email it to me privately. I’m probably going to do another
release shortly as I’m adding some LDIF support functions.

I’d like to do some tests before revising the documentation - won’t have
access to TDS until Monday.

I’ll mail the patch to you privately.

Atomicity test: try a series of modifies including one or more that
violate schema. (For example, if you use inetorgperson, try to delete
the SN attribute.)

Thanks - re-reading your current documentation I see that you also
mention that trying to add an existing value may cause an error, and
I’ve just seen that for myself with the description attribute in
groupOfUniqueNames, in OpenLDAP.

I wasn’t sure about using schema violation, as the RFC allows schema
violation part-way through a group of modification operations, so long
as the end result is compliant. I’ll try that out, though…

…yes, OpenLDAP gives me an error when removing the sn from a person,
but if I remove it and then add a different value within the same
modify, it succeeds.

regards

Justin

7

Justin F. wrote:

Francis C. wrote:

Would you like to have a go at patching the document?

Yes, I’ll propose a patch.

Since I have access to OpenLDAP and TDS, and to satisfy my curiosity,
could you suggest the type of test I could use for atomicity?

I had a look at the free interoperability tests downloadable from the
Open Group, but they only included simple uses of modify.

regards

Justin

Thanks, looking forward to your documentation patch. You can post it
here or email it to me privately. I’m probably going to do another
release shortly as I’m adding some LDIF support functions.

Atomicity test: try a series of modifies including one or more that
violate schema. (For example, if you use inetorgperson, try to delete
the SN attribute.)