[Freeipa-devel] Supported Staged entries

[Dmitri Pal]

On 05/28/2014 01:18 PM, Rob Crittenden wrote:
> 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

+1 I was actually suggesting this too.

>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.