[Freeipa-devel] Proposal for #4456 -- Regular users should not be able to add OTP tokens with custom name

[Simo Sorce]

On Tue, 16 Sep 2014 11:52:43 -0400
Nathaniel McCallum <npmccallum at redhat.com> wrote:

> On Tue, 2014-09-16 at 17:51 +0200, Petr Vobornik wrote:
> > On 16.9.2014 17:26, Nathaniel McCallum wrote:
> > > On Tue, 2014-08-19 at 17:10 -0400, Nathaniel McCallum wrote:
> > >> Admins need the ability to specify the token ID in the case of
> > >> imports. However, generally, this ability is not needed.
> > >>
> > >> Is it possible to offload the ID generation to the ipa-uuid
> > >> plugin? I'm not quite sure how to enable this (I think it
> > >> involves passing a magic value?). But I'm not quite sure how
> > >> this fits in with the IPA framework as the generated value is
> > >> the DN.
> > >>
> > >> However, assuming this can be used, I propose the following. The
> > >> token ID is removed from the UI for regular users (but retained
> > >> for admins). We change the ACIs for token addition/modification
> > >> to prevent regular users from specifying the ID in an add or mod
> > >> operation. The CLI would retain the option to set it, but this
> > >> option would only be usable by admins.
> > >>
> > >> Make sense?
> > >
> > > Nobody has responded to this. :)
> > >
> > > However, since investigating it a bit more, this approach won't
> > > really work without further effort. Here is the problem.
> > >
> > > First, the UUID plugin doesn't currently support this kind of
> > > operation. Either it needs to be modified or a new plugin needs
> > > to be created.
> > >
> > > Second, the client needs to know the ID in order to generate the
> > > token URI. If we generate the UUID inside the DS, the UUID is
> > > unknown to the client and the URI can't be generated. This would
> > > mean a new control.
> > >
> > > As I see it we have three options:
> > > 1. Remove the option to specify the ipatokenUniqueID from the
> > > GUI. Don't make any change in the CLI.
> > >
> > > ENFORCEMENT: none
> > > EFFORT: low
> > >
> > > 2. Perform a server-side check for admin membership. Raise an
> > > exception if the ipatokenUniqueID is specified and the user is
> > > not an admin.
> > >
> > > ENFORCEMENT: API-level
> > > EFFORT: medium
> > >
> > > 3. Modify otptoken-add to create tokens with a magical
> > > ipatokenUniqueID value by default. An ACI would prevent normal
> > > users from adding tokens without this magic value. Create/modify
> > > a plugin to generate UUIDs when the magic value is found. Send a
> > > control back to the client indicating the real ipatokenUniqueID
> > > value. Modify otptoken-add to read this control.
> > >
> > > ENFORCEMENT: DS-level
> > > EFFORT: high
> > >
> > > I think my preference for now is #1. Thoughts?
> > >
> > > Nathaniel
> > >
> > 
> > I want to raise a question if we really want to disable this
> > feature for normal users. Wouldn't it be better to improve error
> > message or check if the name is taken?
> > 
> > UUID is the value which is displayed in the Soft. Token application
> > as name. Sure, one can rename it there to match the description in
> > IPA but that seems quite unpleasant to me. Also user has to know
> > that he can rename the token in FreeOTP,....
> > 
> > Atm the existence check might be little problematic - disclose of 
> > information which is not readable to user by default. But current
> > state is basically it, just unfriendly.
> 
> The existence check is impossible: users can't see tokens they don't
> own.

Why don't we simply allow user to use an arbitrary name of their
choosing (or a random string if not specified) and then append their
uid string to it in the UI ?

I wonder if we have ACIs where the value must match a pattern defined
by the bound user ...

Simo.

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