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

[Simo Sorce]

On Mon, 22 Sep 2014 21:21:04 +0200
Martin Kosek <mkosek at redhat.com> wrote:

> On 09/22/2014 04:55 PM, 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 ?
> >
> > Simo.
> 
> Ugh, no offense, but this approach sounds really ugly :-) I will wait
> for Thierry or Ludwig's assessment, but I still think there is either
> existing control for the modify operation to return an updated entry
> or we could create one as you suggest down the thread - as this may
> be useful for other use cases too.

See following mails, the right approach is to use the POST READ control.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York