[Freeipa-devel] [PATCH 0069] Adds 389DS plugin to enforce UUID token IDs

[Rich Megginson]

On 09/22/2014 09:14 AM, Nathaniel McCallum wrote:
> On Mon, 2014-09-22 at 10:55 -0400, Simo Sorce wrote:
>> On Mon, 22 Sep 2014 10:02:01 -0400
>> Nathaniel McCallum <npmccallum at redhat.com> wrote:
>>
>>> On Mon, 2014-09-22 at 09:50 -0400, Simo Sorce wrote:
>>>> On Mon, 22 Sep 2014 10:34:54 +0200
>>>> Martin Kosek <mkosek at redhat.com> wrote:
>>>>
>>>>> On 09/22/2014 09:33 AM, thierry bordaz wrote:
>>>>>> Hello Nathaniel,
>>>>>>
>>>>>>     Just a remark, in is_token if the entry is
>>>>>> objectclass=ipaToken it returns without freeing the
>>>>>> 'objectclass' char array.
>>>>>>
>>>>>>     thanks
>>>>>>     thierry
>>>>>>
>>>>>> On 09/21/2014 09:07 PM, Nathaniel McCallum wrote:
>>>>>>> Users that can rename the token (such as admins) can also
>>>>>>> create non-UUID token names.
>>>>>>>
>>>>>>> https://fedorahosted.org/freeipa/ticket/4456
>>>>>>>
>>>>>>> NOTE: this patch is an alternate approach to my patch 0065.
>>>>>>> This version has two main advantages compared to 0065:
>>>>>>> 1. Permissions are more flexible (not tied to the admin group).
>>>>>>> 2. Enforcement occurs at the DS-level
>>>>>>>
>>>>>>> It should also be noted that this patch does not enforce UUID
>>>>>>> randomness, only syntax. Users can still specify a token ID so
>>>>>>> long as it is in UUID format.
>>>>>>>
>>>>>>> Nathaniel
>>>>> I am still thinking we may be overcomplicating it. Why cannot we
>>>>> use the similar UUID generation mechanism as we do for SUDO
>>>>> commands for example:
>>>>>
>>>>> # ipa sudocmd-add barbar --all --raw
>>>>> ---------------------------
>>>>> Added Sudo Command "barbar"
>>>>> ---------------------------
>>>>>    dn:
>>>>> ipaUniqueID=3a96de14-4232-11e4-9d66-001a4a104ec9,cn=sudocmds,cn=sudo,dc=mkosek-fedora20,dc=test
>>>>>    sudocmd: barbar
>>>>>    ipaUniqueID: 3a96de14-4232-11e4-9d66-001a4a104ec9
>>>>>    objectClass: ipasudocmd
>>>>>    objectClass: ipaobject
>>>>>
>>>>> It lets DS generate&rename the object's DN when it finds out that
>>>>> the ipaUniqueID is set to "autogenerate" (in baseldap.py). We
>>>>> could let DS generate the UUID and only add the "autogenerate"
>>>>> keyword in otptoken-add command.
>>>>>
>>>>> For authorization, we can simply allow users to only add tokens
>>>>> with "autogenerate" ID, see my example here:
>>>>>
>>>>> http://www.redhat.com/archives/freeipa-devel/2014-September/msg00438.html
>>>>>
>>>>> Admin's or special privilege-owners would have more generous ACI
>>>>> allowing other values than just "autogenerate".
>>>>>
>>>>> IMO, then the whole ipatoken-add mechanism would be a lot simpler
>>>>> and we would not need a special DS plugin (unless we want regular
>>>>> users to generate their own UUIDs instead of letting IPA DS to
>>>>> generate it
>>>>> - which I do not think is the case).
>>>> Good point Martin.
>>> This is the avenue I first pursued. The problem is that the client has
>>> no way to look up the DN after the entry is added. In the case of
>>> sudocmd-add, the lookup is performed using the sudocmd attribute (see
>>> sudocmd.get_dn()). We have no similar attribute in this case and the
>>> lookup cannot be performed.
>> Well in theory we could search with creatorName and createTimestamp set
>> to the user's own DN and a range a few seconds in the past ...
>> It is not robust if you add multiple tokens at the same time, but would
>> this be a concern for user created tokens ?
> That would fundamentally break the import script in which many tokens
> are being created by the same user rapidly.
>
> In a phone call with mkosek, we tossed around the idea of framework
> support for a (preexisting?) control which notifies the client of
> changes to the operation. This would notify the client that the
> ipatokenUniqueID changed from "autogenerate" to
> "86725e75-a307-4c10-9de5-3ce15b963552". This would resolve all
> ambiguity.

What about the POST READ control?  The purpose of this control is to 
return the contents of the entry (e.g. what would be returned by an LDAP 
search request) after the update has been applied.

>
> Nathaniel
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel