[Freeipa-devel] Supported Staged entries

[Alexander Bokovoy]

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.
-- 
/ Alexander Bokovoy