[Freeipa-devel] Stageuser API

[Alexander Bokovoy]

On ti, 17 tammi 2017, Martin Basti wrote:
>
>
>On 17.01.2017 12:38, Christian Heimes wrote:
>>On 2017-01-16 15:52, David Kupka wrote:
>>>Hello everyone!
>>>
>>>I've noticed that our API for stageuser is missing some commands that
>>>user has (stageuser-{add,remove}-{principal,cert}). I was wondering if
>>>there is reason for it but after asking some fellows developers it seems
>>>that there's none.
>>>
>>>I understand the stageuser area as a place where user entry can be
>>>created and amended during the hiring process in organization, example:
>>>
>>>1. HR creates the entry with just basic informations (givenname,
>>>surname, manager)
>>>2. IT assigns basic account information (uid, gid)
>>>3. based on to-be-employee manager's request IT adds additional group
>>>membership (memberOf)
>>>4. based on to-be-employee request IT adds login alias (krbPrincipalName)
>>>5. Security Officer adds certificate from Smart Card assigned to the
>>>to-be-employee
>>>6. HR adds extra information to the account (address, marital status, ...)
>>>7. Facilities update work place related information (seat number, phone
>>>number, ...)
>>>8. At the first day IT activates the user account.
>>>
>>>Considering this work flow I think it might be useful to have the same
>>>API for stageuser as for the user.
>>>
>>>Does the example work flow make sense?
>>>Should we provide the same set of commands for user and stageuser?
>>I see one potential issue in your proposal. A stage user does not
>>reserve its user name. The unique index on uid excludes the staging user
>>and deleted user branch. Therefore it is possible to create a user with
>>the same login name as a staging user.
>>
>>We either have to ensure that this name clash does not cause any trouble
>>with certificates or we have to enforce uniqueness of uid across the
>>whole tree. For FreeIPA it's probably fine because we compare certs
>>bytes. Third party applications parse the cert subject instead and use
>>the subject to identify a user.
>>
>>Christian
>>
>>
>>
>
>AFAIK the non-uniques of stageuser and user names causes more pain 
>than gain, this is not the first case when we have an issue with that. 
>Maybe we should reevaluate this behavior and enforce uid uniqueness 
>with stageusers too.
>
>Note: we explicitly updated uniqueness plugin to allow conflicting 
>names but I don't remember the reason from top of my head.
There might be workflows where an existing normal user would be deleted
and a new but completely separate stageuser would be promoted to a
normal one, both having the same name over an overlapping period of time.
In this case non-uniqueness requirement is needed.

This is a fairly common situation for English-speaking countries with
rather short common surnames and a typical username built out of a
first name + surname combination.



-- 
/ Alexander Bokovoy