[Freeipa-devel] Supported Staged entries

[thierry bordaz]

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 ?

thanks
thierry

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20140528/d153f67e/attachment.htm>