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?