[Freeipa-devel] Supported Staged entries

[Simo Sorce]

On Wed, 2014-05-28 at 09:38 +0200, thierry bordaz wrote:
> On 05/28/2014 08:22 AM, Martin Kosek wrote:
> > On 05/27/2014 08:18 PM, Simo Sorce wrote:
> >> 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.
> > Ok, thanks guys, I see an agreement. Thierry, we should now update all the
> > information here:
> >
> > http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP
> >
> > (you can even link this thread in the archives)
> >
> > Martin
> Yes I will do that.
> 
> Regarding workflow, it looks a priority that active entries are valid 
> (regarding FreeIPA).
> Currently CLI offers:
> 
>   * ipa user-add (in active)
>   * ipa user-add --stage (in stage).
> 
> In order to prevent admin to add a corrupted entry in active and force 
> any entry to go through the filter of objectclass/attribute, we could 
> make 'ipa user-add' to create entry in staging and 'ipa user-add 
> --active' to create entry in active. Even more, should we support to add 
> entry directly in 'active' or rather only support 'user-add' to go only 
> in staging ?

I do not see why this would ever be necessary, ipa user-add cannot
create a "corrupt entry" by definition.

I am actually not very happy with the "ipa user-add --stage" idea, the
staging area is necessary for when you do not create a full 'ipa' user
entry, but rather for when a provisioning system creates an "incomplete"
entry.

Simo.