[Freeipa-devel] User life cycle: changes in user plugin commands

[thierry bordaz]

On 03/27/2015 10:20 AM, Martin Kosek wrote:
> On 03/26/2015 10:32 PM, Dmitri Pal wrote:
>> On 03/26/2015 04:24 PM, thierry bordaz wrote:
>>> On 03/26/2015 08:53 PM, Dmitri Pal wrote:
>>>> On 03/26/2015 02:33 PM, thierry bordaz wrote:
>>>>> On 03/26/2015 04:21 PM, Martin Kosek wrote:
>>>>>> First, I think *this* thread should better be on freeipa-devel since it is
>>>>>> only
>>>>>> upstream feature specific, no planning inside.
>>>>>>
>>>>>> On 03/26/2015 02:02 PM, thierry bordaz wrote:
>>>>>>> On 03/26/2015 01:02 PM, David Kupka wrote:
>>>>>>>> Hi Thierry!
>>>>>>>>
>>>>>>>> On 03/26/2015 11:45 AM, thierry bordaz wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>>       In user life cycle, when a stage entry is activated it is moved from
>>>>>>>>>       a stage container to an active container.
>>>>>>>>>       Then when an active entry is deleted it is moved to a delete
>>>>>>>>> container.
>>>>>>>>>
>>>>>>>>>       The move stage->active is done by creating a new entry (ADD active,
>>>>>>>>>       DEL stage).
>>>>>>>>>       The move active->delete can be done with a MODRDN of the entry or
>>>>>>>>>       also ADD delete_entry + DEL active_entry.
>>>>>>>>>       I was wondering what is the best approach: MODRDN vs ADD-DEL.
>>>>>>>> Why did we choose ADD-DEL over MODRDN in stage->active procedure? Could we
>>>>>>>> use the same reasoning to repeat the choice?
>>>>>>> ADD-DEL was preferred (for activate) mainly because there are provisioning
>>>>>>> systems. So the stage entry can contain invalid values or missing some
>>>>>>> attributes/values. We need to rebuild a very clean entry, picking some
>>>>>>> values
>>>>>>> from the stage entry, if the values are valid.
>>>>>> The original proposal was MODRDN to also allow us control the operation with
>>>>>> the MODRDN ACIs you added to DS. You cannot really control DEL and ADD
>>>>>> operation together, so you would have to allow the person who activates the
>>>>>> entries to delete any staged user and add a new active user.
>>>>> I agree, MODRDN was the original proposal but finally ADD-DEL was choosen
>>>>> because entries added by provisioning system should be validated (in
>>>>> particular structural objectclass
>>>>> https://www.redhat.com/archives/freeipa-devel/2014-May/msg00471.html).
>>>>>
>>>>> That means that the helpdesk person that has rights to ADD on active
>>>>> container need DEL rights on staging.
>>>>> In fact MODRDN ACI brings an additional control, where the helpdesk person
>>>>> does not need that rights.
>>>>>> This is original section I added for this reasoning:
>>>>>> http://www.freeipa.org/index.php?title=V4/User_Life-Cycle_Management#MODRDN_vs._ADD-DEL
>>>>>>
>>>>>>
>>>>>> Why cannot the activate command be multistep? I.e. move the entry to active
>>>>>> users, generate missing fields and enable the entry? It could also trigger
>>>>>> automember for that user, we have commands for it.
>>>>> I think it is also feasible.
>>>>> Just a remark if the stage entry has a userpassword/krbPrincipalKey, at the
>>>>> time it is modrdn to active container we can authenticate with it.
>>>>> This even if all the initialization steps are not completed.
> In this case, I see the benefits for ADD-DEL. It would have to be done anyway,
> if structural objectclasses are added to the entry, right?
>
> Please just make sure to include the end result and reasoning to the cleaned
> wiki design.

Sure. I am doing this right now.
>
>>>>>>> For user-del, the active entry is valid, we just want to clear some
>>>>>>> attributes.
>>>>>>> Actually digging into the archive it was already discussed
>>>>>>> https://www.redhat.com/archives/freeipa-devel/2014-June/msg00080.html
>>>>>>> leading
>>>>>>> to MODRDN !
>>>>>> I would really prefer custom LDAP plugin that would do the processing of
>>>>>> delete
>>>>>> entry (re-add it or convert DEL to MODRDN, if possible). The reason is that
>>>>>> with this approach, people/software would be still able to use standard
>>>>>> ldapdelete operation to delete users instead of figuring out they need to
>>>>>> MODRDN it to some location to keep the company policies.
>>>>>>
>>>>>> The ticket 3911 says: [RFE] Allow managing users add/modify/*delete* via LDAP
>>>>>> client. With MODRDN DEL approach, you are breaking the delete part.
>>>>> That is right, using DS plugin it hides some complexity at the application
>>>>> level.
>>>>> If we introduce user-del options '--preserve|--permanent', we would need to
>>>>> give this option to the DEL (control ?).
>>>> Hm. I do not see it that way.
>>>> I see that command has two options do a MODRDN (--preserve) or DEL
>>>> (--permanent) depending on flags. This is the decision made in framework
>>>> before it hits DS. So I am not sure anything should be given to the control.
>>>> It would be invoked only in case of MOD. In case of DEL everything would
>>>> work as now. No?
>>> (adding freeipa-devel)
>>>
>>> If this is the application or CLI that decides what to do, I agree that
>>> --preserve will issue a MODRDN and --permanent a DEL.
>>>
>>> My understanding of Martin point, is that the application/CLI should not
>>> decide but just issue a DEL.
>>> This would be the job of a DS plugin to convert the DEL into a MODRDN (or
>>> ADD-DEL) to move the entry from active to delete container.
>>>
>>> In that case, DS plugin needs to decide if the DEL intend to preserve the
>>> entry (move to delete container) or permanently delete the entry (true ldap
>>> delete).
>>> I was wondering how to give to DS plugin the way to decide: configuration
>>> parameter, DEL control..
>> I see but this seem more complicated than what I propose and I do not see a
>> reason for the complexity.
> My main concern was that there may be software doing direct LDAP additions and
> modifications for the users. This is the reason why this ticket was opened. The
> software may ADD staging users, helpdesk would activate them and the software
> would DELete them at the end of the life cycle.
>
> In my proposal, to enable deleted users container, one just needs to switch a
> button and activate the DS plugin which would make DEL into a MODRDN.
>
> With your proposal, the application would need to be learned to do MODRDN
> instead of LDAP DEL - is that really feasible?
Applications that use to DEL active entries at the end of the life cycle 
would act as 'user-del --permanent'.
If they need to be ULC aware they will need to learn to do MODRDN to do 
a 'user-del --preserve'.
Now if the default mode is '--preserve' a DEL on active container should 
be rejected or be translated.
>
> Simo, do you have any preference here since your name was called out based on
> your note to do modrdn in
> https://www.redhat.com/archives/freeipa-devel/2014-June/msg00083.html
> ?
>
> Thanks,
> Martin