[Freeipa-devel] Supported Staged entries

[Martin Kosek]

On 05/28/2014 03:06 PM, thierry bordaz wrote:
> 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

Right. Company/app may for example have a registration page where users can
fill their personal details. The page would only have privilege to add staged
users. Unstaging would then be made after authorization step (mail
verification, phone call, etc.).

Martin