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

[Nathaniel McCallum]

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.

Nathaniel