[Freeipa-devel] Supported Staged entries

[Simo Sorce]

On Tue, 2014-05-27 at 19:59 +0200, thierry bordaz wrote:
> On 05/27/2014 06:56 PM, Simo Sorce wrote:
> > On Tue, 2014-05-27 at 18:39 +0200, thierry bordaz wrote:
> >> On 05/27/2014 06:06 PM, Simo Sorce wrote:
> >>> We just need to care about the 'uid' attribute in the staged entry, and
> >>> pick that to generate the RDN of the user in the active tree. If there
> >>> are conflicts the 'unstage' will fail cleanly, as the 'add' operation
> >>> will just fail (due to non unique RDN) and the admin will have to take
> >>> care of the situation.
> >> In that case the provisioning system created a staging entry
> >> ou=TestUser,$STAGING, it will get an active entry uid=xxx,$ACTIVE
> >> It could be an issue for the provisioning system to retrieve the entry
> >> it created.
> > Too bad for the provisioning system, we are not going to allow users to
> > have a form that does not use uid in the RDN in IPA.
> >
> >>> Sounds like a lot of complexity for a problem we do not really have, all
> >>> we need is to not enforce uniqueness in staging.
> >> This proposal was also to limit the operator privilege to do MODRDN from
> >> 'pre-active' to 'active', instead  ADD on 'active'.
> > It is not useful, the operator still needs to be able to create in
> > pre-active ... so it can still create what it wants.
> 
> yes that is correct.
> Does it address the security concern, if the operator that is allowed to 
> add in 'staging'/'pre-active' is different from the one allowed to move 
> the entry in 'active' ?

Well it really depends on 'who' the operator is.

We would like to be able to allow a 'junior admin/helpdesk person' to
just press a button to activate a user, but that shouldn't drive our
design if it makes other things clumsy or suboptimal.

The less privileged operator problem can always be solved by a
middle-man script that has higher privileges. So we nee to give priority
to getting the workflow right in terms of the way it works.

I think re-creating the user object gives us better chances at handling
the overall workflow and fixing up entries accordingly to the management
framework view of what a user needs to look like, so in the end I prefer
that route.

Simo.