[Freeipa-devel] Supported Staged entries

[thierry bordaz]

On 05/28/2014 02:55 PM, Rob Crittenden wrote:
> 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
>
I agree, FreeIPA CLI or API will create valid entry.

Now a staging area can be used for storing entries waiting for an 
approval. For an example, a cron job scanning the stage container may 
send request to an approver. The approver having the ability to read the 
'stage' entry will issue 'ipa user-unstage' or not.

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