Francis C. wrote:
TDS.
Yes, indeed.
To answer your question as you posed it: I’m going to assume you’re
writing a trigger of some kind to modify your TDS data when your AZ
tables change. LDAP defines an “attribute” as an attribute-name and a
set of values. The set of values may be of any cardinality, including
zero, depending on the constraints of your schema. When you search for
an entry via LDAP, the protocol will return to you all of the values
for each attribute you request. (This could be hundreds of values, of
course.) You can modify the set locally using Net::LDAP APIs. When you
update the attribute, all of the values, including the ones you didn’t
modify, get sent back to the LDAP server.
All our changes are timestamped in the application’s database (and all
deletions are logical deletes), so we can replicate frequently,
focussing on what has changed since the last successful replication, and
retry on failure.
There is much more data being maintained (under dual-operator control)
than the organisation/user/profile/function data that is needed for
authentication/authorization.
After replying earlier, I had a quick look at RFC1777
http://www.ietf.org/rfc/rfc1777.txt
and the description of modification (section 4.4) suggests that
additions and deletions of attribute values can be done incrementally
over the wire.
(Your Net::LDAP add_attribute method will add values to those already
existing, but your delete_attribute method deletes all values.)
Read the RDoc for Net::LDAP#modify carefully to understand the
distinctive semantics that LDAP defines for these operations: they are
well-defined, precise, rather complex, somewhat unintuitive, and quite
unlike typical database operations.
Yes. Given that it is not possible to wrap multiple operations in a
transaction, it seems valuable to be able to make fine-grained
modifications. Otherwise someone else could update a multi-valued
attribute between our read and our write. (We should be the only source
of updates to the directory content, but I’d like to make the solution
as robust as possible.) If I can just say “remove this user’s DN from
the members of the Admin group”, that seems better (and exactly what the
protocol was designed to be able to do).
Is this a problem? Well, how often do your AZ rules change? TDS is a
fairly powerful LDAP implementation and can handle a fair amount of
flux. (If you had to do this in Active Directory, I’d strongly advise
you not even to try.) But the fact that you are running TDS tells me
that you are probably a large company beholden somewhow to IBM. (Maybe
they told you that they wouldn’t support Websphere unless you
implemented TDS?) So you’ll have to experiment and see if this will
work. I will say that Net::LDAP is going to be at least as fast as JNDI
on the wire, so if you find that your prototype is slow, don’t expect it
to be magically faster when you go to Java.
Our client is a large company, and IBM runs their applications. They
(IBM) are pushing hard for the use of TDS with WebSphere
container-managed authentication and authorization, and they have the
client’s ear. This is happening in mid-project; we already had all the
authentication and authorization working against DB2.
Now I’ll try to answer your question on somewhat different terms: why
are you using an LDAP directory for authorization in the first place?
You should be using it for authentication and identity-management,
nothing more. There are other, far more effective approaches for AZ.
Feel free to send me a private email if you want to discuss your
application in more detail.
I’ll take you up on that (but not over the weekend) - thank you very
much indeed.
Justin
