On Tue, 16 Sep 2014 12:33:16 -0400 Nathaniel McCallum <npmccal...@redhat.com> wrote:
> 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. Nothing wrong, really, #1 is fine by me. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel