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

[Dmitri Pal]

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.

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


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


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