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


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

Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to