[Freeipa-devel] Supported Staged entries

[Simo Sorce]

On Tue, 2014-05-27 at 21:14 +0300, Alexander Bokovoy wrote:
> On Tue, 27 May 2014, Simo Sorce wrote:
> >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.
> I agree. It also opens us a way to handle import of any foreign schema
> person if staged object uses extensibleObject object class where we are
> in control of what exactly will get into the actual tree.

Right it allows us to do things like filter out objectclass or
attributes the provisioning system adds but that the admin does not want
in the final entry. This is not something we may want to build into the
solution from day zero, but it gives us the option to build it more
easily, as a framework filter on the 'unstage' operation.
(We so need to be able to copy additional objectclasses and their
attributes from day 0 though).
Simo.