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

[Nathaniel McCallum]

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.

Nathaniel