On 02/27/2014 11:42 AM, Nathaniel McCallum wrote:
On Thu, 2014-02-27 at 17:29 +0100, Petr Vobornik wrote:
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.
On a similar note, I've been toying with the idea of a
ipatokenRestricted attribute. The idea is that restricted tokens cannot
be created or deleted by users and, when the user is deleted, the token
is orphaned in stead of deleted. During XML import, the restricted
attribute would be set by default.
This seems to me the correct behavior.
It should be possible for the hardware tokens to exist in the system as
unassigned.
This is why we need an type attribute that indicates this. Tokens that
are HW can't be edited, they can be just assigned, unassigned, synched
or deleted.
Nathaniel
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@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/
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
