[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: "LDAP ease modify restrictions" support



Radovan Semancik wrote:
> 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 need a rationale for both clients succeeding for this same operation.

BTW: You would have to further specify what "same operation" really means in detail.

> But OK, let's get more specific. Consider this example: midPoint is an IDM
> system.

Yes, I saw your presentation at LDAPcon.

> 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.

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.

> Something tells me that other LDAP clients
> will not do that.

Yes for sure, there are many stupid LDAP clients out there.

> Please note that this case is not specific to midPoint. Any IDM has to do the
> same thing.

Yes.

>> 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?

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.

>> 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.

You have to define more details of what you're really doing.

As said: It' sane to add/remove distinct attribute values and you can do that
concurrently. You don't need permissive modify control for that.

>> 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?

I don't know the operations sent by your client. Either I have some doubts that
you need permissive modify control at all or I have some doubts that your client
does things right. Choose yourself.

But hey, you don't have to follow my advice. Just try and see yourself.

Ciao, Michael.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature