[Freeipa-devel] Supported Staged entries

[Rob Crittenden]

Simo Sorce wrote:
> 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.
>

+1

This fits better into the plugin model as well since the container,
default objectclasses, etc will be different for these entries.

rob