11:11 a.m.
Currently, adding or deleting a client, or updating a realm causes
invalidation/eviction of the realm and all clients in that realm. To
make matters worse, the next time the realm is accessed, it queries and
loads each client and its relationships. Why do we do this? When a
realm invalidation happens, the cache has no idea if the realm is just
being updated or removed entirely from the DB. With a realm removal, you
also need to evict the cache of all clients within the realm. So, a
cached realm MUST have a list of all clients within it. As a result,
the more clients that get added, keycloak gets slower and slower.
Eventually though the cache stabilizes after inserts/update/deletes
subside and we get back to normal performance, but you can see a nasty
blip for a little bit.
I think i have a couple of solutions for this:
* Create a separate client cache. Client keys would be
"{realm.id}.{client.id}". Iterate on all client keys, and evict those
that start with the realm id.
* Or, do a DB query for all clients of the realm.
I'm giving this until end of day to see if I can get a good solution,
otherwise i'm aborting.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11:46 a.m.
ISPN also provides an eviction policies to avoid undesired memory consumption. Not sure if
that helps to what you said about "the more clients that get added, keycloak gets
slower and slower".
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: keycloak-dev(a)lists.jboss.org
Sent: Wednesday, February 17, 2016 3:11:08 PM
Subject: [keycloak-dev] client query caches getting complicated
Currently, adding or deleting a client, or updating a realm causes
invalidation/eviction of the realm and all clients in that realm. To
make matters worse, the next time the realm is accessed, it queries and
loads each client and its relationships. Why do we do this? When a
realm invalidation happens, the cache has no idea if the realm is just
being updated or removed entirely from the DB. With a realm removal, you
also need to evict the cache of all clients within the realm. So, a
cached realm MUST have a list of all clients within it. As a result,
the more clients that get added, keycloak gets slower and slower.
Eventually though the cache stabilizes after inserts/update/deletes
subside and we get back to normal performance, but you can see a nasty
blip for a little bit.
I think i have a couple of solutions for this:
* Create a separate client cache. Client keys would be
"{realm.id}.{client.id}". Iterate on all client keys, and evict those
that start with the realm id.
* Or, do a DB query for all clients of the realm.
I'm giving this until end of day to see if I can get a good solution,
otherwise i'm aborting.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
12:04 p.m.
Eviction policies don't solve it. I spelled out why in the original post.
On 2/17/2016 12:46 PM, Pedro Igor Silva wrote:
ISPN also provides an eviction policies to avoid undesired memory
consumption. Not sure if that helps to what you said about "the more clients that get
added, keycloak gets slower and slower".
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: keycloak-dev(a)lists.jboss.org
Sent: Wednesday, February 17, 2016 3:11:08 PM
Subject: [keycloak-dev] client query caches getting complicated
Currently, adding or deleting a client, or updating a realm causes
invalidation/eviction of the realm and all clients in that realm. To
make matters worse, the next time the realm is accessed, it queries and
loads each client and its relationships. Why do we do this? When a
realm invalidation happens, the cache has no idea if the realm is just
being updated or removed entirely from the DB. With a realm removal, you
also need to evict the cache of all clients within the realm. So, a
cached realm MUST have a list of all clients within it. As a result,
the more clients that get added, keycloak gets slower and slower.
Eventually though the cache stabilizes after inserts/update/deletes
subside and we get back to normal performance, but you can see a nasty
blip for a little bit.
I think i have a couple of solutions for this:
* Create a separate client cache. Client keys would be
"{realm.id}.{client.id}". Iterate on all client keys, and evict those
that start with the realm id.
* Or, do a DB query for all clients of the realm.
I'm giving this until end of day to see if I can get a good solution,
otherwise i'm aborting.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
2:09 p.m.
On 17/02/16 18:11, Bill Burke wrote:
Currently, adding or deleting a client, or updating a realm causes
invalidation/eviction of the realm and all clients in that realm. To
make matters worse, the next time the realm is accessed, it queries and
loads each client and its relationships. Why do we do this? When a
realm invalidation happens, the cache has no idea if the realm is just
being updated or removed entirely from the DB. With a realm removal, you
also need to evict the cache of all clients within the realm. So, a
cached realm MUST have a list of all clients within it. As a result,
the more clients that get added, keycloak gets slower and slower.
Eventually though the cache stabilizes after inserts/update/deletes
subside and we get back to normal performance, but you can see a nasty
blip for a little bit.
We don't need to eagerly preload all clients when realm
is loaded.
Infinispan has streaming/predicate API and we are using it in many
places (see InfinispanUserSessionProvider and all the stuff in package
org.keycloak.models.sessions.infinispan.stream ). So when entry is
invalidated, we can have cacheListener, which will query infinispan to
return all cached clients of the realm and remove them. I can see that
we already have listener. So possibly we can just change this line to
use predicate query:
https://github.com/keycloak/keycloak/blob/master/model/infinispan/src/mai...
Other option is, that we can try to optimize eager preload and see if we
can reduce number of SQL queries at startup. For example, it seems that
CachedClient constructor sends SQL query to preload just realm roles.
And then each client sends another SQL query to preload his client roles
(method CachedClient.cacheRoles ). Couldn't we instead send one SQL
query to load all roles of realm (both realm and client roles)? Maybe we
can even send one big SQL query to load realm with all it's objects :-)
Possibly some FetchType.EAGER in Hibernate entities could help here.
Marek
I think i have a couple of solutions for this:
* Create a separate client cache. Client keys would be
"{realm.id}.{client.id}". Iterate on all client keys, and evict those
that start with the realm id.
* Or, do a DB query for all clients of the realm.
I'm giving this until end of day to see if I can get a good solution,
otherwise i'm aborting.
2:56 p.m.
On 2/17/2016 3:09 PM, Marek Posolda wrote:
On 17/02/16 18:11, Bill Burke wrote:
> Currently, adding or deleting a client, or updating a realm causes
> invalidation/eviction of the realm and all clients in that realm. To
> make matters worse, the next time the realm is accessed, it queries and
> loads each client and its relationships. Why do we do this? When a
> realm invalidation happens, the cache has no idea if the realm is just
> being updated or removed entirely from the DB. With a realm removal, you
> also need to evict the cache of all clients within the realm. So, a
> cached realm MUST have a list of all clients within it. As a result,
> the more clients that get added, keycloak gets slower and slower.
> Eventually though the cache stabilizes after inserts/update/deletes
> subside and we get back to normal performance, but you can see a nasty
> blip for a little bit.
We don't need to eagerly preload all clients when realm is loaded.
Infinispan has streaming/predicate API and we are using it in many
places (see InfinispanUserSessionProvider and all the stuff in package
org.keycloak.models.sessions.infinispan.stream ). So when entry is
invalidated, we can have cacheListener, which will query infinispan to
return all cached clients of the realm and remove them. I can see that
we already have listener. So possibly we can just change this line to
use predicate query:
https://github.com/keycloak/keycloak/blob/master/model/infinispan/src/mai...
Lol, i was sort of kind of doing that doing cache.values(). This makes
it much easier with much less refactoring.
Other option is, that we can try to optimize eager preload and see if
we can reduce number of SQL queries at startup. For example, it seems
that CachedClient constructor sends SQL query to preload just realm
roles. And then each client sends another SQL query to preload his
client roles (method CachedClient.cacheRoles ). Couldn't we instead
send one SQL query to load all roles of realm (both realm and client
roles)? Maybe we can even send one big SQL query to load realm with
all it's objects :-) Possibly some FetchType.EAGER in Hibernate
entities could help here.
yeah, we should start looking into stuff like this. We can at least
reduce the number of sql calls for caching a client or realm
individually. I'm not sure how feasible it is though or how much better
it is. Realms and clients contain more than a few one to many
relationships which would make the query result HUGE if I remember how
joins work.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
1:07 a.m.
Having two many joins (fetching everything about a realm in one query) is
probably going to be bad for performance, especially if there are loads of
clients and roles. There can also be large difference between different
vendors.
Another thing in the future we should separate clients out into a separate
store. There could be thousands of clients or even more. So they should be
treated in a similar fashion to users. Does that have impact on how we
improve/refactor/fix caching now?
On 17 February 2016 at 21:56, Bill Burke <bburke(a)redhat.com> wrote:
On 2/17/2016 3:09 PM, Marek Posolda wrote:
On 17/02/16 18:11, Bill Burke wrote:
Currently, adding or deleting a client, or updating a realm causes
invalidation/eviction of the realm and all clients in that realm. To
make matters worse, the next time the realm is accessed, it queries and
loads each client and its relationships. Why do we do this? When a
realm invalidation happens, the cache has no idea if the realm is just
being updated or removed entirely from the DB. With a realm removal, you
also need to evict the cache of all clients within the realm. So, a
cached realm MUST have a list of all clients within it. As a result,
the more clients that get added, keycloak gets slower and slower.
Eventually though the cache stabilizes after inserts/update/deletes
subside and we get back to normal performance, but you can see a nasty
blip for a little bit.
We don't need to eagerly preload all clients when realm is loaded.
Infinispan has streaming/predicate API and we are using it in many places
(see InfinispanUserSessionProvider and all the stuff in package
org.keycloak.models.sessions.infinispan.stream ). So when entry is
invalidated, we can have cacheListener, which will query infinispan to
return all cached clients of the realm and remove them. I can see that we
already have listener. So possibly we can just change this line to use
predicate query:
https://github.com/keycloak/keycloak/blob/master/model/infinispan/src/mai...
Lol, i was sort of kind of doing that doing cache.values(). This makes it
much easier with much less refactoring.
Other option is, that we can try to optimize eager preload and see if we
can reduce number of SQL queries at startup. For example, it seems that
CachedClient constructor sends SQL query to preload just realm roles. And
then each client sends another SQL query to preload his client roles
(method CachedClient.cacheRoles ). Couldn't we instead send one SQL query
to load all roles of realm (both realm and client roles)? Maybe we can even
send one big SQL query to load realm with all it's objects :-) Possibly
some FetchType.EAGER in Hibernate entities could help here.
yeah, we should start looking into stuff like this. We can at least
reduce the number of sql calls for caching a client or realm individually.
I'm not sure how feasible it is though or how much better it is. Realms
and clients contain more than a few one to many relationships which would
make the query result HUGE if I remember how joins work.
--
Bill Burke
JBoss, a division of Red Hathttp://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
1:43 a.m.
On 18/02/16 08:07, Stian Thorgersen wrote:
Having two many joins (fetching everything about a realm in one
query)
is probably going to be bad for performance, especially if there are
loads of clients and roles. There can also be large difference between
different vendors.
Maybe clients and roles (and groups?) shouldn't be loaded
eagerly with
realm, but I guess most of the other stuff can be (ie. federation
providers, identity providers, SMTP configurations etc). Also for
clients we can eagerly load most of the stuff (ie. redirectUris, scopes
). ATM we eagerly preload whole realm in CachedRealm constructor, but we
have fetchType.LAZY everywhere. IMO this is not optimal and would mean
lot of SQL at startup during realm preload (I did not doublecheck myself).
Marek
Another thing in the future we should separate clients out into a
separate store. There could be thousands of clients or even more. So
they should be treated in a similar fashion to users. Does that have
impact on how we improve/refactor/fix caching now?
On 17 February 2016 at 21:56, Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>> wrote:
On 2/17/2016 3:09 PM, Marek Posolda wrote:
> On 17/02/16 18:11, Bill Burke wrote:
>> Currently, adding or deleting a client, or updating a realm causes
>> invalidation/eviction of the realm and all clients in that realm. To
>> make matters worse, the next time the realm is accessed, it queries and
>> loads each client and its relationships. Why do we do this? When a
>> realm invalidation happens, the cache has no idea if the realm is just
>> being updated or removed entirely from the DB. With a realm removal, you
>> also need to evict the cache of all clients within the realm. So, a
>> cached realm MUST have a list of all clients within it. As a result,
>> the more clients that get added, keycloak gets slower and slower.
>> Eventually though the cache stabilizes after inserts/update/deletes
>> subside and we get back to normal performance, but you can see a nasty
>> blip for a little bit.
> We don't need to eagerly preload all clients when realm is
> loaded. Infinispan has streaming/predicate API and we are using
> it in many places (see InfinispanUserSessionProvider and all the
> stuff in package org.keycloak.models.sessions.infinispan.stream
> ). So when entry is invalidated, we can have cacheListener, which
> will query infinispan to return all cached clients of the realm
> and remove them. I can see that we already have listener. So
> possibly we can just change this line to use predicate query:
>
https://github.com/keycloak/keycloak/blob/master/model/infinispan/src/mai...
>
>
Lol, i was sort of kind of doing that doing cache.values(). This
makes it much easier with much less refactoring.
> Other option is, that we can try to optimize eager preload and
> see if we can reduce number of SQL queries at startup. For
> example, it seems that CachedClient constructor sends SQL query
> to preload just realm roles. And then each client sends another
> SQL query to preload his client roles (method
> CachedClient.cacheRoles ). Couldn't we instead send one SQL query
> to load all roles of realm (both realm and client roles)? Maybe
> we can even send one big SQL query to load realm with all it's
> objects :-) Possibly some FetchType.EAGER in Hibernate entities
> could help here.
>
yeah, we should start looking into stuff like this. We can at
least reduce the number of sql calls for caching a client or realm
individually. I'm not sure how feasible it is though or how much
better it is. Realms and clients contain more than a few one to
many relationships which would make the query result HUGE if I
remember how joins work.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
4:05 a.m.
On 18 February 2016 at 08:43, Marek Posolda <mposolda(a)redhat.com> wrote:
On 18/02/16 08:07, Stian Thorgersen wrote:
Having two many joins (fetching everything about a realm in one query) is
probably going to be bad for performance, especially if there are loads of
clients and roles. There can also be large difference between different
vendors.
Maybe clients and roles (and groups?) shouldn't be loaded eagerly with
realm, but I guess most of the other stuff can be (ie. federation
providers, identity providers, SMTP configurations etc). Also for clients
we can eagerly load most of the stuff (ie. redirectUris, scopes ). ATM we
eagerly preload whole realm in CachedRealm constructor, but we have
fetchType.LAZY everywhere. IMO this is not optimal and would mean lot of
SQL at startup during realm preload (I did not doublecheck myself).
I don't really think it's a priority and I suspect performance might
actually be worse if we do a lot of eager loading than lazy loading.
Depends on how Hibernate loads it of course, but if it does it through a
crazy join then performance will suffer.
Marek
Another thing in the future we should separate clients out into a separate
store. There could be thousands of clients or even more. So they should be
treated in a similar fashion to users. Does that have impact on how we
improve/refactor/fix caching now?
On 17 February 2016 at 21:56, Bill Burke <bburke(a)redhat.com> wrote:
>
>
> On 2/17/2016 3:09 PM, Marek Posolda wrote:
>
> On 17/02/16 18:11, Bill Burke wrote:
>
> Currently, adding or deleting a client, or updating a realm causes
> invalidation/eviction of the realm and all clients in that realm. To
> make matters worse, the next time the realm is accessed, it queries and
> loads each client and its relationships. Why do we do this? When a
> realm invalidation happens, the cache has no idea if the realm is just
> being updated or removed entirely from the DB. With a realm removal, you
> also need to evict the cache of all clients within the realm. So, a
> cached realm MUST have a list of all clients within it. As a result,
> the more clients that get added, keycloak gets slower and slower.
> Eventually though the cache stabilizes after inserts/update/deletes
> subside and we get back to normal performance, but you can see a nasty
> blip for a little bit.
>
> We don't need to eagerly preload all clients when realm is loaded.
> Infinispan has streaming/predicate API and we are using it in many places
> (see InfinispanUserSessionProvider and all the stuff in package
> org.keycloak.models.sessions.infinispan.stream ). So when entry is
> invalidated, we can have cacheListener, which will query infinispan to
> return all cached clients of the realm and remove them. I can see that we
> already have listener. So possibly we can just change this line to use
> predicate query:
>
<https://github.com/keycloak/keycloak/blob/master/model/infinispan/src/mai...
>
https://github.com/keycloak/keycloak/blob/master/model/infinispan/src/mai...
>
>
>
> Lol, i was sort of kind of doing that doing cache.values(). This makes
> it much easier with much less refactoring.
>
> Other option is, that we can try to optimize eager preload and see if we
> can reduce number of SQL queries at startup. For example, it seems that
> CachedClient constructor sends SQL query to preload just realm roles. And
> then each client sends another SQL query to preload his client roles
> (method CachedClient.cacheRoles ). Couldn't we instead send one SQL query
> to load all roles of realm (both realm and client roles)? Maybe we can even
> send one big SQL query to load realm with all it's objects :-) Possibly
> some FetchType.EAGER in Hibernate entities could help here.
>
>
> yeah, we should start looking into stuff like this. We can at least
> reduce the number of sql calls for caching a client or realm individually.
> I'm not sure how feasible it is though or how much better it is. Realms
> and clients contain more than a few one to many relationships which would
> make the query result HUGE if I remember how joins work.
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://bill.burkecentral.com
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
7:54 a.m.
On 2/18/2016 5:05 AM, Stian Thorgersen wrote:
On 18 February 2016 at 08:43, Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@redhat.com>> wrote:
On 18/02/16 08:07, Stian Thorgersen wrote:
> Having two many joins (fetching everything about a realm in one
> query) is probably going to be bad for performance, especially if
> there are loads of clients and roles. There can also be large
> difference between different vendors.
Maybe clients and roles (and groups?) shouldn't be loaded eagerly
with realm, but I guess most of the other stuff can be (ie.
federation providers, identity providers, SMTP configurations
etc). Also for clients we can eagerly load most of the stuff (ie.
redirectUris, scopes ). ATM we eagerly preload whole realm in
CachedRealm constructor, but we have fetchType.LAZY everywhere.
IMO this is not optimal and would mean lot of SQL at startup
during realm preload (I did not doublecheck myself).
I don't really think it's a priority and I suspect performance might
actually be worse if we do a lot of eager loading than lazy loading.
Depends on how Hibernate loads it of course, but if it does it through
a crazy join then performance will suffer.
We don't do EAGER SQL loading of clients. We just load every
client/role when a realm is loaded.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
7:53 a.m.
On 2/18/2016 2:07 AM, Stian Thorgersen wrote:
Having two many joins (fetching everything about a realm in one
query)
is probably going to be bad for performance, especially if there are
loads of clients and roles. There can also be large difference between
different vendors.
Another thing in the future we should separate clients out into a
separate store. There could be thousands of clients or even more. So
they should be treated in a similar fashion to users. Does that have
impact on how we improve/refactor/fix caching now?
As I said before, OIDC logout queries *ALL* clients to obtain a list of
valid redirects to compare against the redirect-uri passed to the logout
endpoint. That's about the only very frequent, non-adminstrative
function that requires obtaining a list of all clients. We also really
need a way to figure out of a realm invalidation is the result of the
realm being removed or just updated. Otherwise, you'll be evicting
thousands of clients and other realm related items every time a realm is
updated. Actually, maybe we're better off not evicting clients on a
realm removal, and just registering invalidations for every client in
the realm instead.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
7:56 a.m.
On 18 Feb 2016 13:53, "Bill Burke" <bburke(a)redhat.com> wrote:
On 2/18/2016 2:07 AM, Stian Thorgersen wrote:
>
> Having two many joins (fetching everything about a realm in one query)
is
probably going to be bad for performance, especially if there are loads
of clients and roles. There can also be large difference between different
vendors.
>
> Another thing in the future we should separate clients out into a
separate
store. There could be thousands of clients or even more. So they
should be treated in a similar fashion to users. Does that have impact on
how we improve/refactor/fix caching now?
>
As I said before, OIDC logout queries *ALL* clients to obtain a list of
valid
redirects to compare against the redirect-uri passed to the logout
endpoint. That's about the only very frequent, non-adminstrative function
that requires obtaining a list of all clients. We also really need a way
to figure out of a realm invalidation is the result of the realm being
removed or just updated. Otherwise, you'll be evicting thousands of
clients and other realm related items every time a realm is updated.
Actually, maybe we're better off not evicting clients on a realm removal,
and just registering invalidations for every client in the realm instead.
Why does OIDC logout need to list all clients? It used to just get the
clients that had client sessions for the specific user session.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
8:03 a.m.
On 2/18/2016 8:56 AM, Stian Thorgersen wrote:
On 18 Feb 2016 13:53, "Bill Burke" <bburke(a)redhat.com
<mailto:bburke@redhat.com>> wrote:
>
>
>
> On 2/18/2016 2:07 AM, Stian Thorgersen wrote:
>>
>> Having two many joins (fetching everything about a realm in one
query) is probably going to be bad for performance, especially if
there are loads of clients and roles. There can also be large
difference between different vendors.
>>
>> Another thing in the future we should separate clients out into a
separate store. There could be thousands of clients or even more. So
they should be treated in a similar fashion to users. Does that have
impact on how we improve/refactor/fix caching now?
>>
>
> As I said before, OIDC logout queries *ALL* clients to obtain a list
of valid redirects to compare against the redirect-uri passed to the
logout endpoint. That's about the only very frequent,
non-adminstrative function that requires obtaining a list of all
clients. We also really need a way to figure out of a realm
invalidation is the result of the realm being removed or just
updated. Otherwise, you'll be evicting thousands of clients and other
realm related items every time a realm is updated. Actually, maybe
we're better off not evicting clients on a realm removal, and just
registering invalidations for every client in the realm instead.
Why does OIDC logout need to list all clients? It used to just get the
clients that had client sessions for the specific user session.
>
OIDC logout endpoint has a redirect_uri parameter which tells keycloak
where to redirect *after* logout happens. This redirect_uri needs to be
checked. we may or may not know who initiated the logout request based
on the "id_token_hint" parameter, nor is it guaranteed that the
redirect-uri is in the list of clients that are part of the session.
This is one of the reasons why I wanted to create a generic query
cache. I could cache this list of redirect uri patterns and not load
every client.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
1:44 p.m.
I was thinking about this a bit more. On a DB removal, you actually
don't care if "child" elements don't get evicted from the cache. For
example, if a realm gets removed, you don't care if clients get removed
from cache or not because they will never be looked up again.
Eventually eviction policies will trigger and the old irrelevant cache
items will be gone.
On 2/18/2016 9:03 AM, Bill Burke wrote:
On 2/18/2016 8:56 AM, Stian Thorgersen wrote:
>
>
> On 18 Feb 2016 13:53, "Bill Burke" <bburke(a)redhat.com
> <mailto:bburke@redhat.com>> wrote:
> >
> >
> >
> > On 2/18/2016 2:07 AM, Stian Thorgersen wrote:
> >>
> >> Having two many joins (fetching everything about a realm in one
> query) is probably going to be bad for performance, especially if
> there are loads of clients and roles. There can also be large
> difference between different vendors.
> >>
> >> Another thing in the future we should separate clients out into a
> separate store. There could be thousands of clients or even more. So
> they should be treated in a similar fashion to users. Does that have
> impact on how we improve/refactor/fix caching now?
> >>
> >
> > As I said before, OIDC logout queries *ALL* clients to obtain a
> list of valid redirects to compare against the redirect-uri passed to
> the logout endpoint. That's about the only very frequent,
> non-adminstrative function that requires obtaining a list of all
> clients. We also really need a way to figure out of a realm
> invalidation is the result of the realm being removed or just
> updated. Otherwise, you'll be evicting thousands of clients and
> other realm related items every time a realm is updated. Actually,
> maybe we're better off not evicting clients on a realm removal, and
> just registering invalidations for every client in the realm instead.
>
> Why does OIDC logout need to list all clients? It used to just get
> the clients that had client sessions for the specific user session.
>
> >
>
OIDC logout endpoint has a redirect_uri parameter which tells keycloak
where to redirect *after* logout happens. This redirect_uri needs to
be checked. we may or may not know who initiated the logout request
based on the "id_token_hint" parameter, nor is it guaranteed that the
redirect-uri is in the list of clients that are part of the session.
This is one of the reasons why I wanted to create a generic query
cache. I could cache this list of redirect uri patterns and not load
every client.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
3215
days inactive
3216
days old
12 comments
4 participants
participants (4)
-
Bill Burke -
Marek Posolda -
Pedro Igor Silva -
Stian Thorgersen