[Freeipa-devel] [PATCH] 157 Added password reset capabilities to unauthorized dialog

Petr Vobornik pvoborni at redhat.com
Tue Jun 19 14:01:06 UTC 2012


In general I like simplifying the dialog so I took most of your 
suggestions and implemented them following way:

     Login
     -----------------------------------------------------

       Your session has expired. Please re-login.

       To login with Kerberos, please make sure you
       have valid tickets (obtainable via kinit) and
       [configured] the browser correctly.

       To login with username and password:

         Username:        [edewata                  ]
         Password:        [********                 ]

                                              [Login]


So I just changed the order and kept only one button. If username and 
password are filled it uses form-based auth otherwise it uses kerberos 
auth. I'm not sure if it is straightforward but it is easy to use.

I followed all suggestion in the reset part.

I have to place to the forms error box. I'm not sure about the position 
though.

Updated patch attached.


On 06/13/2012 07:18 PM, Endi Sukma Dewata wrote:
> On 6/13/2012 8:15 AM, Petr Vobornik wrote:
>> I'll address all issues once we decide on the solution.
>>
>>> 1. If you click 'form-based authentication the dialog title still shows
>>> 'Kerberos ticket no longer valid' which is not relevant for form-based
>>> authentication. It might be better to use 'Login' as the title for all
>>> pages in this dialog.
>>
>> Agree
>>
>>> 2. Instead of having to go to a separate page for form-based
>>> authentication, would it be better to change the first page in the login
>>> dialog to show the login form? Something like this:
>>>
>>> Login
>>> -----------------------------------------------------
>>>
>>> Your session has expired. Please re-login.
>>>
>>> To login with username and password:
>>>
>>> Username: [edewata ]
>>> Password: [******** ]
>>>
>>> [Login]
>>>
>>> To login with Kerberos, please make sure you
>>> have valid tickets (obtainable via kinit) and
>>> [configured] the browser correctly.
>>>
>>> [Login with Kerberos]
>>>
>>> The two login mechanisms can be shown at the same time like above or in
>>> collapsible sections. If the user enters a password and it's expired,
>>> the dialog will change into:
>>
>> I like the idea but I'm not sure about the layout. Having one button
>> inside the dialog seems strange a also it will probably look weird.
>
> You mean two buttons (Login & Login with Kerberos)? I agree it's kinda
> strange.
>
>> Collapsible sections are worse because you have to click on them so it
>> slow things down.
>
> That's also true. I'll leave this up to you. The current workflow still
> makes sense if we consider form-based authentication a less preferred
> method, so you'd have to go to another page to login with username &
> password.
>
>> Current implementation has 'forms-based
>> authentication' link selected so user can in most cases hit enter and
>> immediately write username, password and complete login procedure only
>> by using keyboard.
>
> Hmm... that's not very obvious though. I wouldn't have known that until
> you told me :) I think intuitively people will think that if you hit
> enter it will click the default button in the dialog, unless there's
> input text field.
>
>> Also 'Login with Kerberos' is misleading. User login elsewhere (kinit).
>> So current button: 'retry' is more appropriate.
>
> What I meant was 'Login with Kerberos mechanism' or 'Login with Kerberos
> ticket', but it might be too long. I assume people in general isn't
> going to be confused by that because the text also mentions that you'd
> have to get the ticket from kinit.
>
> My concern with 'Retry' is that if you open the UI for the first time
> and you haven't done kinit yet, you'll see a message saying your
> Kerberos ticket has expired and asking you to Retry. This is not quite
> accurate because you never had a ticket before.
>
> The 'expired ticket' and 'retry' message might make more sense if you
> already had the UI open but left it for a while and come back to
> continue. If you just open the UI for the first time I think the message
> should only tell you what you need to do to login, not what went wrong
> in the past.
>
> I'll leave this up to you too. We might be able to keep the current
> workflow, but display different message depending whether it's your
> first visit or return visit.
>
>>> Login
>>> -----------------------------------------------------
>>>
>>> Your password has expired. Please enter a new
>>> password:
>>>
>>> Username: edewata
>>> New Password: [******** ]
>>> Verify Password: [******** ]
>>>
>>> [Reset Password and Login] [Cancel]
>>>
>>> In this page the username is shown for info only, it's not editable. The
>>> old password is not shown again, but kept in memory. I use Cancel
>>> instead of Back to indicate that we are starting over. The Cancel button
>>> will bring you back to the first page.
>>
>> Little change, but can be probably more straightforward - will do.
>
> If you keep the original workflow, the Cancel button probably should
> bring you to the first page (expired ticket), not to the second page
> (login) because if your password has expired you can't login without
> reset anyway.
>
>> 2a. The dialog uses headers in title (the one from #1) and a headers
>> inside (login, reset password). From your examples I'm not sure if you
>> would like to:
>> a) remove the inside headers
>> b) change them to 'login' everywhere
>> c) keep them unchanged
>
> I think the inside header is not necessary, it's a duplicate of the
> dialog title. This reset password operation is still part of login
> operation because if you cancel reset you still aren't logged in yet.
>
>>> 3. I noticed that the password is kept in memory too long by the login
>>> dialog so if you go back and forth between the pages the fields are
>>> already populated. This might be a security risk. I think the username &
>>> password should be cleaned up when you click Back/Cancel.
>>
>> Agree
>
> Also when you complete the login process, it should be cleaned up as well.
>
>>> 4. Is there a plan to provide password reset via email?
>>
>> I don't think so. I'm not sure if it is even useful for Freeipa. One of
>> main purposes for Freeipa is SSO and I guess company mail would be
>> kerberized too. So if you forget the password, you can't login, reset
>> and even access mail. I guess using external mail is not the way to go.
>> Maybe it is useful if company uses additional authentication mechanism
>> like pin + token or other.
>
> OK.
>


-- 
Petr Vobornik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freeipa-pvoborni-0157-1-Added-password-reset-capabilities-to-unauthorized-di.patch
Type: text/x-patch
Size: 24146 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20120619/0d876d9c/attachment.bin>


More information about the Freeipa-devel mailing list