[Freeipa-devel] Supported Staged entries

[Jan Cholasta]

On 28.5.2014 15:56, 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?
>
> Martin

Like I said in the other thread, I think managing staged users does not 
belong in the user plugin, as they are different object classes. So IMO 
we should either avoid it, or do it in a new plugin.

-- 
Jan Cholasta