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.
I'm not sure what the use case for this is either, other than simplifying testing. If you have access to the IPA API then why bother staging a user? rob _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel