9:08 a.m.
We had a JPA user session provider at some point, but dropped it mainly for
performance reasons and the fact it was not very well implemented. Having
to write to the database for every request (including token refresh) would
not be very good for performance, especially not with db replication
enabled. There might be the possibility of creating a hybrid or to reduce
the amount of writes to the session, but that would probably be quite a bit
of work to do.
For authorization code flow we do have plans to figure out sticky sessions
for that where both the requests from the browser and server-side
applications ends up going to the same node. See
https://issues.jboss.org/browse/KEYCLOAK-2352.
On 24 August 2016 at 23:16, Jared Blashka <jblashka(a)redhat.com> wrote:
I'm not sure why I never noticed this before, but I was doing
some
investigation today and couldn't find any session information actually
populated in the DB tables. Both USER_SESSION and CLIENT_SESSION were
empty.
After some digging in the code I saw that the only UserSesssionProvider
implementation is the Infinispan-based one and it looks like the only type
of user sessions that get persisted in the DB are offline sessions (via the
JpaUserSessionPersisterProvider).
Was there a particular reason a JpaUserSessionProvider doesn't exist?
Background: We're aiming to have a highly available+resilient
active-active multi-data center deployment of Keycloak. Ultimately, there
should be no customer impact if a particular data center fails; there
should be no IDP outage and they shouldn't have to log in again. We ran
into issues with asynchronous user data replication earlier, which is why
we're currently working on migrating our existing MariaDB cluster to use
Galera (which has been looking pretty good so far) but it looks like we
mistakenly assumed that this synchronous replication would also handle user
session data.
Not replicating user session data across data centers is also going to
cause us problems (its already caused us problems actually) when it comes
to the OAuth authorization code flow as well. Since that flow involves
back-channel server communication we can't guarantee that the client server
will communicate with the same data center the client authenticated at. If
a client calls out to the "wrong" data center, the flow will fail.
I can spend some time tomorrow investigating the performance when
clustering infinispan across data centers, but I'm not particularly
optimistic about the results.
Any thoughts/comments on our problem?
Jared
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user