On 17/01/17 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




Hi Christian,
uniqueness of uid is not checked in staging area on purpose, it may be changed multiple times before the stageuser is transformed into user (activated). The uid uniqueness is then checked during activation.

Third party application that use FreeIPA's LDAP should:
1) search for users (and usercertificate attribute) only in cn=users,cn=accounts 2) respect the value of nsAccountLock that is set to true for all staged users.

But it would be nice to have this scenario (stageuser.uid == user.uid) implemented as a part of [1].

[1] https://fedorahosted.org/freeipa/ticket/6615

--
David Kupka

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

Reply via email to