Re: "LDAP ease modify restrictions" support

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

On 02/22/2016 04:07 PM, Michael Ströder wrote:
> Radovan Semancik wrote:
> > On 02/22/2016 02:13 PM, Michael Ströder wrote:
> > > There's no way around having decent error handling anyway. Permissive modify
> > > control won't help you there in general. And catching attributeOrValueExists and
> > > gracefully handle it is not a big deal.
> > [..]
> > But most importantly: I would rather like that error handling is trigged only if
> > there is an actual error. MidPoint does a very good error handling. But having
> > logfile full of errors that are in fact just a pretty normal operation is not a
> > nice thing.
> Whether LDAP result code attributeOrValueExists is treated as an error or just
> logged as "nothing to be seen here" is up to your code, isn't it?

Depends on a layer. The operation will always be logged as LDAP error 
response. The connector also does not know whether it is real error or 
not. We are keeping connectors very simple. So it also get logger in the 
ConnId as an error. Even if the situation is later handler correctly, 
the errors are there. Sometimes you cannot entirely control what gets 
logged if you are using libraries that you are not maintaining yourself. 
And who in the opensource world is using just their own stuff?

> For various reasons bulk updates should be a different thing if you need to
> support concurrent operation.

I do not think so. The less exceptions are there the better.

> BTW: If a single role change leads to write operations to more than entry you
> would need LDAP transaction support to really ensure atomicity of that single
> role change.

Not really. I do not need atomicity. I just need eventual consistency. I 
can get that without transactions.

> > > As said: I've decided to handle groups in web2ldap in specific way and to
> > > provoke failure for concurrent writes based on stale data in general.
> > Yes, but if you "provoke" a failure you have to be sure that other components in
> > the system can handle that failure well.
> Yes. In case of web2ldap it even means handling the error in the UI.

Well, that might be enough for web2ldap. But we are a "self-healing" 
system. Even non-technical end users are using it (e.g. requesting and 
approving roles). Reporting this error to end user does not really help. 
And it won't work even if we report it to the admin. Bothering admins 
with any minor issue just won't scale.

> > Anyway, what is actually the problem with operation that adds value that is
> > already there? Why it should fail at all? It will not change the final state.
> If you ensure that you're not re-adding old group membership relations then
> everything's fine.

The thing is that you do not know. If you re-add old group membership 
you will actually NOT get the error. If you are adding existing group 
membership you will get the error. Strange, isn't it? Not very useful.

> Still I think you don't need it. And as developer of a general-purpose IDM you
> can't rely on this proprietary control to be supported by the LDAP server. Hence
> you need the error handling in your code anyway.

We have it already. But I would like to avoid triggering the code unless 
really necessary. So, midPoint will look nicely and efficiently when 
working with nice LDAP servers. And when working with nasty LDAP servers 
the logfiles will be full of messages describing handled errors and 
there will be a lot of additional round-trips. I'm OK with that. The 
people that choose bad LDAP servers deserve to suffer :-) .... Anyway, 
this is much better than being equally nasty with all the LDAP servers.

> > The problem are operations that add and remove the same value at the same time.
> Of course a second user interacting with your UI could revert the changes made
> by a first user. There's nothing you could do about that.

Exactly.

> > Or operations that replace the values. But the attributeOrValueExists error is
> > not going to help here.
> We have to distinguish various write operations in detail:
> attributeOrValueExists (for MOD_ADD) and its counterpart noSuchAttribute (for
> MOD_DELETE) solely helps if your modify request only contains *single* attribute
> values.

Not even in that case. E.g. see above. You will not get the error if you 
are re-adding a group that was deleted just a millisecond ago just 
because the network latencies haven't turned up in your favor.

So, the implication "error => something wrong happened" does not hold. 
And the implication "something wrong happened => error" does not hold 
either. So, what the error really says is:

"Hey there! Maybe something wrong happened. Or maybe not. It may all be 
OK. There is no way to be sure. So forget it. I just wanted to talk to 
you. Sorry to bother you. And, by the way, your operation failed. Just 
for fun. Try something else. I won't tell you what. Go figure. Bye."

How useful is that?

> I think we mostly agree on the general issues.
>
> But we agree to disagree whether permissive modify control is part of a solution
> or will mask serious security issues. Personally I prefer to let problems/error
> happen and then explicitly ignore them if I'm 100% sure it's ok. So personally I
> wouldn't use permissive modify control. YMMV.

Correct. But this specific thing will not help you. Because the error 
may happen when everything is OK. And even worse: it might NOT happen if 
there is a real problem. Relying on that error makes no sense. And in 
fact it might be even dangerous. This is a bad trade-off. Very bad.

--
Radovan Semancik
Software Architect
evolveum.com