Re: "LDAP ease modify restrictions" support

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

On 02/22/2016 06:29 PM, Howard Chu wrote:
> Your logic is flawed: "Just because you may not get an error message 
> when something bad has happened, we want to *never* get an error 
> message when something bad has happened."

Yes and no. I do not care about the error. I just want my operation to 
proceed. It is actually very simple to do, isn't it? If the server 
really feels like it must indicate that it I'm doing a strange thing 
then I'm OK with that. I just want the operation to go on. I know what 
I'm doing.

> Automated or not, large scale distributed or not, if two 
> administrators are making overlapping changes to a single user's 
> privileges at the same time, you have a broken system.

No. I do not have broken system. There are many use cases when that is 
valid. E.g. single admin adding user to a group manually during and 
emergency situation. And later make that change legit by following the 
proper processes, which tries to add the used to the group again.  And 
it does not need to be a person doing that at all. When operation times 
out, you do not know if the request was processed or not. Most systems 
will re-try the operation. But if that operation was processed by the 
server then it will conflict with itself and end up with an error. Is 
that a broken system? That may happen even if there is no timeout. LDAP 
does not have distributed transactions, therefore the application may 
simply die between receiving an LDAP response and passing that 
information to upper layers. So the operation is likely to retry after 
restart. Or the information source and the LDAP may become inconsistent 
because someone simply screwed up. There are many ways how two databases 
on the network may become inconsistent. Too many. You say that if I 
consider inconsistency as a real possibility then my system is broken?

Yes, I can always read the entry first, compute changes and then modify 
it. But why do I need to do that? It takes two round trips and, client 
overhead and it does not guarantee a sucess anyway. Server can do that 
easily and reliably. Now, if my directory server is somewhere in the 
cloud tens of milliseconds away and I have millions of users to 
provision then each extra round-trip is a waste.

Yes, I do not need to read and entry. I just need to handle the 
resulting error. Then read the entry, modify the operation and retry. 
Maybe get the same error. Read entry again. And so on. Anyway, this is 
at least three round-trips instead of one. And it is strictly 
sequential. So, more waste. Yes, I do not need to do that for every 
entry. Only if I get a conflict. So if my data are fairly consistent 
this may a way to go. But that complicates the client. Good error 
handling is not easy to design and it is difficult to test properly. 
This is the hard way.

And now there is this simple and elegant control. It disables a 
"feature" that does not bring any benefit for me and it makes my life 
difficult. And the mere existence of that control means that obviously 
I'm not the only one having problem with this (in my opinion quite bad) 
part of LDAP spec. So why not use it?

> If you don't have distinctly delegated administration zones, and you 
> allow multiple admins to independently operate on the same population 
> of users, you can *never* know if your security definitions are 
> correct. Error messages of this nature are a clear indication that 
> your delegations are broken.

Yes and no. Yes, you do not know the state of all systems exactly at 
every moment. But if you want to satisfy this requirement then LDAP is 
not the right tool for you anyway. To do that you will need strict 
ACID-like consistency, you will have to sacrifice availability, you will 
most likely need distributed transactions, you will need to coordinate 
backup and restore operations with a complex restore and harmonization 
ceremonies - all the things that LDAP servers are not really great at. 
We really cannot have that in practice. I'm quite sure you realize that. 
So now we are only discussing how well we can approximate the state of 
the systems. You are proposing one solution, I have another solution. 
But both solutions are approximating. You say that my solution is wrong. 
I know that it is not. My solution only accepts what's out there. In 
reality it is very common that there are many admins working 
independently over the same population. There are many operations 
(sometimes conflicting) coming from many independent sources. It is one 
of fundamental assumption of my design. I do not need an error to tell 
me that. I already know that. And that reality is not something that can 
be changed easily (if it can be changed at all). And even if we can 
somehow magically change that, the security and organizational policies 
are often a moving target anyway. They are changing faster than the data 
can adapt to them. In reality it is not always possible to make strictly 
consistent deterministic IDM system. We have learned that lesson very 
early. It looks like a much more practical solution is to make system 
that continuously approximates the data and makes sure that it 
eventually converges. That's what we have chosen to do with midPoint. It 
works well. Very well. It is not broken.

So, let's get back to the original question: does OpenLDAP support the 
control? Do I need to configure something to enable it? That's all I need.

Thanks.

--
Radovan Semancik
Software Architect
evolveum.com