On Tue, 2014-09-16 at 12:28 -0400, Simo Sorce wrote:
> On Tue, 16 Sep 2014 12:23:51 -0400
> Nathaniel McCallum <npmccal...@redhat.com> wrote:
> 
> > On Tue, 2014-09-16 at 12:22 -0400, Simo Sorce wrote:
> > > On Tue, 16 Sep 2014 11:52:43 -0400
> > > Nathaniel McCallum <npmccal...@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 ...
> > 
> > This would present a strange scenario where a token is created and
> > then reassigned to another user.
> 
> 
> The idea is to strip away the tail when visualizing to the user, so it
> wouldn't really bee seen ?
> Or perhaps the token can simply be renamed when assigned.

It just feels like a kludge to me. Also, automated stripping may run
afoul of names assigned by the imports.

What is wrong with the three options I provided above? We can do #1 now
and #2 or #3 later.

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

Reply via email to