[Freeipa-devel] Supported Staged entries

[Rob Crittenden]

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