[Freeipa-devel] Supported Staged entries

Dmitri Pal dpal at redhat.com
Thu May 29 02:53:28 UTC 2014


On 05/28/2014 10:50 PM, Dmitri Pal wrote:
> 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.

I also do not like the term "unstage". This is not intuitive.
May be to create users (and other objects in future) from staging entry 
we should use 'ipa provision-user ...' command?

>
>>
>> _______________________________________________
>> 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.




More information about the Freeipa-devel mailing list