[Freeipa-devel] User life cycle: question regarding the design

[Martin Kosek]

On 06/02/2014 12:19 PM, thierry bordaz wrote:
> On 05/30/2014 03:32 PM, Jan Cholasta wrote:
>> On 30.5.2014 15:24, Petr Viktorin wrote:
>>> On 05/30/2014 08:37 AM, Martin Kosek wrote:
>>>> On 05/29/2014 08:14 PM, Dmitri Pal wrote:
>>>>> On 05/29/2014 08:39 AM, Simo Sorce wrote:
>>>>>> On Thu, 2014-05-29 at 09:43 +0200, Martin Kosek wrote:
>>>>>>> On 05/29/2014 05:31 AM, Dmitri Pal wrote:
>>>>>>>> On 05/26/2014 01:49 AM, Martin Kosek wrote:
>>>>>>>>> On 05/23/2014 04:55 PM, Simo Sorce wrote:
>>>>>>>>>> On Fri, 2014-05-23 at 10:13 -0400, Rob Crittenden wrote:
>>>>>>>>>>> This, I believe, has already been covered, but I'm concerned
>>>>>>>>>>> with the
>>>>>>>>>>> (over)use of active/inactive in this discussion.
>>>>>>>>>>>
>>>>>>>>>>> I think use of "inactive" and "active" to describe users might be
>>>>>>>>>>> confusing since there is already an account enable/disable
>>>>>>>>>>> command.
>>>>>>>>>>> This
>>>>>>>>>>> on top of unlock, are there now 3 possible boolean states a
>>>>>>>>>>> user can
>>>>>>>>>>> be
>>>>>>>>>>> in? locked/unlocked, enabled/disabled, active/inactive, plus
>>>>>>>>>>> deleted/active and staged/active?
>>>>>>>>>>>
>>>>>>>>>> Agree, we should only have "ipa user-unstage <username>" and not
>>>>>>>>>> call
>>>>>>>>>> this operations with words like active/inactive.
>>>>>>>>>>
>>>>>>>>>> User's in the staging area are not inactive, they are *not*
>>>>>>>>>> users yet in
>>>>>>>>>> the first place.
>>>>>>>>>>
>>>>>>>>>> Simo.
>>>>>>>>>>
>>>>>>>>> Ok. Let us consolidate the decisions, I think we are now running
>>>>>>>>> in circles.
>>>>>>>>> Let me start from Petr3's API proposal which was a functionally
>>>>>>>>> complete
>>>>>>>>> proposal and start from there:
>>>>>>>>>
>>>>>>>>> On 05/22/2014 10:47 AM, Petr Viktorin wrote:
>>>>>>>>>> ...
>>>>>>>>>> My proposal would be that the move commands use the verb for the
>>>>>>>>>> target
>>>>>>>>>> and an
>>>>>>>>>> option for the source, and add/mod use an option for the container:
>>>>>>>>>>
>>>>>>>>>> 1) adding a new user
>>>>>>>>>> (to active)   ipa user-add tuser ...
>>>>>>>>>> (to stage)    ipa user-add tuser --staged ...
>>>>>>>>> Ok.
>>>>>>>>>
>>>>>>>>>> (to deleted)  ipa user-add tuser --deleted ...  (*)
>>>>>>>>> Not needed.
>>>>>>>>>
>>>>>>>>>> 2) moving to main
>>>>>>>>>> (from stage)  ipa user-activate tuser  (**)
>>>>>>>>>> (from del)    ipa user-activate tuser --deleted
>>>>>>>>> We need both, alternative is Simo's proposal:
>>>>>>>>>
>>>>>>>>> ipa user-unstage
>>>>>>>>> ipa user-undelete
>>>>>>>>>
>>>>>>>>> I personally like unstage and undelete commands, I would go with
>>>>>>>>> those.
>>>>>>>> Sorry for coming late to the party.
>>>>>>>> I strongly do not like "unstage"
>>>>>>>> This suggests that the user will be removed from staged but does
>>>>>>>> not indicate
>>>>>>>> that the full user will be created.
>>>>>>>> As I suggested elsewhere provision-user or user-provision (or may
>>>>>>>> be even
>>>>>>>> user-add --from-stage) would be better.
>>>>>>> As Petr3 already noted on 05/19/2014 03:19 PM, integrating
>>>>>>> unstaging operation
>>>>>>> could get messy and would not create the right API. Using a
>>>>>>> separate call would
>>>>>>> be cleaner. As we see, choosing the right action term has proven
>>>>>>> very difficult
>>>>>>> - everyone has strong opinion on the command name :-)
>>>>>>>
>>>>>>> I already saw user-activate and user-unstage to be trashed so I am
>>>>>>> thinking
>>>>>>> what we are left with. I am still fan of user-unstage,
>>>>>>> user-provision is not
>>>>>>> telling me much more than user-unstage.
>>>>>>>
>>>>>>>>>> 3) moving to deleted
>>>>>>>>>> (from active) ipa user-del tuser
>>>>>>>>> Ok.
>>>>>>>>>
>>>>>>>>>> (from stage)  ipa user-del tuser --staged
>>>>>>>>> IMO staged deleted users should not be moved to deleted
>>>>>>>>> container, but simply
>>>>>>>>> permanently deleted. As Simo noted, staged user are not real
>>>>>>>>> users, just
>>>>>>>>> incomplete users.
>>>>>>>>>
>>>>>>>>>> 4) moving to stage
>>>>>>>>>> (from active) ipa user-stage tuser
>>>>>>>>
>>>>>>>> This was suggested for completeness.
>>>>>>>> I think we are cutting corners but I would not insist here.
>>>>>>>>
>>>>>>>>>> (from del)    ipa user-stage tuser --deleted
>>>>>>>>> None of the commands are needed for the basic workflow.
>>>>>>>> But this is a valid use case. I created a user, deleted it and
>>>>>>>> want to rebuild
>>>>>>>> it becuase something got corrupted in the original entry. I agree
>>>>>>>> it is not a
>>>>>>>> primary use case but then we should have a ticket to track this
>>>>>>>> RFE for
>>>>>>>> future.
>>>>>>> This was not about cutting corners, this was about what operation
>>>>>>> makes sense
>>>>>>> and what we should support. Stage was defined as a tree with
>>>>>>> incomplete user,
>>>>>>> thus this proposal - Simo was not very OK with this workflow.
>>>>>>>
>>>>>>>>>> 5) modifying
>>>>>>>>>> (in active)   ipa user-mod tuser ...
>>>>>>>>> Ok.
>>>>>>>>>
>>>>>>>>>> (in stage)    ipa user-mod tuser --staged ...
>>>>>>>>> Simo did not like this command, I would personally add it. As
>>>>>>>>> long as we have
>>>>>>>>> "ipa user-add --staged", we should also have an option to delete
>>>>>>>>> and modify
>>>>>>>>> user in staged area.
>>>>>>>>>
>>>>>>>>>> (in del)      ipa user-mod tuser --deleted ...
>>>>>>>>> Not needed.
>>>>>>>>>
>>>>>>>>> Is this acceptable for everyone? If yes, the next step would be
>>>>>>>>> for Thierry
>>>>>>>>> to update the design page with new proposals.
>>>>>>>>>
>>>>>>>>> Martin
>>>>>>> Let me try to consolidate again the proposals and changes for the
>>>>>>> workflow&API
>>>>>>> we have so far:
>>>>>>>
>>>>>>> 1) Manipulating staged users
>>>>>>> - staged users must have UID RDN
>>>>>>> - UID uniqueness plugin should not be enforcing in staging area
>>>>>>> - we do not want it in user plugin as it requires different
>>>>>>> parameters and
>>>>>>> objectclasses
>>>>>>> - API:
>>>>>>> ipa stage-user-add
>>>>>>> ipa stage-user-mod
>>>>>>> ipa stage-user-find
>>>>>>> ipa stage-user-del
>>>>>>>
>>>>>>> 2) Activating staged user
>>>>>>> - activation will not do MODRDN, it will create a new user in
>>>>>>> active container
>>>>>>> and then delete the old one (to create right structural objectclass
>>>>>>> set)
>>>>>>> - for now, we need to allow operator delete any user in staged and
>>>>>>> add any user
>>>>>>> in active tree
>>>>>>> - API
>>>>>>> ipa stage-user-activate
>>>>>>> - other options mentioned in the past were user-unstage and
>>>>>>> user-activate
>>>>>>>
>>>>>>> 3) Manipulating deleted users
>>>>>>> - deletion and undeletion will do MODRDN and will use the ACI that
>>>>>>> Thierry
>>>>>>> implemented
>>>>>>> - API
>>>>>>> ipa user-del
>>>>>>> ipa user-undel OR ipa user-undelete
>>>>>>> - Dmitri mentioned that he would like to see the move from deleted
>>>>>>> to staged. I
>>>>>>> would do it via flag:
>>>>>>> ipa user-undel --to-stage
>>>>>>>
>>>>>>>
>>>>>>> Does that look better now? Thanks,
>>>>>> Yes, although I do not see the need for --to-stage honestly.
>>>>> I agree we can just leave it as a future ticket.
>>>>
>>>> I think Simo's thoughts were different - he did not opposed to this part
>>>> because it is too much work (it shouldn't be), but because he did not
>>>> want that
>>>> part of the workflow. Given the simplicity of this part, I see 2 options:
>>>> 1) Do it and do it together with other API is it just one MODRDN command
>>>> 2) Decide we do not want to do it, i.e. do not file any RFE
>>>>
>>>>> Rest looks OK.
>>>>
>>>> It should be fine, just one command could done differently to confine
>>>> it better
>>>> as per Honza's idea:
>>>>
>>>> ipa stageduser-add --from-deleted username
>>>
>>> Do we want that to take all of stageduser-add's options?
>>> Should we use somrthing like stageduser-undel instead?
>>
>> stageduser-undel suggests it's opposite of stageduser-del, which it is not.
>> An alternative would be something like stageduser-add-from-deleted, but
>> that's really long, hence my proposal to use stageduser-add.
> 
> I have also a preference for '--from-deleted' option rather than a new verb.
> IMHO 'Delete' -> 'Stage' would be a quite rare and using an option shows that
> it is a special case.
> 
> 
> 
> Regarding generate attribute, Delete users have final unique value
> (ipaUniqueID, uidNumber..) should we return the values to standard "staging"
> values ('autogenerate', -1) ? I believe yes.

I do not think you want UID and GID reset when you undelete a user or move it
to staging tree by default. When a person that left a company returns, you want
him to be able to access his old files etc.

Same for ipaUniqueID, I do not see value in resetting it when we are dealing
with the same user.

> Also a Deleted user is booking an ipaUniqueID/uidNumber value, so an other
> active entry can not use these values. If we move that user out of the scope of
> attribute uniqueness, an other staging entry may pick up these values. Is it a
> risk ?

It is a risk. But I am thinking that given that
- the user should be in a staging area for a limited period time
- DNA plugin will not re-use this number for new users anyway if not instructed
differently
- DS will prevent moving entry to active tree if there is another user with the
same UID

it is acceptable.

> For example, if on a machine I authenticate with entry A that contains values
> identical from old entry B, may I get the entry B authorisations on an other
> machine (where deletion of entry B has not yet occur) ?

I think we are over-complicating the issue. This should not happen if
replication is OK. If replication is not OK, you could as well authenticate
with entry A which was already deleted on other replica.

Martin