[keycloak-user] Update account - login action tokens - how to make them persistent

Wed Mar 2 14:02:19 EST 2016

You tell us ;)

I had in mind a while back that we'd support storing "configuration" such
as realm settings in a config file. Then we'd store only clients, users,
roles, etc.. in the database. How realistic it is that we'd implement it is
unsure though.

On 2 March 2016 at 14:15, Edgar Vonk - Info.nl <Edgar at info.nl> wrote:

> Hi Stian,
>
> I realise that. However so far it is working ok for us. We do the
> re-importing because we really want a continuous delivery pipeline and
> doing run-time configuration is very different from that. We really only
> perform run-time configuration to develop and test stuff, immediately after
> which we export it so that we can update the resulting realm JSON in Git.
> We work in a similar fashion with other products like content management
> systems where we make a very clear distinction between configuration
> (=source code) and run-time managed content. Our CMS of choice (Magnolia)
> offers a nice upgrade mechanism that we use to re-import all our
> configuration on every upgrade.
>
> No, we do not re-import users. We see users (just like user groups, role
> mappings, group mappings and of course sessions) as run-time data
> (‘content’ to make the link to a CMS).
>
> In our set-up we store all this run-time data in Active Directory (well,
> except the sessions, which we do not store persistently yet) and therefore
> this re-importing in the Keycloak database works for us (to some degree).
>
> A question for you/the Keycloak team: how do you see Keycloak fit into a
> fully automated continuous delivery pipeline? Most configuration changes in
> Keycloak are so fundamental to the set-up that I cannot see that you would
> want to change these on the fly on a production environment at all. It
> would be very easy to break stuff in my opinion.
>
> cheers
>
> Edgar
>
>
> On 02 Mar 2016, at 14:00, Stian Thorgersen <sthorger at redhat.com> wrote:
>
> Re-importing everything on each startup is not really something we're
> supporting. Keycloak wasn't really designed for that and the focus is more
> on run-time configuration. Do you re-import users as well?
>
> On 2 March 2016 at 13:39, Edgar Vonk - Info.nl <http://info.nl> <
> Edgar at info.nl> wrote:
>
>> Thanks Stian!
>>
>> We will have a look at both options.
>>
>> Concerning clustering we have a different challenge which is that we
>> currently re-import all Keycloak realm data on every start up of Keycloak
>> (and because we do continuous delivery and are developing actively this is
>> multiple times a day). This because we treat all (realm) configuration as
>> source code for which our Git repo is leading.
>>
>> Effectively this means that we recreate the Keycloak database for every
>> new deployment and of course a cluster is not going to help us here when it
>> comes to uptime. Not sure how to deal with this as yet. Ideally we would
>> want some sort of realm update/patch mechanism instead of a full import but
>> that sounds rather complex to implement.
>>
>> cheers
>>
>> On 02 Mar 2016, at 13:23, Stian Thorgersen <sthorger at redhat.com> wrote:
>>
>> The tokens themselves are not stored, but can be verified by Keycloak as
>> long as the user session is active. So your question is how to make user
>> sessions persisted. We do not support persisting user sessions at the
>> moment. You have two choices:
>>
>> 1. Add an additional node and configure set owners to 2 for the user
>> session caches, or change it to a replicated cache. See the clustering
>> section in the docs for more details.
>> 2. Try to configure Infinispan to persist the sessions. See
>> https://docs.jboss.org/author/display/WFLY10/Infinispan+Subsystem for
>> more details.
>>
>> On 1 March 2016 at 20:56, Edgar Vonk - Info.nl <http://info.nl/> <
>> Edgar at info.nl> wrote:
>>
>>> Hi all,
>>>
>>> What would we need to do to make Keycloak user sessions persistent in
>>> the database?
>>>
>>> I think the information in:
>>> http://lists.jboss.org/pipermail/keycloak-user/2015-April/001921.html is
>>> not relevant anymore with Keycloak 1.9.0? Specifically:
>>>
>>> "userSessions": {
>>>         "provider": "jpa"
>>>     }
>>>
>>>
>>> Does not seem to work (“Failed to find provider jpa for userSessions”).
>>> User sessions are now managed using Infinispan by default if I understand
>>> correctly:
>>> http://keycloak.github.io/docs/userguide/keycloak-server/html/clustering.html#d4e3292
>>>  ?
>>>
>>> Is there a way to make user sessions persistent?
>>>
>>> Our issue is that we send out a lot of activation (‘update password’)
>>> emails from our (single) Keycloak server to new users and since we have a
>>> continuous delivery pipeline Keycloak does down and up quite a bit and
>>> every time it restarts all temporary log in tokens used for these update
>>> password actions are lost (since they are stored in memory only). And if I
>>> understand correctly these tokens are actually a sort of user sessions.
>>>
>>> cheers
>>>
>>> Edgar
>>>
>>>
>>> On 29 Feb 2016, at 17:52, Edgar Vonk - Info.nl <http://info.nl/> <
>>> Edgar at info.nl> wrote:
>>>
>>> Hi,
>>>
>>> See if I understand this correctly: in the default set up of Keycloak
>>> sessions and temporary tokens are not persisted in the Keycloak database?
>>> So consider this scenario:
>>>
>>> 1/ login as admin to master realm
>>> 2/ go to Users - Credentials and send a ‘Update Password’ reset action
>>> email
>>> 3/ user receives an email with a link with a unique token to update
>>> his/her password in Keycloak
>>> 4/ Keycloak server is restarted for whatever reason
>>> 5/ the temporary ‘login action token’ no longer exists and the link from
>>> 3/ no longer works
>>>
>>> Is this correct and expected behaviour?
>>>
>>> And if so, can somebody maybe point us in the direction to solve this?
>>> I.e. by making sessions/tokens by persistent I guess.
>>>
>>> cheers
>>>
>>> Edgar
>>>
>>>
>>>
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160302/4c7338e4/attachment.html 