<div dir="ltr">I guess at least the re-auth part is logic that belongs in the client that performs the login.<div><br></div><div>Question though for authentication levels as well as authentication timeout (or whatever you call it) shouldn't a rest service be able to say things like I require the user to have authenticated with password + otp, and to have authenticated within N minutes?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 27 November 2015 at 16:13, Bill Burke <span dir="ltr"><<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Why would you need re-auth for REST or even browser clients? Doesn't<br>
access token and refresh token timeouts handle this sort of thing?<br>
<span class=""><br>
On 11/27/2015 7:25 AM, Stian Thorgersen wrote:<br>
> Hmm.. re-auth request for rest endpoints is even more tricky. I think a<br>
> rest endpoint would just have to return a 401? Then it's up to the<br>
> client to figure out that it needs to re-authenticate.<br>
><br>
> On 27 November 2015 at 13:22, Vlastimil Elias <<a href="mailto:velias@redhat.com">velias@redhat.com</a><br>
</span><span class="">> <mailto:<a href="mailto:velias@redhat.com">velias@redhat.com</a>>> wrote:<br>
><br>
><br>
><br>
> On 27.11.2015 12:28, Stian Thorgersen wrote:<br>
>><br>
>><br>
>> On 27 November 2015 at 12:16, Vlastimil Elias<br>
</span>>> <<mailto:<a href="mailto:velias@redhat.com">velias@redhat.com</a>><a href="mailto:velias@redhat.com">velias@redhat.com</a><br>
<span class="">>> <mailto:<a href="mailto:velias@redhat.com">velias@redhat.com</a>>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> On 27.11.2015 11:45, Stian Thorgersen wrote:<br>
>>><br>
>>><br>
>>> On 27 November 2015 at 10:23, Vlastimil Elias<br>
</span>>>> <<mailto:<a href="mailto:velias@redhat.com">velias@redhat.com</a>><a href="mailto:velias@redhat.com">velias@redhat.com</a><br>
<div><div class="h5">>>> <mailto:<a href="mailto:velias@redhat.com">velias@redhat.com</a>>> wrote:<br>
>>><br>
>>> Hi,<br>
>>><br>
>>> I have two proposals for cleanup of 'Change password'<br>
>>> screen in Account<br>
>>> app based on my experience with it:<br>
>>><br>
>>> 1. remove Cancel button - it has no any meaning on this<br>
>>> screen/form, it<br>
>>> only reshowns form with empty fields. And also there is a<br>
>>> bug,<br>
>>> "Password" field is hidden when it is used, which makes<br>
>>> whole form unusable.<br>
>>><br>
>>><br>
>>> +1<br>
>><br>
>> OK, I'm going to create JIRA and provide PR for this.<br>
>><br>
>>><br>
>>> 2. remove validation of current password (remove<br>
>>> "Password" field). Two<br>
>>> reasons for this:<br>
>>> - security impact of this check is small. If attacker<br>
>>> is able to<br>
>>> compromise Account app then he can always change email<br>
>>> and then use<br>
>>> "Forgot password" feature to change password<br>
>>> - user created over Identity Provider do not know old<br>
>>> password<br>
>>> (because it is not set) so he is not able to set password<br>
>>> using this screen<br>
>>> After we implement support for reauthentication<br>
>>> (KEYCLOAK-2076) then we<br>
>>> should set some reasonable reauth timeout for Account app<br>
>>> instead, this<br>
>>> will make it more secure at all.<br>
>>><br>
>>><br>
>>> -1 Reset password over email may not be enabled at all. We<br>
>>> already allow setting password for IdPs login without<br>
>>> requiring the existing password.<br>
>> Fair enough<br>
>>><br>
>>> +1 To suggestion from Thomas - we should ask for password<br>
>>> when updating email at least when recover password over email<br>
>>> is enabled.<br>
>><br>
>> Makes sense, but what to do if user has no password set at<br>
>> this point? Don't ask him, or reauthenticate him by other<br>
>> available mechanism?<br>
>><br>
>> And there are also other "dangerous" operations in Account<br>
>> app. Eg. attacker who gains access to it can disable OTP<br>
>> without any recheck. This should be protected too.<br>
>> I believe whole Account app should be correctly protected by<br>
>> reauthentications. Question is if implement it somehow<br>
>> specifically in the app, or resolve this generally as part of<br>
>> KEYCLOAK-2076.<br>
>><br>
>><br>
>> Yep, you're right there's other dangerous operations as well.<br>
>> Re-authentication sounds like the correct approach, rather than<br>
>> requesting the password again. We could have two configurable<br>
>> timeouts in account management console. One that requires re-auth<br>
>> for anything (~30 min default), and another that requires re-auth<br>
>> for sensitive operations (~5 min).<br>
>><br>
>> One thing with re-auth is that if it happens when a user submits a<br>
>> form, you then someone have to also remember the values of the<br>
>> form. Currently account management is stateless.<br>
><br>
> Yep, implementing reauthentication schemes correctly in client apps<br>
> may be tricky, mainly for POST requests (and even worse posts with<br>
> file upload) and AJAX call handlers etc.<br>
> Beside Keycloak Account app we should try to provide reasonable<br>
> support in Keycloak adapters, but it may be tricky as related Java<br>
> EE specifications (JAAS subsystems, auth related things in Java<br>
> Servlet and EJB spec ) do not count with these more complicated<br>
> schemes too much.<br>
><br>
> And I also thought if reauthentication scheme should be somehow<br>
> implemented on REST API levels also.<br>
> Eg. some REST endpoint operation will define that it needs reauth<br>
> with some timeout. If client app call it with Bearer token then it<br>
> should be able to tests last auth timestamp (which should be<br>
> possible as it may be in the token as claim) and propagate back info<br>
> that it needs reauth (how to map this to HTTP?). Support for this<br>
> should be added to the framework like RestEasy then.<br>
><br>
> Vl.<br>
><br>
>><br>
>><br>
>> Vlastimil<br>
>><br>
>>><br>
>>> It seems to be common practice to ask for current password<br>
>>> when updating the existing password.<br>
>>><br>
>>><br>
>>> If you agree then I can create JIRA issue for this and<br>
>>> provide PR.<br>
>>><br>
>>> Vlastimil<br>
>>><br>
>>> --<br>
>>> Vlastimil Elias<br>
>>> Principal Software Engineer<br>
>>> Developer Portal Engineering Team<br>
>>><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> keycloak-dev mailing list<br>
>>> <a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
</div></div>>>> <mailto:<a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a>><br>
<span class="im HOEnZb">>>> <a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
>>><br>
>>><br>
>><br>
>> --<br>
>> Vlastimil Elias<br>
>> Principal Software Engineer<br>
>> Developer Portal Engineering Team<br>
>><br>
>><br>
><br>
> --<br>
> Vlastimil Elias<br>
> Principal Software Engineer<br>
> Developer Portal Engineering Team<br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> keycloak-dev mailing list<br>
> <a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
><br>
<br>
--<br>
</span><span class="HOEnZb"><font color="#888888">Bill Burke<br>
JBoss, a division of Red Hat<br>
<a href="http://bill.burkecentral.com" rel="noreferrer" target="_blank">http://bill.burkecentral.com</a><br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
</div></div></blockquote></div><br></div>