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
[email protected]
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/
_______________________________________________
Freeipa-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/freeipa-devel
