[Freeipa-devel] Supported Staged entries

[thierry bordaz]

On 05/27/2014 04:35 PM, Martin Kosek wrote:
> On 05/27/2014 04:27 PM, Simo Sorce wrote:
>> On Tue, 2014-05-27 at 15:21 +0200, Martin Kosek wrote:
>>> This topic was already discussed in the past, see following part of
>>> the design:
>>>
>>> http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP
>>>
>>> One of the biggest concern was that to allow operator unstage a user,
>>> he would
>>> need to have a delete ACI in staging container AND add ACI in the
>>> active users
>>> area - which would also allow him to create any user he wishes in the
>>> users area.
>>>
>>> This is the reason why we preferred to do and control it via MODRDN
>>> and the
>>> reason why Thierry implemented the new ACI for controlling MODRDN
>>> operation:
>>>
>>> https://fedorahosted.org/389/ticket/47553
>>>
>> I know that's why we did it, but I had a hard look since then, and I
>> believe we cannot really use that method.
>>
>> The reason is simply that we do not control who adds the user object and
>> our reason to do the staging is to make it simple for an external
>> provisioning system to create a basic user entry the way it knows how
>> to, with only the attributes the provisioning system cares about.
>>
>> But this means we have no guarantee of what objectclasses are available
>> on the object, so we have no guarantees all the necessary structureal
>> objectclasses have been added in the staging object.
>>
>> We have to recreate the user object in order to be able to add all the
>> right structural objectclasses as those can only be added at object
>> creation time in an LDAPv3 compliant LDAP server.
Both approach looks possible:

  * adding required structural OC+AT in the existing entry
  * creating a new entry with all structural OC+AT and update the AT
    values with what exists in the stage entry

but I think the second one would be simpler to implement.
Here again uid uniqueness is a difficulty: if 'uid' exists in stage 
entry we need to delete the stage entry before adding the active one.
There is a risk to loose the entry if the add fails. Also it is 
important to apply DEL/ADD on the same replica so that DEL csn < ADD csn.

>>
>> Recreating the object will also allow you to deal with the other case
>> you brought forward where the provisioning system used CN as the RDN,
>> but we want uid.

I am not sure: if some provisioning systems created the two entries

# entry 1
dn: ou=TestUser,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com
objectClass: top
objectClass: account
uid: xxx
ou: TestUser

# entry 2
dn: uid=TestUser,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com
objectClass: top
objectClass: posixAccount
cn: TestUser
uid: TestUser
ipaUniqueID: autogenerate
uidNumber: -1
gidNumber: -1


If we activate both entries. we will create a new entry with all the required objectclass but at the end we will need to pick up a 'uid' value.
Entry 2 will keep its 'uid'. Entry 1 we have two solutions, 'xxx' but then it changes the RDN value or 'TestUser' (the former RDN value) that is in collision with entry 2.

I think it would simplify the problem if we enforce that staged entries have 'uid' RDN.


>>
>> I understand it gives operators a higher privilege, but I think we'll
>> have to think harder how to properly handle the issue.
A possibility is to create a "pre-active" status, between 'stage' and 
'active'.
The 'stage' container contains raw provisioned entries. 'pre-active' a 
copy of the 'stage' entry with all the structural objectclasses.

If 'pre-active' is out of the scope of uid uniqueness, we can add the 
'pre-active' entry before removing the 'stage' entry (and rollback in 
case of failure). Then do a MODRDN (with appropriate aci) 'pre-active' 
-> 'active'.


>>
>> Perhaps the best way is to create a new "proxy-API" to "promote" users
>> from a staging area. This service will have the privilege to create
>> users using its own credentials instead of those of the operator.
>>
>> This can be done later, meanwhile we will have to accept operators need
>> the privilege to create users.
>>
>> Simo.
> Ok, the point about structural objectclasses is a strong one. Thierry, you what
> to do - this should be noted in the design page...
>
> Martin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20140527/565b5470/attachment.htm>