Re: "LDAP ease modify restrictions" support

[Radovan Semancik <radovan.semancik@evolveum.com>]

On 02/22/2016 12:53 PM, Michael Ströder wrote:
> Radovan Semancik wrote:
> > E.g. imagine that two clients adds user to the same group.
> What's the rationale for doing that?

There are two independent clients. Do you need an explicit rationale for 
each of them to do the same operation at the same time? I would rather 
say: what makes you think that the clients will NOT do that operation? 
Or would you expect that all the clients of the directory server must be 
explicitly synchronized by some "magic" external means?

But OK, let's get more specific. Consider this example: midPoint is an 
IDM system. It is processing several changes at once. E.g. user requests 
a set of roles. Some roles from this set are to be approved by approver 
A1, other roles by approver A2. We do not want to wait for both of them 
unless necessary (e.g. approver A2 may be on vacation), so So we split 
the request and the processing goes in parallel. What happens when both 
approvers approve the request at the same time? There may be two roles 
that add user to the same group (which is actually quite a common case). 
Yes, we can have complex coordination in midPoint that avoids concurrent 
writes to the server - even though that would be very difficult as 
midPoint can operate in multi-node cluster. But it is unnecessarily 
complex and even this complex thing does not entirely resolve the 
problem (see below). Currently in midPoint we are still doing the 
read-filter-write cycle with deltas just to lower the chance of this 
issue occuring. But that still does not guarantee success. E.g. both 
nodes read, both nodes decide that there is nothing to filter and both 
nodes write. Which results in error. So, in midPoint we had to implement 
quite complex error handling on top of that to make sure that we can 
handle all situations. Something tells me that other LDAP clients will 
not do that.

Please note that this case is not specific to midPoint. Any IDM has to 
do the same thing. E.g. the IDM will try to add a group, but the same 
group may be added at the same time using native administration tool in 
the application.

Anytime there is more than one client there is a risk of this happening. 
And as far as I know LDAP servers were designed especially to support 
many clients, weren't they?

> Bear in mind that maintaining group entries has a serious security impact!

Agreed. But how exactly is "security impact" influencing consistency 
model of the LDAP sever?

> Many years ago with brand new W2K there was a bug in MMC where the MMC client
> always replaced all values with a "new" set of values. That re-added group
> membership which was removed by another client instance before.

Well, that was really a bug in the client, wasn't it? And that's exactly 
what should be fixed in the client, right?
That's the reason why add/delete should be used instead or replace. But 
I'm talking about add/delete case here.

> BTW: Even when using the permissive modify control you would have to read the
> old entry for removing attribute values.

Why? I know the DN of the user and I know the DN of the group, why 
should I read the (potentially very long) list of all group members to 
make a simple operation?

--
Radovan Semancik
Software Architect
evolveum.com