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.
--
Petr Vobornik

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

Reply via email to