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

[Dmitri Pal]

On 02/26/2014 06:57 AM, Petr Vobornik wrote:
> On 26.2.2014 01:55, Dmitri Pal wrote:
>> On 02/24/2014 10:21 AM, Nathaniel McCallum wrote:
>>> On Mon, 2014-02-24 at 15:48 +0100, Petr Vobornik wrote:
>>>> On 24.2.2014 15:31, Nathaniel McCallum wrote:
>>>>> On Mon, 2014-02-24 at 11:04 +0100, Petr Vobornik wrote:
>>>>>> On 21.2.2014 20:00, Nathaniel McCallum wrote:
>>>>>>> Is it possible to do something more intelligent for the key and 
>>>>>>> date
>>>>>>> fields in the add-token UI?
>>>>>>>
>>>>>>> Date fields are currently just a text box. Is there any sort of
>>>>>>> calendar
>>>>>>> we could use here? If not, I'm still unsure of what the format
>>>>>>> should be
>>>>>>> for this field.
>>>>>> It's the format you chose :), try to fill it in CLI, you will 
>>>>>> have the
>>>>>> same proble. From API level it's just string, from LDAP it's
>>>>>> generalized
>>>>>> time.
>>>>> Is there a better option? I'm open to suggestions.
>>>> As I mentioned below, it's being implemented. The datetime patches 
>>>> will
>>>> be send separately. The core OTP UI patches should not be blocked by
>>>> them.
>>>>
>>>>>> I've an UI patch prepared where you can write it in ISO format, 
>>>>>> with a
>>>>>> validator attached to it, so user will be noticed about the format,
>>>>>> but
>>>>>> it's waiting for:
>>>>>> https://www.redhat.com/archives/freeipa-devel/2014-January/msg00057.html 
>>>>>>
>>>>>>
>>>>>> https://www.redhat.com/archives/freeipa-devel/2014-January/msg00060.html 
>>>>>>
>>>>>>
>>>>>>
>>>>>>> The key field should probably have a note indicating that it is
>>>>>>> Base32
>>>>>>> encoding. It would also be nice to restrict the input to Base32
>>>>>>> characters. Maybe even automatic case correction...
>>>>>> Actually I think it doesn't help much. Show me a person who can 
>>>>>> write
>>>>>> base32 encoded string.... But I agree that a validator with some 
>>>>>> regex
>>>>>> to limit the chars and a note that it should be base32 string is
>>>>>> better.
>>>>>> The question is what's the purpose of this field from user
>>>>>> perspective.
>>>>>> Is a human being suppose to fill it or is it meant to be only
>>>>>> filled by
>>>>>> some provisioning systems? In UI it's just as a backup?
>>>>>>
>>>>>> If there is a use case where user is suppose to choose the key, it
>>>>>> would
>>>>>> be better to fill the key and convert it to base32 string on a 
>>>>>> server.
>>>>> I can't think of any case where a user would use the key field.
>>>>>
>>>>> However, there are at least two important cases where an admin 
>>>>> would do
>>>>> this:
>>>>> 1. Hardware tokens
>>>>> 2. Transferring OATH (TOTP/HOTP) tokens from another system
>>>>>
>>>>> Nathaniel
>>>>>
>>>> What is the input format for these two cases? Is it base32 so admin 
>>>> can
>>>> enter it into UI or is it plain text so he has to use different 
>>>> tool to
>>>> encode it to base32 and then fill into UI?
>>> In both of the above cases, I suspect the predominant use will be
>>> scripts written to take a token store and import the tokens. This is
>>> mostly a non-UI case.
>>>
>>> RFC 6030 uses Base64 for unencrypted tokens. Base32 is also in wide 
>>> use.
>>> This is largely because, with fewer characters and no case-sensitivity,
>>> Base32 is easier to type. I don't know of any other encodings in wide
>>> use.
>>>
>>> It would be nice to support both of them, but I'm not sure how this is
>>> possible. Suggestions are welcome.
>>
>> I do not think we should allow typing the key (and other attributes)
>> manually.
>> We should rather ask user to import a token or tokens from the XML file
>> that uses RFC6030.
>> There are vendors of the hardware tokens that actually using it to
>> distribute the tokens.
>>
>> Here are the examples
>> http://www.gooze.eu/howto/oath-otp-tokens-howto/seed-codes-sample-files
>>
>> Please click around the site for more info.
>>
>
> This is one vendor. Do we have information that the other ones (or 
> just the major ones) use the XML PSKC schema from RFC6030 as well? If 
> that's the case, we have enough information for implementing 
> otp-import (design page says that we don't have enough info).
>
> Back to UI. The UI might be useful if the admin has the values in 
> different form than XML data, i.e., printed on a paper. Having the UI 
> doesn't do any harm, right?
>
> If vendors mostly use base64 keys, adding only base32 support in our 
> API doesn't make much sense. IMO it actually adds more work because 
> you have to convert it first.
>
> Anyway: NACK for the patch because it shows totp/hotp switch in 
> selfservice without possibility to define other hotp specifics. I'll 
> remove it so there will be only totp in self-service (just token 
> name+description).

I think we need to take an inspiration in the LinOTP solution UI.
See more details here: 
http://www.linotp.org/doc/2.6/part-management/managingtokens/import.html
It loos like Alladin, SafeNet, Fetian have these tokens in XML.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/