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"
  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:


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


Freeipa-devel mailing list

Reply via email to