[keycloak-dev] [keycloak-user] How to implement long user sso sessions with reauthentication for important actions?

[Stian Thorgersen]

On 27 November 2015 at 13:36, Vlastimil Elias <velias at redhat.com> wrote:

>
>
> On 27.11.2015 12:22, Stian Thorgersen wrote:
>
> Initially when you proposed this feature I underestimated how complicated
> it would be as well. Reading the discussion on the issue you created I've
> got a few comments:
>
> * We need a new flow - users could want to require re-auth with password,
> or with totp, or with both, etc..
>
> Agree, but at least first step must be same with Browser flow - check of
> cookie, and then redirect to another flow if necessary. Not sure if current
> flow engine supports this.
>

Current browser flow would just automatically log-in as the cookie is there


>
>
> * There's probably quite a few corner cases to cover - you've already
> mentioned a few
>
> It's a very nice to have feature, but I doubt have time to work on it for
> 1.8.
>
> Is it something we can post-pone to 2.x or do you really need it now?
>
>
> We do not need it just now, but should be cool to have it in some
> reasonable time (half of year?).
> Not sure when you plan to start work on 2.x, probably sometime around half
> of next year?
>
> As it is really complex then we probably should break it into smaller
> chunks and implement it per partes over the releases. I can imagine first
> version with basic flow support with Form password auth only, then add
> other parts like support for Identity Brokers, OTP, Kerberos, required
> actions etc.
>
> Vl.
>
>
>
> On 27 November 2015 at 11:05, Vlastimil Elias <velias at redhat.com> wrote:
>
>> Hi,
>>
>> moving this discussion to the devel forum as it is about the feture
>> development now.
>>
>> Toplevel issue I created for this feature is
>> <https://issues.jboss.org/browse/KEYCLOAK-2076>
>> https://issues.jboss.org/browse/KEYCLOAK-2076
>>
>> I added some notes and thoughts from my investigation as a comment to the
>> KEYCLOAK-2076, there are some open questions how to implement it.
>>
>> Originally I though I should be able to implement reauth support and
>> provide PR.
>> But I must say I'm not sure now if I'm able to implement it, looks like
>> it is a bit more complicated than I originally expected, so probably some
>> Keycloak core developer should do it.
>> But if you think you will not have resources to do it in 1.8 then I can
>> try it (with your support), as I believe it is a very important feature,
>> and we really want use it.
>>
>> Cheers
>>
>> Vlastimil
>>
>>
>>
>>
>> On 12.11.2015 14:50, Stian Thorgersen wrote:
>>
>>
>>
>> On 12 November 2015 at 14:49, Vlastimil Elias < <velias at redhat.com>
>> velias at redhat.com> wrote:
>>
>>> Thanks for quick reply Stian.
>>>
>>> I'm going to create JIRAs for all these things. I can volunter to
>>> implement some parts of this.
>>>
>>> For the last one, it should be probably cool to have "reauthenticate
>>> timeout" setting available in client section for every client (not only
>>> internal admin console and account management). It should allow simple
>>> implementation of "long user sso session" scheme even in environments where
>>> some clients can't be updated to set max_age on protocol level.
>>>
>>
>> Yep, that makes sense
>>
>>
>>>
>>> Vl.
>>>
>>>
>>> On 12.11.2015 14:39, Stian Thorgersen wrote:
>>>
>>>
>>>
>>> On 12 November 2015 at 14:15, Vlastimil Elias < <velias at redhat.com>
>>> velias at redhat.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> I'd like to use long session authentication mechanism known from many
>>>> sites like google. facebook, linked in etc.
>>>> It is about really long user SSO sessions (eg. weeks or even months)
>>>> with reauthentication for important actions when last authentication
>>>> timestamp is older than some limit.
>>>>
>>>> Is this somehow possible with current Keycloak server and Keycloak
>>>> adapters?
>>>>
>>>> I see few subquestions in this problem for our use:
>>>>
>>>> *****
>>>> open-id connect protocol defines few auth request parameters to support
>>>> this use case, mainly max_age or prompt=login. Are they correctly
>>>> implemented in Keycloak server?
>>>>
>>>
>>> We don't have support for max_age and we only support prompt=none so
>>> these would have to be added
>>>
>>>
>>>>
>>>>
>>>> *****
>>>> Wildfly/EAP adapter - is it possible and is there some example how to
>>>> use "reauth if auth is older than 30min" action in Java app secured by
>>>> this adapter? Or is info about last auth timestamp somehow available in
>>>> the app?
>>>>
>>>
>>> We don't set auth_time claim ATM so answer is no
>>>
>>>
>>>>
>>>>
>>>> *****
>>>> Keycloak user account application itself - it is part of the Keycloak
>>>> server, but it contains sensitive actions which typically require
>>>> reathentication in this long session scheme (password change, email
>>>> change, ...). Is it somehow possible to configure Keycloak to force
>>>> timeout reauth for this app?
>>>>
>>>
>>> Not at the moment - but if we add what you want it would also make sense
>>> to add that. Would need to be configurable through the admin console. Would
>>> also be nice to have the same for the admin console itself.
>>>
>>>
>>>>
>>>> Thanks in advance
>>>>
>>>> Vl.
>>>>
>>>> --
>>>> Vlastimil Elias
>>>> Principal Software Engineer
>>>> Developer Portal Engineering Team
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> keycloak-user mailing list
>>>> <keycloak-user at lists.jboss.org>keycloak-user at lists.jboss.org
>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-user>
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>
>>>
>>>
>>> --
>>> Vlastimil Elias
>>> Principal Software Engineer
>>> Developer Portal Engineering Team
>>>
>>>
>>
>> --
>> Vlastimil Elias
>> Principal Software Engineer
>> Developer Portal Engineering Team
>>
>>
>
> --
> Vlastimil Elias
> Principal Software Engineer
> Developer Portal Engineering Team
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151127/1cb44515/attachment.html