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