[Freeipa-devel] [PATCH] 531-541 OTP UI

[Petr Vobornik]

On 27.2.2014 16:51, Nathaniel McCallum wrote:
> On Thu, 2014-02-27 at 13:35 +0100, Petr Vobornik wrote:
>> On 21.2.2014 15:24, Petr Vobornik wrote:
>>> On 10.2.2014 14:12, Petr Vobornik wrote:
>>>> On 13.1.2014 17:09, Petr Vobornik wrote:
>>>>> Hi,
>>>>>
>>>>> these patches implements the OTP Web UI.
>>>>>
>>>>> Last 5 patches is the OTP UI.
>>>>>
>>>>> First 6 patches is a little refactoring/bug fixes needed for them.
>>>>> General password dialog is introduced to avoid another implementation.
>>>>>
>>>>> Self-service UI is implemented to be very simple. Atm user can choose
>>>>> only token name. Admin interface allows to enter all values.
>>>>>
>>>>> It's based on the RCUE work -> we need to push RCUE first. Thanks
>>>>> Nathaniel for review of the last font package. It will speed things up.
>>>>>
>>>>> Know bugs:
>>>>> - there is clash in id's of checkboxes preventing editation of
>>>>> subsequently displayed ones with the same name. Will be fixed in
>>>>> separate patch.
>>>>> - bugs caused by bugs in API (adding/removal of own tokens in
>>>>> self-service, inability to enter key on token creation -
>>>>> https://fedorahosted.org/freeipa/ticket/4099)
>>>>> - datetime format (widget+validator) will be implemented in separate
>>>>> patch
>>>>> - no support of not reviewed CLI patches (HOTP..)
>>>>>
>>>>> Cgit:
>>>>> http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/log/?h=otp
>>>>>
>>>>> https://fedorahosted.org/freeipa/ticket/3369
>>>>>
>>>>
>>>> patch 540-1 has been updated
>>>> - QR code is centered
>>>> - QR code correction level was lowered from H to M
>>>>
>>>> All other current patches from sub-threads are attached as well (it was
>>>> getting hard to keep track of them).
>>>>
>>>
>>> Attaching new version of patch 537: 537-4
>>>
>>> It:
>>> * adds HOTP support - new switch in adder dialog and ipatokenhotpcounter
>>> field in details facet
>>> * removes 'default' radio button in adder dialog in ipatokenotpalgorithm
>>> and ipatokenotpdigits field
>>>
>>>
>>> Btw I've encountered an issue on Web UI login when:
>>> - user is created
>>> - token is created for him
>>> - admin resets user's password and changes auth type to 'otp'
>>> - user tries to login with psw+otp
>>>
>>> The initial login-password call is successful but subsequent change
>>> password fails - it uses the old psw+otp.
>>>
>>> I'll address this issue in https://fedorahosted.org/freeipa/ticket/3903
>>> which is almost implemented.
>>>
>>>
>>> I also plan to hide fields without any value in otp token details page
>>> in self-service mode. This will be done after #3903 because some
>>> prerequisites for #3903 add useful code for that task.
>>>
>>
>> New version of 537 attached: 537-5
>>
>> It removes token type switch from selfservice page. Therefore default
>> token type (totp) will be always created.
>>
>> Originated from:
>> http://www.redhat.com/archives/freeipa-devel/2014-February/msg00532.html
>
> I'm not sure I understand the rationale for this (after having read the
> other email thread). But I agree we should discuss which options should
> be available on the self-service page.
>
> Just to recap the situation:
> 1. Only token name / description are provided in the self-service UI
> 2. All options are provided on the CLI
>
> I think the main question is: who should get to choose the primary token
> type in FreeIPA? There are three possibilities:
> 1. FreeIPA developers
> 2. Admins
> 3. Users
>
> The case for #1 is that we can't guarantee timely replication of the
> counter attribute. On this basis, we choose TOTP as default because of
> structural limitations. This is currently the default.
>
> I don't see much use for #3. But I can see an argument for #2.
>
> Personally, I lean toward #1. Thoughts?
>
> Nathaniel
>

Sorry, there is no real reason to not have HOTP there, and therefore 
537-5 is wrong and 537-4 is OK.

Rationale of the mistake:
* self-service page has to be simple so it doesn't allow to add hw tokens
* My thoughts were fixed to the idea that HOTP has to be hw token - 
maybe the H confused me.
-- 
Petr Vobornik