[Freeipa-devel] Supported Staged entries

[Simo Sorce]

On Wed, 2014-05-28 at 15:56 +0200, Martin Kosek wrote:
> On 05/28/2014 02:48 PM, Simo Sorce wrote:
> > 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.
> 
> /me wishes that the major concerns were spelled out during initial RFE review...
> 
> Could this help a custom provisioning system that uses FreeIPA user-add
> JSON-RPC command instead of ldapadd? The record may still be incomplete in
> terms of company policy (e.g. missing manager) and about to be moved only when
> the user joins the company?
> 
> Or is this nonsense and we should avoid doing user-add/user-mod/user-del in the
> staging area?

Note that I did not say we should not have an IPA command for that, but
I dislike the idea of putting it in the user plugin and using that
specific command expression.

I would see something like ipa stage-user-add <username> as a better way
to go, in its own "stage" plugin.

Simo.