[keycloak-dev] [keycloak-user] How to implement long user sso sessions with reauthentication for important actions?
Adam Young
ayoung at redhat.com
Mon Nov 30 19:33:40 EST 2015
On 11/27/2015 07:57 AM, Stian Thorgersen wrote:
> Current flow checks if cookie is there and if it is it's all happy.
> We'd need a different flow that can require the re-auth to take place
> even if cookie is there. Also, with re-auth flow user should be able
> to cancel or just navigate away and continue using the session as if
> nothing has happend (with the other apps that's happy with the old
> session that is)
>
> On 27 November 2015 at 13:51, Vlastimil Elias <velias at redhat.com
> <mailto:velias at redhat.com>> wrote:
>
>
>
> On 27.11.2015 13:46, Stian Thorgersen wrote:
>>
>>
>> On 27 November 2015 at 13:36, Vlastimil Elias <velias at redhat.com
>> <mailto: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
>
> yep, but new Reauthentication flow must also check if user is
> logged in currently (over cookie). If not logged in then it should
> go to current Browser flow to login him. If logged in then it must
> continue in Reathentication flow. So check "is user currently
> logged in?" should be same for both flows.
>
> Vl
>
If not logged in, it is not reauthentication, it is delegation.
If I ask for a long running task, and I am not around when something
needs to be done on my behalf, I need to make sure I've delegated to the
remote principal the ability to perform this task, and that remote
principal needs to be able to confirm it.
>
>
>>
>>
>>> * 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 <mailto: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
>>>
>>> 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 <mailto: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 <mailto: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
>>>>> <mailto:keycloak-user at lists.jboss.org>
>>>>> 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
>>
>>
>
> --
> Vlastimil Elias
> Principal Software Engineer
> Developer Portal Engineering Team
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151130/4b1f562e/attachment-0001.html
More information about the keycloak-dev
mailing list