10:45 p.m.
You don't necessarily 'need' it, but it makes the project an order of
magnitude more complicated to understand. The adapters are magic, but if
we aren't already familiar with something like Spring, then we really have
no way to fully understand what is going on. The other adapters such as
undertow as equally as intense. We don't need to understand all
infrastructure of course, but given there is an integration into an
existing workflow it makes it hard to use.
I would contribute a simple / clean Java example but I am still not sure
what that would even mean. Most threads I see around inspection say just
use XXX and don't worry. But I have found that to be dubious.
The aerogear team used using a Auth0 JWT inspection library which seems
like it is working.
The project is very well documented and there are tons of examples, but I
see every 2 weeks or so someone asks about token introspection as they are
trying to learn the best way to use Keycloak and basically get 3 responses
in until they get a 'dont worry about it' response, which really doesn't
help as it is rare to solve a more complicated problem without
understanding the basic problem.
We get the fear of missing using token inspection, but it sucks as a user
not to be able to get a clear example of 'Here is how you used to do it
with manually token inspection, now compare to the adapters' as opposed to
'read this intense doc and just simply integrate this adapter which you
don't understand' which has been what I have personally seen in digging
through 3 years of emails. Or the even better - "just google for industry
best practices on token inspection and use the existing libraries". For you
on the team it probably seems like such a trivial use case not even worth
mentioning but if you are new to Oauth/Keycloak/JWT and adapters, a simple
use case even if it was absolutely evil and going to cause WW3 would be
useful. Even as a blog post.
The use case is, I use keycloak to do a social sign-in, I get the token
back, using only self-contained Java (so calling libraries but not using
any json configs or adapters), how would I inspect the token to pull out
the email address and verify that token is still valid and actually came
from my keycloak server instead of being spoofed?
I know this is what adapters/json configs do for you (at least in theory, I
never got adapters to work), and there are existing libraries, but an all
in one laid out example direct from keycloak team would be awesome!
On Thu, Aug 10, 2017 at 8:58 AM, <keycloak-user-request(a)lists.jboss.org>
wrote:
Send keycloak-user mailing list submissions to
keycloak-user(a)lists.jboss.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.jboss.org/mailman/listinfo/keycloak-user
or, via email, send a message with subject or body 'help' to
keycloak-user-request(a)lists.jboss.org
You can reach the person managing the list at
keycloak-user-owner(a)lists.jboss.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of keycloak-user digest..."
Today's Topics:
1. Re: DB deadlock for concurrent logins (Vikrant Singh)
2. Re: token introspection (Pedro Igor Silva)
3. Re: JGroups failure: failed submitting DONT_BUNDLE message to
thread pool (Hynek Mlnarik)
----------------------------------------------------------------------
Message: 1
Date: Thu, 10 Aug 2017 17:06:33 +0530
From: Vikrant Singh <vikrant02.work(a)gmail.com>
Subject: Re: [keycloak-user] DB deadlock for concurrent logins
To: "keycloak-us." <keycloak-user(a)lists.jboss.org>
Message-ID:
<CACackctxEZcXL37cAMuS7ajhmdHyr_SHNGBT=qaz6Nw0W428oQ@mail.
gmail.com>
Content-Type: text/plain; charset="UTF-8"
Yes, but password migration should only be happening during first login. I
have checked the CREDENTIAL table in DB and user have already migrated to
new hashing algorithm and no of iterations, but still keycloak is trying to
run Update query for each login attempt.
-Vikrant
On Thu, Aug 10, 2017 at 4:18 PM, <keycloak-user-request(a)lists.jboss.org>
wrote:
>
>
> I believe that the default hashing algorithm has changed to SHA-256 as
> SHA-1 was recently in the news for being able to create hash
> collisions. Because of this change, each login will update the password
> hash stored with the 1st login of the user.
>
> Not sure why MariaDB would deadlock. Don't know enough about how that
> database performs locks. It is trying to update a foreign key that has
> an index associated with it. Maybe that has something to do with it.
>
>
>
> On 8/9/17 5:35 PM, Vikrant Singh wrote:
> > Hi,
> >
> > I am Running Keycloak 3.2.1.Final on openshift platform with MariaDB
> 10.2.7
> > for DB, recently upgraded from 3.1.0.Final.
> >
> > Deployment is consist of 3 keycloak servers along with 3 DB instances.
As
> > part of kubernetes rediness check, a token is requested for a local
user
> in
> > master realm every 10 sec. The concurrent token request for same user
is
> > causing the deadlock exception in DB. Following is the exception being
> > logged in keycloak.
> >
> >
> > Caused by: java.sql.SQLException: Deadlock found when trying to get
> > lock; try restarting transaction
> >
> > Query is: select userentity0_.ID as ID1_71_,
> > userentity0_.CREATED_TIMESTAMP as CREATED_2_71_, userentity0_.EMAIL as
> > EMAIL3_71_, userentity0_.EMAIL_CONSTRAINT as EMAIL_CO4_71_,
> > userentity0_.EMAIL_VERIFIED as EMAIL_VE5_71_, userentity0_.ENABLED as
> > ENABLED6_71_, userentity0_.FEDERATION_LINK as FEDERATI7_71_,
> > userentity0_.FIRST_NAME as FIRST_NA8_71_, userentity0_.LAST_NAME as
> > LAST_NAM9_71_, userentity0_.REALM_ID as REALM_I10_71_,
> > userentity0_.SERVICE_ACCOUNT_CLIENT_LINK as SERVICE11_71_,
> > userentity0_.USERNAME as USERNAM12_71_ from USER_ENTITY userentity0_
> > where userentity0_.ID=? and userentity0_.REALM_ID=?, parameters
> > ['ddafa525-baae-4c40-98f8-08c25a23f2c6','master']
> >
> > at org.mariadb.jdbc.internal.util.LogQueryTool.
exceptionWithQuery(
> LogQueryTool.java:146)
> >
> > at org.mariadb.jdbc.internal.protocol.AbstractQueryProtocol.
> executeQuery(AbstractQueryProtocol.java:221)
> >
> > at org.mariadb.jdbc.MariaDbPreparedStatementClient
> .executeInternal(MariaDbPreparedStatementClient.java:218)
> >
> > ... 76 more
> >
> >
> > Caused by: java.sql.SQLException: Lock wait timeout exceeded; try
> > restarting transaction
> >
> > Query is: update CREDENTIAL set ALGORITHM=?, COUNTER=?,
> > CREATED_DATE=?, DEVICE=?, DIGITS=?, HASH_ITERATIONS=?, PERIOD=?,
> > SALT=?, TYPE=?, USER_ID=?, VALUE=? where ID=?, parameters
> >
['pbkdf2-sha256',0,1501750736628,<null>,0,27500,0,<bytearray:???7'3^
> >
.??LT???>,'password','ddafa525-baae-4c40-98f8-08c25a23f2c6','
> Hdpx8Zg5Ec8M9qVUp+Ylwlje+nhcGAzVPStF6/cvrqZghTeby048b8d3uqExfzS0of/
> 9Quwx9CROGKTC685Tpw==','5929a82b-542c-4597-b3eb-524d74e58919']
> >
> > at org.mariadb.jdbc.internal.util.LogQueryTool.
exceptionWithQuery(
> LogQueryTool.java:146)
> >
> > at org.mariadb.jdbc.internal.protocol.AbstractQueryProtocol.
> executeQuery(AbstractQueryProtocol.java:221)
> >
> > at org.mariadb.jdbc.MariaDbPreparedStatementClient
> .executeInternal(MariaDbPreparedStatementClient.java:218)
> >
> > ... 78 more
> >
> >
> > Why keycloak is trying to update the user credential for every login.
> > and why is deadlock occurring? Any help truly appreciated.
> >
> >
> > Thanks,
> >
> > Vikrant
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>
------------------------------
Message: 2
Date: Thu, 10 Aug 2017 08:53:23 -0300
From: Pedro Igor Silva <psilva(a)redhat.com>
Subject: Re: [keycloak-user] token introspection
To: Simon Payne <simonpayne58(a)gmail.com>
Cc: keycloak-user <keycloak-user(a)lists.jboss.org>
Message-ID:
<CAJrcDBfFW3M4yauqgn=eG8Wnp=MnPkpQ4OFjeyoUZPLowm=1EQ@mail.
gmail.com>
Content-Type: text/plain; charset="UTF-8"
No, we don't. Like Bill said, you don't really need it. Basically, what we
support is described in docs [1].
[1]
http://www.keycloak.org/docs/3.1/authorization_services/
topics/enforcer/keycloak-enforcement-filter.html
On Thu, Aug 10, 2017 at 6:11 AM, Simon Payne <simonpayne58(a)gmail.com>
wrote:
> do we have token introspection implemented in any of the client adapters
> (other than spring boot)?
>
> thanks
>
>
> On Wed, Aug 9, 2017 at 9:50 AM, Simon Payne <simonpayne58(a)gmail.com>
> wrote:
>
> > thanks Pedro,
> >
> > however, i think our use cases are not exactly the same. it appears
your
> > component is set to allow authentication of user where mine is bearer
> only.
> >
> > the only other differences i can see between our projects is that i am
> > running gradle with keycloak 3.2.0 and that i have also added compile(
> > 'org.keycloak:keycloak-authz-client:3.2.0.CR1')
> >
> > Lucian, i don't have a project which i can share at the moment as other
> > code is included, if you would still like to see something i can make a
> > shareable version.
> >
> > Thanks
> >
> >
> > On Tue, Aug 8, 2017 at 8:57 PM, Pedro Igor Silva <psilva(a)redhat.com>
> > wrote:
> >
> >> Hey Lucian, we have this https://github.com/keycloak/ke
> >> ycloak-quickstarts/tree/latest/app-authz-springboot.
> >>
> >> On Tue, Aug 8, 2017 at 1:17 PM, Lucian Ochian <okianl(a)yahoo.com>
wrote:
> >>
> >>> Simon,
> >>> Do you have a demo app with that? I am just curious to see a
> >>> spring(boot) app with authorizations...I remember that I tried
> something
> >>> with authorizations, and the authorization context was null(I know
> there
> >>> are some Jira issues about it), but I still could not get it to work
in
> >>> 2.5.5
> >>> AuthorizationContext authzContext =
> >>> keycloakSecurityContext.getAuthorizationContext();
> >>> Thanks,Lucian
> >>>
> >>> On Tuesday, August 8, 2017, 10:25:35 AM CDT, Simon Payne <
> >>> simonpayne58(a)gmail.com> wrote:
> >>>
> >>> yes correct.
> >>>
> >>> there is a definite change in behavior with the addition of the
> >>> keycloak.policy-enforcer-config.online-introspection=true flag, as
> >>> without
> >>> this single line in my property file it works correctly as a bearer
> only
> >>> resource server. Addition of this line results in the incorrect call
> to
> >>> token exchange endpoint.
> >>>
> >>> thanks
> >>>
> >>>
> >>> On Tue, Aug 8, 2017 at 3:28 PM, Bill Burke <bburke(a)redhat.com>
wrote:
> >>>
> >>> > Doesn't look like the switch is hooked up to anything. As it
is,
it
> >>> > looks like this switch was added for RPT validation, not access
token
> >>> > validation, and not ever implemented. You just want the adapter
to
> >>> > validate the access token with the auth server for bearer token
> >>> > requests, right?
> >>> >
> >>> >
> >>> > On 8/8/17 9:29 AM, Bill Burke wrote:
> >>> > > I'm looking at the code on server and I dont' see
that it
requires
> >>> any
> >>> > > special switch to use it. The endpoint is:
> >>> > >
> >>> > > @Post
> >>> > >
> >>> > >
/auth/realms/{realm}/protocol/openid-connect/token/introspect
> >>> > >
> >>> > > Takes form params.
> >>> > >
> >>> > > token
> >>> > >
> >>> > > token_type_hint (optional and defaults to
"access_token")
> >>> > >
> >>> > >
> >>> > >
> >>> > >
> >>> > >
> >>> > > On 8/8/17 4:31 AM, Simon Payne wrote:
> >>> > >> after some debugging i figured that
> >>> > >>
keycloak.policy-enforcer-config.online-introspection=true
> switched
> >>> on
> >>> > this
> >>> > >> functionality, however it appears to error on a 400
after
making a
> >>> call
> >>> > to
> >>> > >> the /auth/realms/master/protocol/openid-connect/token
endpoint.
> >>> > >>
> >>> > >> I'm assuming this is a bug?
> >>> > >>
> >>> > >> Thanks
> >>> > >>
> >>> > >>
> >>> > >>
> >>> > >> On Mon, Aug 7, 2017 at 3:10 PM, Simon Payne <
> simonpayne58(a)gmail.com
> >>> >
> >>> > wrote:
> >>> > >>
> >>> > >>> Hi All,
> >>> > >>>
> >>> > >>> I'm evaluating keycloak and i'm currently
looking at token
> >>> > introspection.
> >>> > >>>
> >>> > >>> I've managed to achieve this manually, i.e. by
sending a post
via
> >>> > postman,
> >>> > >>> but i'm unable to figure out whether this can be
achieved via
the
> >>> > keycloak
> >>> > >>> adapters, specifically spring boot.
> >>> > >>>
> >>> > >>> any help in this area would be appreciated.
> >>> > >>>
> >>> > >>> thanks
> >>> > >>>
> >>> > >>> Simon.
> >>> > >>>
> >>> > >> _______________________________________________
> >>> > >> keycloak-user mailing list
> >>> > >> keycloak-user(a)lists.jboss.org
> >>> > >> https://lists.jboss.org/mailman/listinfo/keycloak-user
> >>> > > _______________________________________________
> >>> > > keycloak-user mailing list
> >>> > > keycloak-user(a)lists.jboss.org
> >>> > > https://lists.jboss.org/mailman/listinfo/keycloak-user
> >>> >
> >>> > _______________________________________________
> >>> > keycloak-user mailing list
> >>> > keycloak-user(a)lists.jboss.org
> >>> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> >>> >
> >>> _______________________________________________
> >>> keycloak-user mailing list
> >>> keycloak-user(a)lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-user
> >>> _______________________________________________
> >>> keycloak-user mailing list
> >>> keycloak-user(a)lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-user
> >>>
> >>
> >>
> >
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
------------------------------
Message: 3
Date: Thu, 10 Aug 2017 14:32:50 +0200
From: Hynek Mlnarik <hmlnarik(a)redhat.com>
Subject: Re: [keycloak-user] JGroups failure: failed submitting
DONT_BUNDLE message to thread pool
To: Edwin de Jong <edwin.de.jong(a)simacan.com>
Cc: keycloak-user <keycloak-user(a)lists.jboss.org>
Message-ID:
<CAMvXD=HpizBoVGpVALHnmkwJHLFzh3U6tNwVbkTwi+Lwa-XTsw@mail.
gmail.com>
Content-Type: text/plain; charset="UTF-8"
You seem to be facing https://issues.jboss.org/browse/WFLY-6179. Once
keycloak updates to WF 10.1/11.x, this issue should be resolved.
On Wed, Aug 9, 2017 at 1:32 PM, Edwin de Jong <edwin.de.jong(a)simacan.com>
wrote:
> Dear Keycloak users (and devs),
>
> This morning, we faced a production level issue on our Keycloak Cluster,
> running in a 3-node formation on EC2. Symptoms were a high failure rate
> of requests (> 20%) and high latency (> 10 seconds). We are currently
> trying to figure out what went wrong. We would appreciate it if someone
> with knowledge op JGroups / Inifinispan could chime in with a working
> hypothesis.
>
> About priority: we are currently running nominally. We have brought down
> two of the instances and brought up two new instances. The cluster is
> working again as expected.
>
> Below I'll give information about our setup, the relevant log-messages
> and links to some screenshots of our monitoring:
>
> EC2 instances are C4.Large (3x)
> Keycloak Version 3.1.0-FINAL
>
> Normal CPU usage is around 1% or less. It peaked to 16% during the
incident.
> Memory usage is normal.
>
> Screenshots:
>
> - datadog statistics of our services calling keycloak:
https://ibb.co/dsDTKv
> - AWS EC2 instance Cloudwatch statistics: network out rate (in bytes per
> MINUTE): https://ibb.co/j8jhCF
> - AWS EC2 instance Cloudwatch statistics: network in rate (in bytes per
> MINUTE): https://ibb.co/ggLuRa
>
> Log lines, just before failure (to help reduce clutter, I've removed the
> date and replaced the IP addresses with "IP-A", "IP-B",
"IP-C"). The
> last message is repeated around 500.000 times in the span of around 1
> minute.
>
> ---------------------->%-----------------------
> 05:09:23,925 INFO
> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> (Incoming-17,ee,ip-B) ISPN000094: Received new cluster view for channel
> server: [ip-A|3] (2) [ip-A, ip-B]
> 05:09:23,926 INFO
> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> (Incoming-17,ee,ip-B) ISPN000094: Received new cluster view for channel
> keycloak: [ip-A|3] (2) [ip-A, ip-B]
> 05:09:23,926 INFO
> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> (Incoming-17,ee,ip-B) ISPN000094: Received new cluster view for channel
> web: [ip-A|3] (2) [ip-A, ip-B]
> 05:09:23,926 INFO
> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> (Incoming-17,ee,ip-B) ISPN000094: Received new cluster view for channel
> ejb: [ip-A|3] (2) [ip-A, ip-B]
> 05:09:23,928 INFO
> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> (Incoming-17,ee,ip-B) ISPN000094: Received new cluster view for channel
> hibernate: [ip-A|3] (2) [ip-A, ip-B]
> 05:09:23,990 INFO
> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> (Incoming-1,ee,ip-A) ISPN000094: Received new cluster view for channel
> server: [ip-A|3] (2) [ip-A, ip-B]
> 05:09:23,990 INFO
> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> (Incoming-1,ee,ip-A) ISPN000094: Received new cluster view for channel
> keycloak: [ip-A|3] (2) [ip-A, ip-B]
> 05:09:23,991 INFO
> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> (Incoming-1,ee,ip-A) ISPN000094: Received new cluster view for channel
> web: [ip-A|3] (2) [ip-A, ip-B]
> 05:09:23,992 INFO
> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> (Incoming-1,ee,ip-A) ISPN000094: Received new cluster view for channel
> hibernate: [ip-A|3] (2) [ip-A, ip-B]
> 05:09:23,992 INFO
> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> (Incoming-1,ee,ip-A) ISPN000094: Received new cluster view for channel
> ejb: [ip-A|3] (2) [ip-A, ip-B]
> 05:09:23,996 INFO [org.infinispan.CLUSTER] (transport-thread--p14-t18)
> ISPN000310: Starting cluster-wide rebalance for cache authorization,
> topology CacheTopology{id=6, rebalanceId=3,
> currentCH=DefaultConsistentHash{ns=80, owners = (2)[ip-A: 54+26, ip-B:
> 26+54]}, pendingCH=DefaultConsistentHash{ns=80, owners = (2)[ip-A:
> 40+40, ip-B: 40+40]}, unionCH=null, actualMembers=[ip-A, ip-B]}
> 05:09:24,001 INFO [org.infinispan.CLUSTER] (transport-thread--p14-t18)
> ISPN000310: Starting cluster-wide rebalance for cache sessions, topology
> CacheTopology{id=6, rebalanceId=3,
> currentCH=DefaultConsistentHash{ns=80, owners = (2)[ip-A: 54+26, ip-B:
> 26+54]}, pendingCH=DefaultConsistentHash{ns=80, owners = (2)[ip-A:
> 40+40, ip-B: 40+40]}, unionCH=null, actualMembers=[ip-A, ip-B]}
> 05:09:24,004 INFO [org.infinispan.CLUSTER] (transport-thread--p14-t18)
> ISPN000310: Starting cluster-wide rebalance for cache offlineSessions,
> topology CacheTopology{id=6, rebalanceId=3,
> currentCH=DefaultConsistentHash{ns=80, owners = (2)[ip-A: 54+26, ip-B:
> 26+54]}, pendingCH=DefaultConsistentHash{ns=80, owners = (2)[ip-A:
> 40+40, ip-B: 40+40]}, unionCH=null, actualMembers=[ip-A, ip-B]}
> 05:09:24,014 INFO [org.infinispan.CLUSTER] (transport-thread--p14-t18)
> ISPN000310: Starting cluster-wide rebalance for cache loginFailures,
> topology CacheTopology{id=6, rebalanceId=3,
> currentCH=DefaultConsistentHash{ns=80, owners = (2)[ip-A: 54+26, ip-B:
> 26+54]}, pendingCH=DefaultConsistentHash{ns=80, owners = (2)[ip-A:
> 40+40, ip-B: 40+40]}, unionCH=null, actualMembers=[ip-A, ip-B]}
> 05:09:24,027 INFO [org.infinispan.CLUSTER] (remote-thread--p7-t130)
> ISPN000336: Finished cluster-wide rebalance for cache sessions, topology
> id = 6
> 05:09:24,028 INFO [org.infinispan.CLUSTER] (remote-thread--p7-t130)
> ISPN000336: Finished cluster-wide rebalance for cache offlineSessions,
> topology id = 6
> 05:09:24,029 INFO [org.infinispan.CLUSTER] (remote-thread--p7-t131)
> ISPN000336: Finished cluster-wide rebalance for cache loginFailures,
> topology id = 6
> 05:09:24,029 INFO [org.infinispan.CLUSTER] (remote-thread--p7-t132)
> ISPN000336: Finished cluster-wide rebalance for cache authorization,
> topology id = 6
> 05:09:33,567 INFO
> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> (Incoming-1,ee,ip-C) ISPN000093: Received new, MERGED cluster view for
> channel server: MergeView::[ip-A|4] (3) [ip-A, ip-B, ip-C], 2 subgroups:
> [ip-A|2] (3) [ip-A, ip-C, ip-B], [ip-A|3] (2) [ip-A, ip-B]
> 05:09:33,569 INFO
> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> (Incoming-1,ee,ip-C) ISPN000093: Received new, MERGED cluster view for
> channel keycloak: MergeView::[ip-A|4] (3) [ip-A, ip-B, ip-C], 2
> subgroups: [ip-A|2] (3) [ip-A, ip-C, ip-B], [ip-A|3] (2) [ip-A, ip-B]
> 05:09:33,569 INFO
> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> (Incoming-1,ee,ip-C) ISPN000093: Received new, MERGED cluster view for
> channel web: MergeView::[ip-A|4] (3) [ip-A, ip-B, ip-C], 2 subgroups:
> [ip-A|2] (3) [ip-A, ip-C, ip-B], [ip-A|3] (2) [ip-A, ip-B]
> 05:09:33,573 INFO
> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> (Incoming-1,ee,ip-C) ISPN000093: Received new, MERGED cluster view for
> channel ejb: MergeView::[ip-A|4] (3) [ip-A, ip-B, ip-C], 2 subgroups:
> [ip-A|2] (3) [ip-A, ip-C, ip-B], [ip-A|3] (2) [ip-A, ip-B]
> 05:09:33,575 INFO
> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> (Incoming-1,ee,ip-C) ISPN000093: Received new, MERGED cluster view for
> channel hibernate: MergeView::[ip-A|4] (3) [ip-A, ip-B, ip-C], 2
> subgroups: [ip-A|2] (3) [ip-A, ip-C, ip-B], [ip-A|3] (2) [ip-A, ip-B]
> 05:09:33,521 WARN [org.jgroups.protocols.pbcast.NAKACK]
> (Incoming-19,ee,ip-B) JGRP000011: ip-B: dropped message 54375 from
> non-member ip-C (view=[ip-A|3] (2) [ip-A, ip-B]) Warning
> 05:09:33,527 INFO
> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> (Incoming-20,ee,ip-B) ISPN000093: Received new, MERGED cluster view for
> channel server: MergeView::[ip-A|4] (3) [ip-A, ip-B, ip-C], 2 subgroups:
> [ip-A|2] (3) [ip-A, ip-C, ip-B], [ip-A|3] (2) [ip-A, ip-B]
> 05:09:33,529 INFO
> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> (Incoming-20,ee,ip-B) ISPN000093: Received new, MERGED cluster view for
> channel keycloak: MergeView::[ip-A|4] (3) [ip-A, ip-B, ip-C], 2
> subgroups: [ip-A|2] (3) [ip-A, ip-C, ip-B], [ip-A|3] (2) [ip-A, ip-B]
> 05:09:33,529 INFO
> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> (Incoming-20,ee,ip-B) ISPN000093: Received new, MERGED cluster view for
> channel web: MergeView::[ip-A|4] (3) [ip-A, ip-B, ip-C], 2 subgroups:
> [ip-A|2] (3) [ip-A, ip-C, ip-B], [ip-A|3] (2) [ip-A, ip-B]
> 05:09:33,530 INFO
> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> (Incoming-20,ee,ip-B) ISPN000093: Received new, MERGED cluster view for
> channel ejb: MergeView::[ip-A|4] (3) [ip-A, ip-B, ip-C], 2 subgroups:
> [ip-A|2] (3) [ip-A, ip-C, ip-B], [ip-A|3] (2) [ip-A, ip-B]
> 05:09:33,533 INFO
> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> (Incoming-20,ee,ip-B) ISPN000093: Received new, MERGED cluster view for
> channel hibernate: MergeView::[ip-A|4] (3) [ip-A, ip-B, ip-C], 2
> subgroups: [ip-A|2] (3) [ip-A, ip-C, ip-B], [ip-A|3] (2) [ip-A, ip-B]
> 05:09:33,518 INFO
> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> (Incoming-7,ee,ip-A) ISPN000093: Received new, MERGED cluster view for
> channel server: MergeView::[ip-A|4] (3) [ip-A, ip-B, ip-C], 2 subgroups:
> [ip-A|2] (3) [ip-A, ip-C, ip-B], [ip-A|3] (2) [ip-A, ip-B]
> 05:09:33,525 INFO
> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> (Incoming-7,ee,ip-A) ISPN000093: Received new, MERGED cluster view for
> channel keycloak: MergeView::[ip-A|4] (3) [ip-A, ip-B, ip-C], 2
> subgroups: [ip-A|2] (3) [ip-A, ip-C, ip-B], [ip-A|3] (2) [ip-A, ip-B]
> 05:09:33,525 INFO
> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> (Incoming-7,ee,ip-A) ISPN000093: Received new, MERGED cluster view for
> channel web: MergeView::[ip-A|4] (3) [ip-A, ip-B, ip-C], 2 subgroups:
> [ip-A|2] (3) [ip-A, ip-C, ip-B], [ip-A|3] (2) [ip-A, ip-B]
> 05:09:33,527 INFO
> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> (Incoming-7,ee,ip-A) ISPN000093: Received new, MERGED cluster view for
> channel hibernate: MergeView::[ip-A|4] (3) [ip-A, ip-B, ip-C], 2
> subgroups: [ip-A|2] (3) [ip-A, ip-C, ip-B], [ip-A|3] (2) [ip-A, ip-B]
> 05:09:33,527 INFO
> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> (Incoming-7,ee,ip-A) ISPN000093: Received new, MERGED cluster view for
> channel ejb: MergeView::[ip-A|4] (3) [ip-A, ip-B, ip-C], 2 subgroups:
> [ip-A|2] (3) [ip-A, ip-C, ip-B], [ip-A|3] (2) [ip-A, ip-B]
> 05:09:33,577 INFO [org.infinispan.CLUSTER] (transport-thread--p14-t12)
> ISPN000310: Starting cluster-wide rebalance for cache authorization,
> topology CacheTopology{id=10, rebalanceId=3,
> currentCH=DefaultConsistentHash{ns=80, owners = (3)[ip-A: 27+53, ip-C:
> 27+53, ip-B: 26+54]}, pendingCH=DefaultConsistentHash{ns=80, owners =
> (3)[ip-A: 27+53, ip-B: 26+54, ip-C: 27+53]}, unionCH=null,
> actualMembers=[ip-A, ip-B, ip-C]}
> 05:09:33,579 INFO [org.infinispan.CLUSTER] (transport-thread--p14-t12)
> ISPN000310: Starting cluster-wide rebalance for cache offlineSessions,
> topology CacheTopology{id=10, rebalanceId=3,
> currentCH=DefaultConsistentHash{ns=80, owners = (3)[ip-A: 27+53, ip-C:
> 27+53, ip-B: 26+54]}, pendingCH=DefaultConsistentHash{ns=80, owners =
> (3)[ip-A: 27+53, ip-B: 26+54, ip-C: 27+53]}, unionCH=null,
> actualMembers=[ip-A, ip-B, ip-C]}
> 05:09:33,580 INFO [org.infinispan.CLUSTER] (transport-thread--p14-t12)
> ISPN000310: Starting cluster-wide rebalance for cache loginFailures,
> topology CacheTopology{id=10, rebalanceId=3,
> currentCH=DefaultConsistentHash{ns=80, owners = (3)[ip-A: 27+53, ip-C:
> 27+53, ip-B: 26+54]}, pendingCH=DefaultConsistentHash{ns=80, owners =
> (3)[ip-A: 27+53, ip-B: 26+54, ip-C: 27+53]}, unionCH=null,
> actualMembers=[ip-A, ip-B, ip-C]}
> 05:09:33,582 INFO [org.infinispan.CLUSTER] (transport-thread--p14-t15)
> ISPN000310: Starting cluster-wide rebalance for cache sessions, topology
> CacheTopology{id=10, rebalanceId=3,
> currentCH=DefaultConsistentHash{ns=80, owners = (3)[ip-A: 27+53, ip-C:
> 27+53, ip-B: 26+54]}, pendingCH=DefaultConsistentHash{ns=80, owners =
> (3)[ip-A: 27+53, ip-B: 26+54, ip-C: 27+53]}, unionCH=null,
> actualMembers=[ip-A, ip-B, ip-C]}
> 05:09:33,589 INFO [org.infinispan.CLUSTER] (remote-thread--p7-t130)
> ISPN000336: Finished cluster-wide rebalance for cache loginFailures,
> topology id = 10
> 05:09:33,589 INFO [org.infinispan.CLUSTER] (remote-thread--p7-t130)
> ISPN000336: Finished cluster-wide rebalance for cache authorization,
> topology id = 10
> 05:09:33,590 INFO [org.infinispan.CLUSTER] (remote-thread--p7-t131)
> ISPN000336: Finished cluster-wide rebalance for cache offlineSessions,
> topology id = 10
> 05:09:33,601 INFO [org.infinispan.CLUSTER] (remote-thread--p7-t133)
> ISPN000336: Finished cluster-wide rebalance for cache sessions, topology
> id = 10
> 05:09:34,001 ERROR [org.jgroups.protocols.TCP] (Connection.Receiver
> [IP-A:35361 - IP-C:7600],ee,ip-A) ip-A: failed submitting DONT_BUNDLE
> message to thread pool: java.util.concurrent.RejectedExecutionException:
> Task org.jgroups.protocols.TP$SingleMessageHandler@17c86a0c rejected
> from java.util.concurrent.ThreadPoolExecutor@52cae691[Running, pool size
> = 4, active threads = 4, queued tasks = 100, completed tasks = 1589693].
> Msg: RequestCorrelator: id=200, type=REQ, id=607, rsp_expected=true,
> FORK: ee:keycloak, NAKACK: [XMIT_RSP, seqno=206], TCP: [cluster_name=ee]
> ERROR
> 05:09:34,010 ERROR [org.jgroups.protocols.TCP] (Connection.Receiver
> [IP-A:35361 - IP-C:7600],ee,ip-A) ip-A: failed submitting DONT_BUNDLE
> message to thread pool: java.util.concurrent.RejectedExecutionException:
> Task org.jgroups.protocols.TP$SingleMessageHandler@4fec3655 rejected
> from java.util.concurrent.ThreadPoolExecutor@52cae691[Running, pool size
> = 4, active threads = 4, queued tasks = 100, completed tasks = 1589694].
> Msg: RequestCorrelator: id=200, type=REQ, id=609, rsp_expected=true,
> FORK: ee:keycloak, NAKACK: [XMIT_RSP, seqno=208], TCP: [cluster_name=ee]
> ERROR
>
> (last line repeated many, many times)
> ---------------------->%-----------------------
>
>
>
> Infinispan subsystem configuration in standalone-ha.xml:
>
> ---------------------->%-----------------------
> <subsystem xmlns="urn:jboss:domain:infinispan:4.0">
> <cache-container name="keycloak"
jndi-name="infinispan/Keycloak">
> <transport lock-timeout="60000"/>
> <local-cache name="realms">
> <eviction max-entries="10000" strategy="LRU"/>
> </local-cache>
> <local-cache name="users">
> <eviction max-entries="10000" strategy="LRU"/>
> </local-cache>
> <distributed-cache name="sessions" mode="SYNC"
owners="3"/>
> <distributed-cache name="offlineSessions"
mode="SYNC"
owners="3"/>
> <distributed-cache name="loginFailures" mode="SYNC"
owners="3"/>
> <distributed-cache name="authorization" mode="SYNC"
owners="3"/>
> <replicated-cache name="work" mode="SYNC"/>
> <local-cache name="keys">
> <eviction max-entries="1000" strategy="LRU"/>
> <expiration max-idle="3600000"/>
> </local-cache>
> </cache-container>
> <cache-container name="server" aliases="singleton
cluster"
> default-cache="default"
module="org.wildfly.clustering.server">
> <transport lock-timeout="60000"/>
> <replicated-cache name="default" mode="SYNC">
> <transaction mode="BATCH"/>
> </replicated-cache>
> </cache-container>
> <cache-container name="web" default-cache="dist"
> module="org.wildfly.clustering.web.infinispan">
> <transport lock-timeout="60000"/>
> <distributed-cache name="dist" mode="ASYNC"
l1-lifespan="0"
> owners="2">
> <locking isolation="REPEATABLE_READ"/>
> <transaction mode="BATCH"/>
> <file-store/>
> </distributed-cache>
> </cache-container>
> <cache-container name="ejb" aliases="sfsb"
default-cache="dist"
> module="org.wildfly.clustering.ejb.infinispan">
> <transport lock-timeout="60000"/>
> <distributed-cache name="dist" mode="ASYNC"
l1-lifespan="0"
> owners="2">
> <locking isolation="REPEATABLE_READ"/>
> <transaction mode="BATCH"/>
> <file-store/>
> </distributed-cache>
> </cache-container>
> <cache-container name="hibernate"
default-cache="local-query"
> module="org.hibernate.infinispan">
> <transport lock-timeout="60000"/>
> <local-cache name="local-query">
> <eviction strategy="LRU" max-entries="10000"/>
> <expiration max-idle="100000"/>
> </local-cache>
> <invalidation-cache name="entity" mode="SYNC">
> <transaction mode="NON_XA"/>
> <eviction strategy="LRU" max-entries="10000"/>
> <expiration max-idle="100000"/>
> </invalidation-cache>
> <replicated-cache name="timestamps"
mode="ASYNC"/>
> </cache-container>
> </subsystem>
> ---------------------->%-----------------------
>
> JGroups subsystem configuration:
>
> ---------------------->%-----------------------
> <subsystem xmlns="urn:jboss:domain:jgroups:4.0"
default-stack="tcp">
> <channels default="ee">
> <channel name="ee" stack="tcp"/>
> </channels>
> <stacks>
> <stack name="tcp">
> <transport type="TCP"
socket-binding="jgroups-tcp"/>
> <protocol type="S3_PING">
> <property
name="access_key">S3AccessKey</property>
> <property name="secret_access_key">
S3SecretAccessKey</property>
> <property
name="location">S3PingBucketName</property>
> </protocol>
> <protocol type="MERGE2"/>
> <protocol type="FD_SOCK"
socket-binding="jgroups-tcp-fd"/>
> <protocol type="FD"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK"/>
> <protocol type="UNICAST2"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="UFC"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> <stack name="udp">
> <transport type="UDP"
socket-binding="jgroups-udp"/>
> <protocol type="PING"/>
> <protocol type="MERGE3"/>
> <protocol type="FD_SOCK"
socket-binding="jgroups-udp-fd"/>
> <protocol type="FD_ALL"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="UFC"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> </stack>
> </stacks>
> </subsystem>
> ---------------------->%-----------------------
>
> with kind regards,
>
> Edwin de Jong
>
> -- Simacan B.V. Data Engineer
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
--
--Hynek
------------------------------
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
End of keycloak-user Digest, Vol 44, Issue 23
*********************************************
12:12 a.m.
New subject: token introspection
In my organisation the support for token introspection comes with the added
security that if an access token is revoked, then the activity ceases.
Using JWT verification, a potential fraudulent use of access token has
until token expiry as only refresh token is revoked. This is often enough
for architects to make a decision one way or another depending upon the use
case.
As an aside, i have managed to get spring-security-oauth2 working against
keycloak, but this library also appears to not support token
introspection. However, spring security, in my opinion, is easier to
inject custom services or filters to add a manual token introspection step
if required.
On Thu, Aug 10, 2017 at 2:45 PM, Doug Drouillard <
douglas.drouillard(a)gmail.com> wrote:
You don't necessarily 'need' it, but it makes the project
an order of
magnitude more complicated to understand. The adapters are magic, but if
we aren't already familiar with something like Spring, then we really have
no way to fully understand what is going on. The other adapters such as
undertow as equally as intense. We don't need to understand all
infrastructure of course, but given there is an integration into an
existing workflow it makes it hard to use.
I would contribute a simple / clean Java example but I am still not sure
what that would even mean. Most threads I see around inspection say just
use XXX and don't worry. But I have found that to be dubious.
The aerogear team used using a Auth0 JWT inspection library which seems
like it is working.
The project is very well documented and there are tons of examples, but I
see every 2 weeks or so someone asks about token introspection as they are
trying to learn the best way to use Keycloak and basically get 3 responses
in until they get a 'dont worry about it' response, which really doesn't
help as it is rare to solve a more complicated problem without
understanding the basic problem.
We get the fear of missing using token inspection, but it sucks as a user
not to be able to get a clear example of 'Here is how you used to do it
with manually token inspection, now compare to the adapters' as opposed to
'read this intense doc and just simply integrate this adapter which you
don't understand' which has been what I have personally seen in digging
through 3 years of emails. Or the even better - "just google for industry
best practices on token inspection and use the existing libraries". For you
on the team it probably seems like such a trivial use case not even worth
mentioning but if you are new to Oauth/Keycloak/JWT and adapters, a simple
use case even if it was absolutely evil and going to cause WW3 would be
useful. Even as a blog post.
The use case is, I use keycloak to do a social sign-in, I get the token
back, using only self-contained Java (so calling libraries but not using
any json configs or adapters), how would I inspect the token to pull out
the email address and verify that token is still valid and actually came
from my keycloak server instead of being spoofed?
I know this is what adapters/json configs do for you (at least in theory, I
never got adapters to work), and there are existing libraries, but an all
in one laid out example direct from keycloak team would be awesome!
On Thu, Aug 10, 2017 at 8:58 AM, <keycloak-user-request(a)lists.jboss.org>
wrote:
> Send keycloak-user mailing list submissions to
> keycloak-user(a)lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/keycloak-user
> or, via email, send a message with subject or body 'help' to
> keycloak-user-request(a)lists.jboss.org
>
> You can reach the person managing the list at
> keycloak-user-owner(a)lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of keycloak-user digest..."
>
>
> Today's Topics:
>
> 1. Re: DB deadlock for concurrent logins (Vikrant Singh)
> 2. Re: token introspection (Pedro Igor Silva)
> 3. Re: JGroups failure: failed submitting DONT_BUNDLE message to
> thread pool (Hynek Mlnarik)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 10 Aug 2017 17:06:33 +0530
> From: Vikrant Singh <vikrant02.work(a)gmail.com>
> Subject: Re: [keycloak-user] DB deadlock for concurrent logins
> To: "keycloak-us." <keycloak-user(a)lists.jboss.org>
> Message-ID:
> <CACackctxEZcXL37cAMuS7ajhmdHyr_SHNGBT=qaz6Nw0W428oQ@mail.
> gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Yes, but password migration should only be happening during first login.
I
> have checked the CREDENTIAL table in DB and user have already migrated to
> new hashing algorithm and no of iterations, but still keycloak is trying
to
> run Update query for each login attempt.
>
> -Vikrant
>
> On Thu, Aug 10, 2017 at 4:18 PM, <keycloak-user-request(a)lists.jboss.org>
> wrote:
> >
> >
> > I believe that the default hashing algorithm has changed to SHA-256 as
> > SHA-1 was recently in the news for being able to create hash
> > collisions. Because of this change, each login will update the
password
> > hash stored with the 1st login of the user.
> >
> > Not sure why MariaDB would deadlock. Don't know enough about how that
> > database performs locks. It is trying to update a foreign key that has
> > an index associated with it. Maybe that has something to do with it.
> >
> >
> >
> > On 8/9/17 5:35 PM, Vikrant Singh wrote:
> > > Hi,
> > >
> > > I am Running Keycloak 3.2.1.Final on openshift platform with MariaDB
> > 10.2.7
> > > for DB, recently upgraded from 3.1.0.Final.
> > >
> > > Deployment is consist of 3 keycloak servers along with 3 DB
instances.
> As
> > > part of kubernetes rediness check, a token is requested for a local
> user
> > in
> > > master realm every 10 sec. The concurrent token request for same user
> is
> > > causing the deadlock exception in DB. Following is the exception
being
> > > logged in keycloak.
> > >
> > >
> > > Caused by: java.sql.SQLException: Deadlock found when trying to get
> > > lock; try restarting transaction
> > >
> > > Query is: select userentity0_.ID as ID1_71_,
> > > userentity0_.CREATED_TIMESTAMP as CREATED_2_71_, userentity0_.EMAIL
as
> > > EMAIL3_71_, userentity0_.EMAIL_CONSTRAINT as EMAIL_CO4_71_,
> > > userentity0_.EMAIL_VERIFIED as EMAIL_VE5_71_, userentity0_.ENABLED as
> > > ENABLED6_71_, userentity0_.FEDERATION_LINK as FEDERATI7_71_,
> > > userentity0_.FIRST_NAME as FIRST_NA8_71_, userentity0_.LAST_NAME as
> > > LAST_NAM9_71_, userentity0_.REALM_ID as REALM_I10_71_,
> > > userentity0_.SERVICE_ACCOUNT_CLIENT_LINK as SERVICE11_71_,
> > > userentity0_.USERNAME as USERNAM12_71_ from USER_ENTITY userentity0_
> > > where userentity0_.ID=? and userentity0_.REALM_ID=?, parameters
> > > ['ddafa525-baae-4c40-98f8-08c25a23f2c6','master']
> > >
> > > at org.mariadb.jdbc.internal.util.LogQueryTool.
> exceptionWithQuery(
> > LogQueryTool.java:146)
> > >
> > > at org.mariadb.jdbc.internal.protocol.AbstractQueryProtocol.
> > executeQuery(AbstractQueryProtocol.java:221)
> > >
> > > at org.mariadb.jdbc.MariaDbPreparedStatementClient
> > .executeInternal(MariaDbPreparedStatementClient.java:218)
> > >
> > > ... 76 more
> > >
> > >
> > > Caused by: java.sql.SQLException: Lock wait timeout exceeded; try
> > > restarting transaction
> > >
> > > Query is: update CREDENTIAL set ALGORITHM=?, COUNTER=?,
> > > CREATED_DATE=?, DEVICE=?, DIGITS=?, HASH_ITERATIONS=?, PERIOD=?,
> > > SALT=?, TYPE=?, USER_ID=?, VALUE=? where ID=?, parameters
> > >
['pbkdf2-sha256',0,1501750736628,<null>,0,27500,0,<bytearray:???7'3^
> > >
.??LT???>,'password','ddafa525-baae-4c40-98f8-08c25a23f2c6','
> > Hdpx8Zg5Ec8M9qVUp+Ylwlje+nhcGAzVPStF6/cvrqZghTeby048b8d3uqExfzS0of/
> > 9Quwx9CROGKTC685Tpw==','5929a82b-542c-4597-b3eb-524d74e58919']
> > >
> > > at org.mariadb.jdbc.internal.util.LogQueryTool.
> exceptionWithQuery(
> > LogQueryTool.java:146)
> > >
> > > at org.mariadb.jdbc.internal.protocol.AbstractQueryProtocol.
> > executeQuery(AbstractQueryProtocol.java:221)
> > >
> > > at org.mariadb.jdbc.MariaDbPreparedStatementClient
> > .executeInternal(MariaDbPreparedStatementClient.java:218)
> > >
> > > ... 78 more
> > >
> > >
> > > Why keycloak is trying to update the user credential for every login.
> > > and why is deadlock occurring? Any help truly appreciated.
> > >
> > >
> > > Thanks,
> > >
> > > Vikrant
> > > _______________________________________________
> > > keycloak-user mailing list
> > > keycloak-user(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-user
> >
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 10 Aug 2017 08:53:23 -0300
> From: Pedro Igor Silva <psilva(a)redhat.com>
> Subject: Re: [keycloak-user] token introspection
> To: Simon Payne <simonpayne58(a)gmail.com>
> Cc: keycloak-user <keycloak-user(a)lists.jboss.org>
> Message-ID:
> <CAJrcDBfFW3M4yauqgn=eG8Wnp=MnPkpQ4OFjeyoUZPLowm=1EQ@mail.
> gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> No, we don't. Like Bill said, you don't really need it. Basically, what
we
> support is described in docs [1].
>
> [1]
> http://www.keycloak.org/docs/3.1/authorization_services/
> topics/enforcer/keycloak-enforcement-filter.html
>
>
> On Thu, Aug 10, 2017 at 6:11 AM, Simon Payne <simonpayne58(a)gmail.com>
> wrote:
>
> > do we have token introspection implemented in any of the client
adapters
> > (other than spring boot)?
> >
> > thanks
> >
> >
> > On Wed, Aug 9, 2017 at 9:50 AM, Simon Payne <simonpayne58(a)gmail.com>
> > wrote:
> >
> > > thanks Pedro,
> > >
> > > however, i think our use cases are not exactly the same. it appears
> your
> > > component is set to allow authentication of user where mine is bearer
> > only.
> > >
> > > the only other differences i can see between our projects is that i
am
> > > running gradle with keycloak 3.2.0 and that i have also added
compile(
> > > 'org.keycloak:keycloak-authz-client:3.2.0.CR1')
> > >
> > > Lucian, i don't have a project which i can share at the moment as
other
> > > code is included, if you would still like to see something i can
make a
> > > shareable version.
> > >
> > > Thanks
> > >
> > >
> > > On Tue, Aug 8, 2017 at 8:57 PM, Pedro Igor Silva
<psilva(a)redhat.com>
> > > wrote:
> > >
> > >> Hey Lucian, we have this https://github.com/keycloak/ke
> > >> ycloak-quickstarts/tree/latest/app-authz-springboot.
> > >>
> > >> On Tue, Aug 8, 2017 at 1:17 PM, Lucian Ochian
<okianl(a)yahoo.com>
> wrote:
> > >>
> > >>> Simon,
> > >>> Do you have a demo app with that? I am just curious to see a
> > >>> spring(boot) app with authorizations...I remember that I tried
> > something
> > >>> with authorizations, and the authorization context was null(I
know
> > there
> > >>> are some Jira issues about it), but I still could not get it to
work
> in
> > >>> 2.5.5
> > >>> AuthorizationContext authzContext =
> > >>> keycloakSecurityContext.getAuthorizationContext();
> > >>> Thanks,Lucian
> > >>>
> > >>> On Tuesday, August 8, 2017, 10:25:35 AM CDT, Simon Payne <
> > >>> simonpayne58(a)gmail.com> wrote:
> > >>>
> > >>> yes correct.
> > >>>
> > >>> there is a definite change in behavior with the addition of the
> > >>> keycloak.policy-enforcer-config.online-introspection=true flag,
as
> > >>> without
> > >>> this single line in my property file it works correctly as a
bearer
> > only
> > >>> resource server. Addition of this line results in the incorrect
call
> > to
> > >>> token exchange endpoint.
> > >>>
> > >>> thanks
> > >>>
> > >>>
> > >>> On Tue, Aug 8, 2017 at 3:28 PM, Bill Burke
<bburke(a)redhat.com>
> wrote:
> > >>>
> > >>> > Doesn't look like the switch is hooked up to anything.
As it is,
> it
> > >>> > looks like this switch was added for RPT validation, not
access
> token
> > >>> > validation, and not ever implemented. You just want the
adapter
to
> > >>> > validate the access token with the auth server for bearer
token
> > >>> > requests, right?
> > >>> >
> > >>> >
> > >>> > On 8/8/17 9:29 AM, Bill Burke wrote:
> > >>> > > I'm looking at the code on server and I dont'
see that it
> requires
> > >>> any
> > >>> > > special switch to use it. The endpoint is:
> > >>> > >
> > >>> > > @Post
> > >>> > >
> > >>> > >
/auth/realms/{realm}/protocol/openid-connect/token/introspect
> > >>> > >
> > >>> > > Takes form params.
> > >>> > >
> > >>> > > token
> > >>> > >
> > >>> > > token_type_hint (optional and defaults to
"access_token")
> > >>> > >
> > >>> > >
> > >>> > >
> > >>> > >
> > >>> > >
> > >>> > > On 8/8/17 4:31 AM, Simon Payne wrote:
> > >>> > >> after some debugging i figured that
> > >>> > >>
keycloak.policy-enforcer-config.online-introspection=true
> > switched
> > >>> on
> > >>> > this
> > >>> > >> functionality, however it appears to error on a 400
after
> making a
> > >>> call
> > >>> > to
> > >>> > >> the
/auth/realms/master/protocol/openid-connect/token
endpoint.
> > >>> > >>
> > >>> > >> I'm assuming this is a bug?
> > >>> > >>
> > >>> > >> Thanks
> > >>> > >>
> > >>> > >>
> > >>> > >>
> > >>> > >> On Mon, Aug 7, 2017 at 3:10 PM, Simon Payne <
> > simonpayne58(a)gmail.com
> > >>> >
> > >>> > wrote:
> > >>> > >>
> > >>> > >>> Hi All,
> > >>> > >>>
> > >>> > >>> I'm evaluating keycloak and i'm
currently looking at token
> > >>> > introspection.
> > >>> > >>>
> > >>> > >>> I've managed to achieve this manually, i.e.
by sending a post
> via
> > >>> > postman,
> > >>> > >>> but i'm unable to figure out whether this
can be achieved via
> the
> > >>> > keycloak
> > >>> > >>> adapters, specifically spring boot.
> > >>> > >>>
> > >>> > >>> any help in this area would be appreciated.
> > >>> > >>>
> > >>> > >>> thanks
> > >>> > >>>
> > >>> > >>> Simon.
> > >>> > >>>
> > >>> > >> _______________________________________________
> > >>> > >> keycloak-user mailing list
> > >>> > >> keycloak-user(a)lists.jboss.org
> > >>> > >>
https://lists.jboss.org/mailman/listinfo/keycloak-user
> > >>> > > _______________________________________________
> > >>> > > keycloak-user mailing list
> > >>> > > keycloak-user(a)lists.jboss.org
> > >>> > > https://lists.jboss.org/mailman/listinfo/keycloak-user
> > >>> >
> > >>> > _______________________________________________
> > >>> > keycloak-user mailing list
> > >>> > keycloak-user(a)lists.jboss.org
> > >>> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> > >>> >
> > >>> _______________________________________________
> > >>> keycloak-user mailing list
> > >>> keycloak-user(a)lists.jboss.org
> > >>> https://lists.jboss.org/mailman/listinfo/keycloak-user
> > >>> _______________________________________________
> > >>> keycloak-user mailing list
> > >>> keycloak-user(a)lists.jboss.org
> > >>> https://lists.jboss.org/mailman/listinfo/keycloak-user
> > >>>
> > >>
> > >>
> > >
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> >
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 10 Aug 2017 14:32:50 +0200
> From: Hynek Mlnarik <hmlnarik(a)redhat.com>
> Subject: Re: [keycloak-user] JGroups failure: failed submitting
> DONT_BUNDLE message to thread pool
> To: Edwin de Jong <edwin.de.jong(a)simacan.com>
> Cc: keycloak-user <keycloak-user(a)lists.jboss.org>
> Message-ID:
> <CAMvXD=HpizBoVGpVALHnmkwJHLFzh3U6tNwVbkTwi+Lwa-XTsw@mail.
> gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> You seem to be facing https://issues.jboss.org/browse/WFLY-6179. Once
> keycloak updates to WF 10.1/11.x, this issue should be resolved.
>
> On Wed, Aug 9, 2017 at 1:32 PM, Edwin de Jong <edwin.de.jong(a)simacan.com
>
> wrote:
> > Dear Keycloak users (and devs),
> >
> > This morning, we faced a production level issue on our Keycloak
Cluster,
> > running in a 3-node formation on EC2. Symptoms were a high failure rate
> > of requests (> 20%) and high latency (> 10 seconds). We are currently
> > trying to figure out what went wrong. We would appreciate it if someone
> > with knowledge op JGroups / Inifinispan could chime in with a working
> > hypothesis.
> >
> > About priority: we are currently running nominally. We have brought
down
> > two of the instances and brought up two new instances. The cluster is
> > working again as expected.
> >
> > Below I'll give information about our setup, the relevant log-messages
> > and links to some screenshots of our monitoring:
> >
> > EC2 instances are C4.Large (3x)
> > Keycloak Version 3.1.0-FINAL
> >
> > Normal CPU usage is around 1% or less. It peaked to 16% during the
> incident.
> > Memory usage is normal.
> >
> > Screenshots:
> >
> > - datadog statistics of our services calling keycloak:
> https://ibb.co/dsDTKv
> > - AWS EC2 instance Cloudwatch statistics: network out rate (in bytes
per
> > MINUTE): https://ibb.co/j8jhCF
> > - AWS EC2 instance Cloudwatch statistics: network in rate (in bytes per
> > MINUTE): https://ibb.co/ggLuRa
> >
> > Log lines, just before failure (to help reduce clutter, I've removed
the
> > date and replaced the IP addresses with "IP-A", "IP-B",
"IP-C"). The
> > last message is repeated around 500.000 times in the span of around 1
> > minute.
> >
> > ---------------------->%-----------------------
> > 05:09:23,925 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-17,ee,ip-B) ISPN000094: Received new cluster view for channel
> > server: [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:23,926 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-17,ee,ip-B) ISPN000094: Received new cluster view for channel
> > keycloak: [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:23,926 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-17,ee,ip-B) ISPN000094: Received new cluster view for channel
> > web: [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:23,926 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-17,ee,ip-B) ISPN000094: Received new cluster view for channel
> > ejb: [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:23,928 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-17,ee,ip-B) ISPN000094: Received new cluster view for channel
> > hibernate: [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:23,990 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-1,ee,ip-A) ISPN000094: Received new cluster view for channel
> > server: [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:23,990 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-1,ee,ip-A) ISPN000094: Received new cluster view for channel
> > keycloak: [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:23,991 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-1,ee,ip-A) ISPN000094: Received new cluster view for channel
> > web: [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:23,992 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-1,ee,ip-A) ISPN000094: Received new cluster view for channel
> > hibernate: [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:23,992 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-1,ee,ip-A) ISPN000094: Received new cluster view for channel
> > ejb: [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:23,996 INFO [org.infinispan.CLUSTER]
(transport-thread--p14-t18)
> > ISPN000310: Starting cluster-wide rebalance for cache authorization,
> > topology CacheTopology{id=6, rebalanceId=3,
> > currentCH=DefaultConsistentHash{ns=80, owners = (2)[ip-A: 54+26, ip-B:
> > 26+54]}, pendingCH=DefaultConsistentHash{ns=80, owners = (2)[ip-A:
> > 40+40, ip-B: 40+40]}, unionCH=null, actualMembers=[ip-A, ip-B]}
> > 05:09:24,001 INFO [org.infinispan.CLUSTER]
(transport-thread--p14-t18)
> > ISPN000310: Starting cluster-wide rebalance for cache sessions,
topology
> > CacheTopology{id=6, rebalanceId=3,
> > currentCH=DefaultConsistentHash{ns=80, owners = (2)[ip-A: 54+26, ip-B:
> > 26+54]}, pendingCH=DefaultConsistentHash{ns=80, owners = (2)[ip-A:
> > 40+40, ip-B: 40+40]}, unionCH=null, actualMembers=[ip-A, ip-B]}
> > 05:09:24,004 INFO [org.infinispan.CLUSTER]
(transport-thread--p14-t18)
> > ISPN000310: Starting cluster-wide rebalance for cache offlineSessions,
> > topology CacheTopology{id=6, rebalanceId=3,
> > currentCH=DefaultConsistentHash{ns=80, owners = (2)[ip-A: 54+26, ip-B:
> > 26+54]}, pendingCH=DefaultConsistentHash{ns=80, owners = (2)[ip-A:
> > 40+40, ip-B: 40+40]}, unionCH=null, actualMembers=[ip-A, ip-B]}
> > 05:09:24,014 INFO [org.infinispan.CLUSTER]
(transport-thread--p14-t18)
> > ISPN000310: Starting cluster-wide rebalance for cache loginFailures,
> > topology CacheTopology{id=6, rebalanceId=3,
> > currentCH=DefaultConsistentHash{ns=80, owners = (2)[ip-A: 54+26, ip-B:
> > 26+54]}, pendingCH=DefaultConsistentHash{ns=80, owners = (2)[ip-A:
> > 40+40, ip-B: 40+40]}, unionCH=null, actualMembers=[ip-A, ip-B]}
> > 05:09:24,027 INFO [org.infinispan.CLUSTER] (remote-thread--p7-t130)
> > ISPN000336: Finished cluster-wide rebalance for cache sessions,
topology
> > id = 6
> > 05:09:24,028 INFO [org.infinispan.CLUSTER] (remote-thread--p7-t130)
> > ISPN000336: Finished cluster-wide rebalance for cache offlineSessions,
> > topology id = 6
> > 05:09:24,029 INFO [org.infinispan.CLUSTER] (remote-thread--p7-t131)
> > ISPN000336: Finished cluster-wide rebalance for cache loginFailures,
> > topology id = 6
> > 05:09:24,029 INFO [org.infinispan.CLUSTER] (remote-thread--p7-t132)
> > ISPN000336: Finished cluster-wide rebalance for cache authorization,
> > topology id = 6
> > 05:09:33,567 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-1,ee,ip-C) ISPN000093: Received new, MERGED cluster view for
> > channel server: MergeView::[ip-A|4] (3) [ip-A, ip-B, ip-C], 2
subgroups:
> > [ip-A|2] (3) [ip-A, ip-C, ip-B], [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:33,569 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-1,ee,ip-C) ISPN000093: Received new, MERGED cluster view for
> > channel keycloak: MergeView::[ip-A|4] (3) [ip-A, ip-B, ip-C], 2
> > subgroups: [ip-A|2] (3) [ip-A, ip-C, ip-B], [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:33,569 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-1,ee,ip-C) ISPN000093: Received new, MERGED cluster view for
> > channel web: MergeView::[ip-A|4] (3) [ip-A, ip-B, ip-C], 2 subgroups:
> > [ip-A|2] (3) [ip-A, ip-C, ip-B], [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:33,573 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-1,ee,ip-C) ISPN000093: Received new, MERGED cluster view for
> > channel ejb: MergeView::[ip-A|4] (3) [ip-A, ip-B, ip-C], 2 subgroups:
> > [ip-A|2] (3) [ip-A, ip-C, ip-B], [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:33,575 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-1,ee,ip-C) ISPN000093: Received new, MERGED cluster view for
> > channel hibernate: MergeView::[ip-A|4] (3) [ip-A, ip-B, ip-C], 2
> > subgroups: [ip-A|2] (3) [ip-A, ip-C, ip-B], [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:33,521 WARN [org.jgroups.protocols.pbcast.NAKACK]
> > (Incoming-19,ee,ip-B) JGRP000011: ip-B: dropped message 54375 from
> > non-member ip-C (view=[ip-A|3] (2) [ip-A, ip-B]) Warning
> > 05:09:33,527 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-20,ee,ip-B) ISPN000093: Received new, MERGED cluster view for
> > channel server: MergeView::[ip-A|4] (3) [ip-A, ip-B, ip-C], 2
subgroups:
> > [ip-A|2] (3) [ip-A, ip-C, ip-B], [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:33,529 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-20,ee,ip-B) ISPN000093: Received new, MERGED cluster view for
> > channel keycloak: MergeView::[ip-A|4] (3) [ip-A, ip-B, ip-C], 2
> > subgroups: [ip-A|2] (3) [ip-A, ip-C, ip-B], [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:33,529 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-20,ee,ip-B) ISPN000093: Received new, MERGED cluster view for
> > channel web: MergeView::[ip-A|4] (3) [ip-A, ip-B, ip-C], 2 subgroups:
> > [ip-A|2] (3) [ip-A, ip-C, ip-B], [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:33,530 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-20,ee,ip-B) ISPN000093: Received new, MERGED cluster view for
> > channel ejb: MergeView::[ip-A|4] (3) [ip-A, ip-B, ip-C], 2 subgroups:
> > [ip-A|2] (3) [ip-A, ip-C, ip-B], [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:33,533 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-20,ee,ip-B) ISPN000093: Received new, MERGED cluster view for
> > channel hibernate: MergeView::[ip-A|4] (3) [ip-A, ip-B, ip-C], 2
> > subgroups: [ip-A|2] (3) [ip-A, ip-C, ip-B], [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:33,518 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-7,ee,ip-A) ISPN000093: Received new, MERGED cluster view for
> > channel server: MergeView::[ip-A|4] (3) [ip-A, ip-B, ip-C], 2
subgroups:
> > [ip-A|2] (3) [ip-A, ip-C, ip-B], [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:33,525 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-7,ee,ip-A) ISPN000093: Received new, MERGED cluster view for
> > channel keycloak: MergeView::[ip-A|4] (3) [ip-A, ip-B, ip-C], 2
> > subgroups: [ip-A|2] (3) [ip-A, ip-C, ip-B], [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:33,525 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-7,ee,ip-A) ISPN000093: Received new, MERGED cluster view for
> > channel web: MergeView::[ip-A|4] (3) [ip-A, ip-B, ip-C], 2 subgroups:
> > [ip-A|2] (3) [ip-A, ip-C, ip-B], [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:33,527 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-7,ee,ip-A) ISPN000093: Received new, MERGED cluster view for
> > channel hibernate: MergeView::[ip-A|4] (3) [ip-A, ip-B, ip-C], 2
> > subgroups: [ip-A|2] (3) [ip-A, ip-C, ip-B], [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:33,527 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-7,ee,ip-A) ISPN000093: Received new, MERGED cluster view for
> > channel ejb: MergeView::[ip-A|4] (3) [ip-A, ip-B, ip-C], 2 subgroups:
> > [ip-A|2] (3) [ip-A, ip-C, ip-B], [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:33,577 INFO [org.infinispan.CLUSTER]
(transport-thread--p14-t12)
> > ISPN000310: Starting cluster-wide rebalance for cache authorization,
> > topology CacheTopology{id=10, rebalanceId=3,
> > currentCH=DefaultConsistentHash{ns=80, owners = (3)[ip-A: 27+53, ip-C:
> > 27+53, ip-B: 26+54]}, pendingCH=DefaultConsistentHash{ns=80, owners =
> > (3)[ip-A: 27+53, ip-B: 26+54, ip-C: 27+53]}, unionCH=null,
> > actualMembers=[ip-A, ip-B, ip-C]}
> > 05:09:33,579 INFO [org.infinispan.CLUSTER]
(transport-thread--p14-t12)
> > ISPN000310: Starting cluster-wide rebalance for cache offlineSessions,
> > topology CacheTopology{id=10, rebalanceId=3,
> > currentCH=DefaultConsistentHash{ns=80, owners = (3)[ip-A: 27+53, ip-C:
> > 27+53, ip-B: 26+54]}, pendingCH=DefaultConsistentHash{ns=80, owners =
> > (3)[ip-A: 27+53, ip-B: 26+54, ip-C: 27+53]}, unionCH=null,
> > actualMembers=[ip-A, ip-B, ip-C]}
> > 05:09:33,580 INFO [org.infinispan.CLUSTER]
(transport-thread--p14-t12)
> > ISPN000310: Starting cluster-wide rebalance for cache loginFailures,
> > topology CacheTopology{id=10, rebalanceId=3,
> > currentCH=DefaultConsistentHash{ns=80, owners = (3)[ip-A: 27+53, ip-C:
> > 27+53, ip-B: 26+54]}, pendingCH=DefaultConsistentHash{ns=80, owners =
> > (3)[ip-A: 27+53, ip-B: 26+54, ip-C: 27+53]}, unionCH=null,
> > actualMembers=[ip-A, ip-B, ip-C]}
> > 05:09:33,582 INFO [org.infinispan.CLUSTER]
(transport-thread--p14-t15)
> > ISPN000310: Starting cluster-wide rebalance for cache sessions,
topology
> > CacheTopology{id=10, rebalanceId=3,
> > currentCH=DefaultConsistentHash{ns=80, owners = (3)[ip-A: 27+53, ip-C:
> > 27+53, ip-B: 26+54]}, pendingCH=DefaultConsistentHash{ns=80, owners =
> > (3)[ip-A: 27+53, ip-B: 26+54, ip-C: 27+53]}, unionCH=null,
> > actualMembers=[ip-A, ip-B, ip-C]}
> > 05:09:33,589 INFO [org.infinispan.CLUSTER] (remote-thread--p7-t130)
> > ISPN000336: Finished cluster-wide rebalance for cache loginFailures,
> > topology id = 10
> > 05:09:33,589 INFO [org.infinispan.CLUSTER] (remote-thread--p7-t130)
> > ISPN000336: Finished cluster-wide rebalance for cache authorization,
> > topology id = 10
> > 05:09:33,590 INFO [org.infinispan.CLUSTER] (remote-thread--p7-t131)
> > ISPN000336: Finished cluster-wide rebalance for cache offlineSessions,
> > topology id = 10
> > 05:09:33,601 INFO [org.infinispan.CLUSTER] (remote-thread--p7-t133)
> > ISPN000336: Finished cluster-wide rebalance for cache sessions,
topology
> > id = 10
> > 05:09:34,001 ERROR [org.jgroups.protocols.TCP] (Connection.Receiver
> > [IP-A:35361 - IP-C:7600],ee,ip-A) ip-A: failed submitting DONT_BUNDLE
> > message to thread pool: java.util.concurrent.
RejectedExecutionException:
> > Task org.jgroups.protocols.TP$SingleMessageHandler@17c86a0c rejected
> > from java.util.concurrent.ThreadPoolExecutor@52cae691[Running, pool
size
> > = 4, active threads = 4, queued tasks = 100, completed tasks =
1589693].
> > Msg: RequestCorrelator: id=200, type=REQ, id=607, rsp_expected=true,
> > FORK: ee:keycloak, NAKACK: [XMIT_RSP, seqno=206], TCP:
[cluster_name=ee]
> > ERROR
> > 05:09:34,010 ERROR [org.jgroups.protocols.TCP] (Connection.Receiver
> > [IP-A:35361 - IP-C:7600],ee,ip-A) ip-A: failed submitting DONT_BUNDLE
> > message to thread pool: java.util.concurrent.
RejectedExecutionException:
> > Task org.jgroups.protocols.TP$SingleMessageHandler@4fec3655 rejected
> > from java.util.concurrent.ThreadPoolExecutor@52cae691[Running, pool
size
> > = 4, active threads = 4, queued tasks = 100, completed tasks =
1589694].
> > Msg: RequestCorrelator: id=200, type=REQ, id=609, rsp_expected=true,
> > FORK: ee:keycloak, NAKACK: [XMIT_RSP, seqno=208], TCP:
[cluster_name=ee]
> > ERROR
> >
> > (last line repeated many, many times)
> > ---------------------->%-----------------------
> >
> >
> >
> > Infinispan subsystem configuration in standalone-ha.xml:
> >
> > ---------------------->%-----------------------
> > <subsystem xmlns="urn:jboss:domain:infinispan:4.0">
> > <cache-container name="keycloak"
jndi-name="infinispan/
Keycloak">
> > <transport lock-timeout="60000"/>
> > <local-cache name="realms">
> > <eviction max-entries="10000"
strategy="LRU"/>
> > </local-cache>
> > <local-cache name="users">
> > <eviction max-entries="10000"
strategy="LRU"/>
> > </local-cache>
> > <distributed-cache name="sessions" mode="SYNC"
owners="3"/>
> > <distributed-cache name="offlineSessions"
mode="SYNC"
> owners="3"/>
> > <distributed-cache name="loginFailures"
mode="SYNC"
owners="3"/>
> > <distributed-cache name="authorization"
mode="SYNC"
owners="3"/>
> > <replicated-cache name="work" mode="SYNC"/>
> > <local-cache name="keys">
> > <eviction max-entries="1000"
strategy="LRU"/>
> > <expiration max-idle="3600000"/>
> > </local-cache>
> > </cache-container>
> > <cache-container name="server" aliases="singleton
cluster"
> > default-cache="default"
module="org.wildfly.clustering.server">
> > <transport lock-timeout="60000"/>
> > <replicated-cache name="default"
mode="SYNC">
> > <transaction mode="BATCH"/>
> > </replicated-cache>
> > </cache-container>
> > <cache-container name="web" default-cache="dist"
> > module="org.wildfly.clustering.web.infinispan">
> > <transport lock-timeout="60000"/>
> > <distributed-cache name="dist" mode="ASYNC"
l1-lifespan="0"
> > owners="2">
> > <locking isolation="REPEATABLE_READ"/>
> > <transaction mode="BATCH"/>
> > <file-store/>
> > </distributed-cache>
> > </cache-container>
> > <cache-container name="ejb" aliases="sfsb"
default-cache="dist"
> > module="org.wildfly.clustering.ejb.infinispan">
> > <transport lock-timeout="60000"/>
> > <distributed-cache name="dist" mode="ASYNC"
l1-lifespan="0"
> > owners="2">
> > <locking isolation="REPEATABLE_READ"/>
> > <transaction mode="BATCH"/>
> > <file-store/>
> > </distributed-cache>
> > </cache-container>
> > <cache-container name="hibernate"
default-cache="local-query"
> > module="org.hibernate.infinispan">
> > <transport lock-timeout="60000"/>
> > <local-cache name="local-query">
> > <eviction strategy="LRU"
max-entries="10000"/>
> > <expiration max-idle="100000"/>
> > </local-cache>
> > <invalidation-cache name="entity"
mode="SYNC">
> > <transaction mode="NON_XA"/>
> > <eviction strategy="LRU"
max-entries="10000"/>
> > <expiration max-idle="100000"/>
> > </invalidation-cache>
> > <replicated-cache name="timestamps"
mode="ASYNC"/>
> > </cache-container>
> > </subsystem>
> > ---------------------->%-----------------------
> >
> > JGroups subsystem configuration:
> >
> > ---------------------->%-----------------------
> > <subsystem xmlns="urn:jboss:domain:jgroups:4.0"
default-stack="tcp">
> > <channels default="ee">
> > <channel name="ee" stack="tcp"/>
> > </channels>
> > <stacks>
> > <stack name="tcp">
> > <transport type="TCP"
socket-binding="jgroups-tcp"/>
> > <protocol type="S3_PING">
> > <property
name="access_key">S3AccessKey</property>
> > <property name="secret_access_key">
> S3SecretAccessKey</property>
> > <property
name="location">S3PingBucketName</property>
> > </protocol>
> > <protocol type="MERGE2"/>
> > <protocol type="FD_SOCK"
socket-binding="jgroups-tcp-fd"/>
> > <protocol type="FD"/>
> > <protocol type="VERIFY_SUSPECT"/>
> > <protocol type="pbcast.NAKACK"/>
> > <protocol type="UNICAST2"/>
> > <protocol type="pbcast.STABLE"/>
> > <protocol type="pbcast.GMS"/>
> > <protocol type="UFC"/>
> > <protocol type="MFC"/>
> > <protocol type="FRAG2"/>
> > <protocol type="RSVP"/>
> > </stack>
> > <stack name="udp">
> > <transport type="UDP"
socket-binding="jgroups-udp"/>
> > <protocol type="PING"/>
> > <protocol type="MERGE3"/>
> > <protocol type="FD_SOCK"
socket-binding="jgroups-udp-fd"/>
> > <protocol type="FD_ALL"/>
> > <protocol type="VERIFY_SUSPECT"/>
> > <protocol type="pbcast.NAKACK2"/>
> > <protocol type="UNICAST3"/>
> > <protocol type="pbcast.STABLE"/>
> > <protocol type="pbcast.GMS"/>
> > <protocol type="UFC"/>
> > <protocol type="MFC"/>
> > <protocol type="FRAG2"/>
> > </stack>
> > </stacks>
> > </subsystem>
> > ---------------------->%-----------------------
> >
> > with kind regards,
> >
> > Edwin de Jong
> >
> > -- Simacan B.V. Data Engineer
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
> --
>
> --Hynek
>
>
> ------------------------------
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
> End of keycloak-user Digest, Vol 44, Issue 23
> *********************************************
>
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
12:46 a.m.
New subject: token introspection
On 8/10/17 9:45 AM, Doug Drouillard wrote:
You don't necessarily 'need' it, but it makes the project
an order of
magnitude more complicated to understand. The adapters are magic, but if
we aren't already familiar with something like Spring, then we really have
no way to fully understand what is going on. The other adapters such as
undertow as equally as intense. We don't need to understand all
infrastructure of course, but given there is an integration into an
existing workflow it makes it hard to use.
You don't need token introspection
if you are following the OAuth2
protocol correctly. Token introspection is redundant in this case. It
is only potentially useful for validating bearer token requests
depending on the access token implementation.
I would contribute a simple / clean Java example but I am still not
sure
what that would even mean. Most threads I see around inspection say just
use XXX and don't worry. But I have found that to be dubious.
The aerogear team used using a Auth0 JWT inspection library which seems
like it is working.
The project is very well documented and there are tons of examples, but I
see every 2 weeks or so someone asks about token introspection as they are
trying to learn the best way to use Keycloak and basically get 3 responses
in until they get a 'dont worry about it' response, which really doesn't
help as it is rare to solve a more complicated problem without
understanding the basic problem.
Keycloak access tokens are digitally signed by the
realm. This is
spelled out in our documentation. For bearer token requests, our
adapters validate this signature against the public key of the realm.
Keycloak token introspection is only useful for determining if the
access token has been revoked within the allowable timeout of the
token. Our adapters don't support token introspection. We do not
recommend token introspection for bearer token requests because then the
Keycloak auth server would basically have to scale one-to-one with all
the bearer token requests of every single service on your network.
We get the fear of missing using token inspection, but it sucks as a
user
not to be able to get a clear example of 'Here is how you used to do it
with manually token inspection, now compare to the adapters' as opposed to
'read this intense doc and just simply integrate this adapter which you
don't understand' which has been what I have personally seen in digging
through 3 years of emails. Or the even better - "just google for industry
best practices on token inspection and use the existing libraries". For you
on the team it probably seems like such a trivial use case not even worth
mentioning but if you are new to Oauth/Keycloak/JWT and adapters, a simple
use case even if it was absolutely evil and going to cause WW3 would be
useful. Even as a blog post.
The use case is, I use keycloak to do a social sign-in, I get the token
back, using only self-contained Java (so calling libraries but not using
any json configs or adapters), how would I inspect the token to pull out
the email address and verify that token is still valid and actually came
from my keycloak server instead of being spoofed?
I think your complaints are
misguided. Either you trust the adapter's
"magic" or you learn and completely understand the protocols yourself.
In your particular example, you know that the email address, etc. that
you pull out is not being spoofed because you are doing the OAuth2 auth
code flow using HTTPS and your client HTTP library should be validating
the cert when setting up an SSL connection to make the code to token
exchange. This is completely spelled out in the OAuth2 and OpenID
Connect specifications.
I know this is what adapters/json configs do for you (at least in theory, I
never got adapters to work), and there are existing libraries, but an all
in one laid out example direct from keycloak team would be awesome!
Sounds like you
are implying that our adapters don't work? Must be user
error on your part. If you want to criticize our docs and say they
suck, that's perfectly fine. But to imply our adapters don't work is
just plain wrong. Granted it can be difficult to debug setup issues at
times, but our adapters don't work "in theory" ...The project is 4+
years old now and to imply that something as fundamental as our adapters
don't work is well tiny bit insulting :)
As far as a "laid out example": example on what? There are a ton of
examples for setting up adapters. Keyclaok admin console can even
generate a config file for you. If you want a "laid out example" of
manually coding the OpenID connect or SAML protocols in Java...well,
there you are on your own. We are OpenID Connect certified so, if you
learn the protocol you should be able to manually code anything you
want. IMO, OAuth2 and OpenID connect specifications are easy enough to
understand.
What is missing I think is documentation on how to validate bearer
tokens if you are not using our adapters or security proxy.
KEYCLOAK-5287 was just created and scheduled by me to track this.
Bill
4:58 a.m.
New subject: token introspection
I'm not sure about any example, but there are some references in our docs
[1] [2]. They are not "clone & run" examples, but may be helpful to
understand how to achieve token introspection.
[1]
https://keycloak.gitbooks.io/documentation/securing_apps/topics/oidc/oidc...
[2]
https://keycloak.gitbooks.io/documentation/authorization_services/topics/...
On Thu, Aug 10, 2017 at 10:45 AM, Doug Drouillard <
douglas.drouillard(a)gmail.com> wrote:
You don't necessarily 'need' it, but it makes the project
an order of
magnitude more complicated to understand. The adapters are magic, but if
we aren't already familiar with something like Spring, then we really have
no way to fully understand what is going on. The other adapters such as
undertow as equally as intense. We don't need to understand all
infrastructure of course, but given there is an integration into an
existing workflow it makes it hard to use.
I would contribute a simple / clean Java example but I am still not sure
what that would even mean. Most threads I see around inspection say just
use XXX and don't worry. But I have found that to be dubious.
The aerogear team used using a Auth0 JWT inspection library which seems
like it is working.
The project is very well documented and there are tons of examples, but I
see every 2 weeks or so someone asks about token introspection as they are
trying to learn the best way to use Keycloak and basically get 3 responses
in until they get a 'dont worry about it' response, which really doesn't
help as it is rare to solve a more complicated problem without
understanding the basic problem.
We get the fear of missing using token inspection, but it sucks as a user
not to be able to get a clear example of 'Here is how you used to do it
with manually token inspection, now compare to the adapters' as opposed to
'read this intense doc and just simply integrate this adapter which you
don't understand' which has been what I have personally seen in digging
through 3 years of emails. Or the even better - "just google for industry
best practices on token inspection and use the existing libraries". For you
on the team it probably seems like such a trivial use case not even worth
mentioning but if you are new to Oauth/Keycloak/JWT and adapters, a simple
use case even if it was absolutely evil and going to cause WW3 would be
useful. Even as a blog post.
The use case is, I use keycloak to do a social sign-in, I get the token
back, using only self-contained Java (so calling libraries but not using
any json configs or adapters), how would I inspect the token to pull out
the email address and verify that token is still valid and actually came
from my keycloak server instead of being spoofed?
I know this is what adapters/json configs do for you (at least in theory, I
never got adapters to work), and there are existing libraries, but an all
in one laid out example direct from keycloak team would be awesome!
On Thu, Aug 10, 2017 at 8:58 AM, <keycloak-user-request(a)lists.jboss.org>
wrote:
> Send keycloak-user mailing list submissions to
> keycloak-user(a)lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/keycloak-user
> or, via email, send a message with subject or body 'help' to
> keycloak-user-request(a)lists.jboss.org
>
> You can reach the person managing the list at
> keycloak-user-owner(a)lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of keycloak-user digest..."
>
>
> Today's Topics:
>
> 1. Re: DB deadlock for concurrent logins (Vikrant Singh)
> 2. Re: token introspection (Pedro Igor Silva)
> 3. Re: JGroups failure: failed submitting DONT_BUNDLE message to
> thread pool (Hynek Mlnarik)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 10 Aug 2017 17:06:33 +0530
> From: Vikrant Singh <vikrant02.work(a)gmail.com>
> Subject: Re: [keycloak-user] DB deadlock for concurrent logins
> To: "keycloak-us." <keycloak-user(a)lists.jboss.org>
> Message-ID:
> <CACackctxEZcXL37cAMuS7ajhmdHyr_SHNGBT=qaz6Nw0W428oQ@mail.
> gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Yes, but password migration should only be happening during first login.
I
> have checked the CREDENTIAL table in DB and user have already migrated to
> new hashing algorithm and no of iterations, but still keycloak is trying
to
> run Update query for each login attempt.
>
> -Vikrant
>
> On Thu, Aug 10, 2017 at 4:18 PM, <keycloak-user-request(a)lists.jboss.org>
> wrote:
> >
> >
> > I believe that the default hashing algorithm has changed to SHA-256 as
> > SHA-1 was recently in the news for being able to create hash
> > collisions. Because of this change, each login will update the
password
> > hash stored with the 1st login of the user.
> >
> > Not sure why MariaDB would deadlock. Don't know enough about how that
> > database performs locks. It is trying to update a foreign key that has
> > an index associated with it. Maybe that has something to do with it.
> >
> >
> >
> > On 8/9/17 5:35 PM, Vikrant Singh wrote:
> > > Hi,
> > >
> > > I am Running Keycloak 3.2.1.Final on openshift platform with MariaDB
> > 10.2.7
> > > for DB, recently upgraded from 3.1.0.Final.
> > >
> > > Deployment is consist of 3 keycloak servers along with 3 DB
instances.
> As
> > > part of kubernetes rediness check, a token is requested for a local
> user
> > in
> > > master realm every 10 sec. The concurrent token request for same user
> is
> > > causing the deadlock exception in DB. Following is the exception
being
> > > logged in keycloak.
> > >
> > >
> > > Caused by: java.sql.SQLException: Deadlock found when trying to get
> > > lock; try restarting transaction
> > >
> > > Query is: select userentity0_.ID as ID1_71_,
> > > userentity0_.CREATED_TIMESTAMP as CREATED_2_71_, userentity0_.EMAIL
as
> > > EMAIL3_71_, userentity0_.EMAIL_CONSTRAINT as EMAIL_CO4_71_,
> > > userentity0_.EMAIL_VERIFIED as EMAIL_VE5_71_, userentity0_.ENABLED as
> > > ENABLED6_71_, userentity0_.FEDERATION_LINK as FEDERATI7_71_,
> > > userentity0_.FIRST_NAME as FIRST_NA8_71_, userentity0_.LAST_NAME as
> > > LAST_NAM9_71_, userentity0_.REALM_ID as REALM_I10_71_,
> > > userentity0_.SERVICE_ACCOUNT_CLIENT_LINK as SERVICE11_71_,
> > > userentity0_.USERNAME as USERNAM12_71_ from USER_ENTITY userentity0_
> > > where userentity0_.ID=? and userentity0_.REALM_ID=?, parameters
> > > ['ddafa525-baae-4c40-98f8-08c25a23f2c6','master']
> > >
> > > at org.mariadb.jdbc.internal.util.LogQueryTool.
> exceptionWithQuery(
> > LogQueryTool.java:146)
> > >
> > > at org.mariadb.jdbc.internal.protocol.AbstractQueryProtocol.
> > executeQuery(AbstractQueryProtocol.java:221)
> > >
> > > at org.mariadb.jdbc.MariaDbPreparedStatementClient
> > .executeInternal(MariaDbPreparedStatementClient.java:218)
> > >
> > > ... 76 more
> > >
> > >
> > > Caused by: java.sql.SQLException: Lock wait timeout exceeded; try
> > > restarting transaction
> > >
> > > Query is: update CREDENTIAL set ALGORITHM=?, COUNTER=?,
> > > CREATED_DATE=?, DEVICE=?, DIGITS=?, HASH_ITERATIONS=?, PERIOD=?,
> > > SALT=?, TYPE=?, USER_ID=?, VALUE=? where ID=?, parameters
> > >
['pbkdf2-sha256',0,1501750736628,<null>,0,27500,0,<bytearray:???7'3^
> > >
.??LT???>,'password','ddafa525-baae-4c40-98f8-08c25a23f2c6','
> > Hdpx8Zg5Ec8M9qVUp+Ylwlje+nhcGAzVPStF6/cvrqZghTeby048b8d3uqExfzS0of/
> > 9Quwx9CROGKTC685Tpw==','5929a82b-542c-4597-b3eb-524d74e58919']
> > >
> > > at org.mariadb.jdbc.internal.util.LogQueryTool.
> exceptionWithQuery(
> > LogQueryTool.java:146)
> > >
> > > at org.mariadb.jdbc.internal.protocol.AbstractQueryProtocol.
> > executeQuery(AbstractQueryProtocol.java:221)
> > >
> > > at org.mariadb.jdbc.MariaDbPreparedStatementClient
> > .executeInternal(MariaDbPreparedStatementClient.java:218)
> > >
> > > ... 78 more
> > >
> > >
> > > Why keycloak is trying to update the user credential for every login.
> > > and why is deadlock occurring? Any help truly appreciated.
> > >
> > >
> > > Thanks,
> > >
> > > Vikrant
> > > _______________________________________________
> > > keycloak-user mailing list
> > > keycloak-user(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-user
> >
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 10 Aug 2017 08:53:23 -0300
> From: Pedro Igor Silva <psilva(a)redhat.com>
> Subject: Re: [keycloak-user] token introspection
> To: Simon Payne <simonpayne58(a)gmail.com>
> Cc: keycloak-user <keycloak-user(a)lists.jboss.org>
> Message-ID:
> <CAJrcDBfFW3M4yauqgn=eG8Wnp=MnPkpQ4OFjeyoUZPLowm=1EQ@mail.
> gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> No, we don't. Like Bill said, you don't really need it. Basically, what
we
> support is described in docs [1].
>
> [1]
> http://www.keycloak.org/docs/3.1/authorization_services/
> topics/enforcer/keycloak-enforcement-filter.html
>
>
> On Thu, Aug 10, 2017 at 6:11 AM, Simon Payne <simonpayne58(a)gmail.com>
> wrote:
>
> > do we have token introspection implemented in any of the client
adapters
> > (other than spring boot)?
> >
> > thanks
> >
> >
> > On Wed, Aug 9, 2017 at 9:50 AM, Simon Payne <simonpayne58(a)gmail.com>
> > wrote:
> >
> > > thanks Pedro,
> > >
> > > however, i think our use cases are not exactly the same. it appears
> your
> > > component is set to allow authentication of user where mine is bearer
> > only.
> > >
> > > the only other differences i can see between our projects is that i
am
> > > running gradle with keycloak 3.2.0 and that i have also added
compile(
> > > 'org.keycloak:keycloak-authz-client:3.2.0.CR1')
> > >
> > > Lucian, i don't have a project which i can share at the moment as
other
> > > code is included, if you would still like to see something i can
make a
> > > shareable version.
> > >
> > > Thanks
> > >
> > >
> > > On Tue, Aug 8, 2017 at 8:57 PM, Pedro Igor Silva
<psilva(a)redhat.com>
> > > wrote:
> > >
> > >> Hey Lucian, we have this https://github.com/keycloak/ke
> > >> ycloak-quickstarts/tree/latest/app-authz-springboot.
> > >>
> > >> On Tue, Aug 8, 2017 at 1:17 PM, Lucian Ochian
<okianl(a)yahoo.com>
> wrote:
> > >>
> > >>> Simon,
> > >>> Do you have a demo app with that? I am just curious to see a
> > >>> spring(boot) app with authorizations...I remember that I tried
> > something
> > >>> with authorizations, and the authorization context was null(I
know
> > there
> > >>> are some Jira issues about it), but I still could not get it to
work
> in
> > >>> 2.5.5
> > >>> AuthorizationContext authzContext =
> > >>> keycloakSecurityContext.getAuthorizationContext();
> > >>> Thanks,Lucian
> > >>>
> > >>> On Tuesday, August 8, 2017, 10:25:35 AM CDT, Simon Payne <
> > >>> simonpayne58(a)gmail.com> wrote:
> > >>>
> > >>> yes correct.
> > >>>
> > >>> there is a definite change in behavior with the addition of the
> > >>> keycloak.policy-enforcer-config.online-introspection=true flag,
as
> > >>> without
> > >>> this single line in my property file it works correctly as a
bearer
> > only
> > >>> resource server. Addition of this line results in the incorrect
call
> > to
> > >>> token exchange endpoint.
> > >>>
> > >>> thanks
> > >>>
> > >>>
> > >>> On Tue, Aug 8, 2017 at 3:28 PM, Bill Burke
<bburke(a)redhat.com>
> wrote:
> > >>>
> > >>> > Doesn't look like the switch is hooked up to anything.
As it is,
> it
> > >>> > looks like this switch was added for RPT validation, not
access
> token
> > >>> > validation, and not ever implemented. You just want the
adapter
to
> > >>> > validate the access token with the auth server for bearer
token
> > >>> > requests, right?
> > >>> >
> > >>> >
> > >>> > On 8/8/17 9:29 AM, Bill Burke wrote:
> > >>> > > I'm looking at the code on server and I dont'
see that it
> requires
> > >>> any
> > >>> > > special switch to use it. The endpoint is:
> > >>> > >
> > >>> > > @Post
> > >>> > >
> > >>> > >
/auth/realms/{realm}/protocol/openid-connect/token/introspect
> > >>> > >
> > >>> > > Takes form params.
> > >>> > >
> > >>> > > token
> > >>> > >
> > >>> > > token_type_hint (optional and defaults to
"access_token")
> > >>> > >
> > >>> > >
> > >>> > >
> > >>> > >
> > >>> > >
> > >>> > > On 8/8/17 4:31 AM, Simon Payne wrote:
> > >>> > >> after some debugging i figured that
> > >>> > >>
keycloak.policy-enforcer-config.online-introspection=true
> > switched
> > >>> on
> > >>> > this
> > >>> > >> functionality, however it appears to error on a 400
after
> making a
> > >>> call
> > >>> > to
> > >>> > >> the
/auth/realms/master/protocol/openid-connect/token
endpoint.
> > >>> > >>
> > >>> > >> I'm assuming this is a bug?
> > >>> > >>
> > >>> > >> Thanks
> > >>> > >>
> > >>> > >>
> > >>> > >>
> > >>> > >> On Mon, Aug 7, 2017 at 3:10 PM, Simon Payne <
> > simonpayne58(a)gmail.com
> > >>> >
> > >>> > wrote:
> > >>> > >>
> > >>> > >>> Hi All,
> > >>> > >>>
> > >>> > >>> I'm evaluating keycloak and i'm
currently looking at token
> > >>> > introspection.
> > >>> > >>>
> > >>> > >>> I've managed to achieve this manually, i.e.
by sending a post
> via
> > >>> > postman,
> > >>> > >>> but i'm unable to figure out whether this
can be achieved via
> the
> > >>> > keycloak
> > >>> > >>> adapters, specifically spring boot.
> > >>> > >>>
> > >>> > >>> any help in this area would be appreciated.
> > >>> > >>>
> > >>> > >>> thanks
> > >>> > >>>
> > >>> > >>> Simon.
> > >>> > >>>
> > >>> > >> _______________________________________________
> > >>> > >> keycloak-user mailing list
> > >>> > >> keycloak-user(a)lists.jboss.org
> > >>> > >>
https://lists.jboss.org/mailman/listinfo/keycloak-user
> > >>> > > _______________________________________________
> > >>> > > keycloak-user mailing list
> > >>> > > keycloak-user(a)lists.jboss.org
> > >>> > > https://lists.jboss.org/mailman/listinfo/keycloak-user
> > >>> >
> > >>> > _______________________________________________
> > >>> > keycloak-user mailing list
> > >>> > keycloak-user(a)lists.jboss.org
> > >>> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> > >>> >
> > >>> _______________________________________________
> > >>> keycloak-user mailing list
> > >>> keycloak-user(a)lists.jboss.org
> > >>> https://lists.jboss.org/mailman/listinfo/keycloak-user
> > >>> _______________________________________________
> > >>> keycloak-user mailing list
> > >>> keycloak-user(a)lists.jboss.org
> > >>> https://lists.jboss.org/mailman/listinfo/keycloak-user
> > >>>
> > >>
> > >>
> > >
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> >
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 10 Aug 2017 14:32:50 +0200
> From: Hynek Mlnarik <hmlnarik(a)redhat.com>
> Subject: Re: [keycloak-user] JGroups failure: failed submitting
> DONT_BUNDLE message to thread pool
> To: Edwin de Jong <edwin.de.jong(a)simacan.com>
> Cc: keycloak-user <keycloak-user(a)lists.jboss.org>
> Message-ID:
> <CAMvXD=HpizBoVGpVALHnmkwJHLFzh3U6tNwVbkTwi+Lwa-XTsw@mail.
> gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> You seem to be facing https://issues.jboss.org/browse/WFLY-6179. Once
> keycloak updates to WF 10.1/11.x, this issue should be resolved.
>
> On Wed, Aug 9, 2017 at 1:32 PM, Edwin de Jong <edwin.de.jong(a)simacan.com
>
> wrote:
> > Dear Keycloak users (and devs),
> >
> > This morning, we faced a production level issue on our Keycloak
Cluster,
> > running in a 3-node formation on EC2. Symptoms were a high failure rate
> > of requests (> 20%) and high latency (> 10 seconds). We are currently
> > trying to figure out what went wrong. We would appreciate it if someone
> > with knowledge op JGroups / Inifinispan could chime in with a working
> > hypothesis.
> >
> > About priority: we are currently running nominally. We have brought
down
> > two of the instances and brought up two new instances. The cluster is
> > working again as expected.
> >
> > Below I'll give information about our setup, the relevant log-messages
> > and links to some screenshots of our monitoring:
> >
> > EC2 instances are C4.Large (3x)
> > Keycloak Version 3.1.0-FINAL
> >
> > Normal CPU usage is around 1% or less. It peaked to 16% during the
> incident.
> > Memory usage is normal.
> >
> > Screenshots:
> >
> > - datadog statistics of our services calling keycloak:
> https://ibb.co/dsDTKv
> > - AWS EC2 instance Cloudwatch statistics: network out rate (in bytes
per
> > MINUTE): https://ibb.co/j8jhCF
> > - AWS EC2 instance Cloudwatch statistics: network in rate (in bytes per
> > MINUTE): https://ibb.co/ggLuRa
> >
> > Log lines, just before failure (to help reduce clutter, I've removed
the
> > date and replaced the IP addresses with "IP-A", "IP-B",
"IP-C"). The
> > last message is repeated around 500.000 times in the span of around 1
> > minute.
> >
> > ---------------------->%-----------------------
> > 05:09:23,925 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-17,ee,ip-B) ISPN000094: Received new cluster view for channel
> > server: [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:23,926 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-17,ee,ip-B) ISPN000094: Received new cluster view for channel
> > keycloak: [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:23,926 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-17,ee,ip-B) ISPN000094: Received new cluster view for channel
> > web: [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:23,926 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-17,ee,ip-B) ISPN000094: Received new cluster view for channel
> > ejb: [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:23,928 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-17,ee,ip-B) ISPN000094: Received new cluster view for channel
> > hibernate: [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:23,990 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-1,ee,ip-A) ISPN000094: Received new cluster view for channel
> > server: [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:23,990 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-1,ee,ip-A) ISPN000094: Received new cluster view for channel
> > keycloak: [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:23,991 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-1,ee,ip-A) ISPN000094: Received new cluster view for channel
> > web: [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:23,992 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-1,ee,ip-A) ISPN000094: Received new cluster view for channel
> > hibernate: [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:23,992 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-1,ee,ip-A) ISPN000094: Received new cluster view for channel
> > ejb: [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:23,996 INFO [org.infinispan.CLUSTER]
(transport-thread--p14-t18)
> > ISPN000310: Starting cluster-wide rebalance for cache authorization,
> > topology CacheTopology{id=6, rebalanceId=3,
> > currentCH=DefaultConsistentHash{ns=80, owners = (2)[ip-A: 54+26, ip-B:
> > 26+54]}, pendingCH=DefaultConsistentHash{ns=80, owners = (2)[ip-A:
> > 40+40, ip-B: 40+40]}, unionCH=null, actualMembers=[ip-A, ip-B]}
> > 05:09:24,001 INFO [org.infinispan.CLUSTER]
(transport-thread--p14-t18)
> > ISPN000310: Starting cluster-wide rebalance for cache sessions,
topology
> > CacheTopology{id=6, rebalanceId=3,
> > currentCH=DefaultConsistentHash{ns=80, owners = (2)[ip-A: 54+26, ip-B:
> > 26+54]}, pendingCH=DefaultConsistentHash{ns=80, owners = (2)[ip-A:
> > 40+40, ip-B: 40+40]}, unionCH=null, actualMembers=[ip-A, ip-B]}
> > 05:09:24,004 INFO [org.infinispan.CLUSTER]
(transport-thread--p14-t18)
> > ISPN000310: Starting cluster-wide rebalance for cache offlineSessions,
> > topology CacheTopology{id=6, rebalanceId=3,
> > currentCH=DefaultConsistentHash{ns=80, owners = (2)[ip-A: 54+26, ip-B:
> > 26+54]}, pendingCH=DefaultConsistentHash{ns=80, owners = (2)[ip-A:
> > 40+40, ip-B: 40+40]}, unionCH=null, actualMembers=[ip-A, ip-B]}
> > 05:09:24,014 INFO [org.infinispan.CLUSTER]
(transport-thread--p14-t18)
> > ISPN000310: Starting cluster-wide rebalance for cache loginFailures,
> > topology CacheTopology{id=6, rebalanceId=3,
> > currentCH=DefaultConsistentHash{ns=80, owners = (2)[ip-A: 54+26, ip-B:
> > 26+54]}, pendingCH=DefaultConsistentHash{ns=80, owners = (2)[ip-A:
> > 40+40, ip-B: 40+40]}, unionCH=null, actualMembers=[ip-A, ip-B]}
> > 05:09:24,027 INFO [org.infinispan.CLUSTER] (remote-thread--p7-t130)
> > ISPN000336: Finished cluster-wide rebalance for cache sessions,
topology
> > id = 6
> > 05:09:24,028 INFO [org.infinispan.CLUSTER] (remote-thread--p7-t130)
> > ISPN000336: Finished cluster-wide rebalance for cache offlineSessions,
> > topology id = 6
> > 05:09:24,029 INFO [org.infinispan.CLUSTER] (remote-thread--p7-t131)
> > ISPN000336: Finished cluster-wide rebalance for cache loginFailures,
> > topology id = 6
> > 05:09:24,029 INFO [org.infinispan.CLUSTER] (remote-thread--p7-t132)
> > ISPN000336: Finished cluster-wide rebalance for cache authorization,
> > topology id = 6
> > 05:09:33,567 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-1,ee,ip-C) ISPN000093: Received new, MERGED cluster view for
> > channel server: MergeView::[ip-A|4] (3) [ip-A, ip-B, ip-C], 2
subgroups:
> > [ip-A|2] (3) [ip-A, ip-C, ip-B], [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:33,569 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-1,ee,ip-C) ISPN000093: Received new, MERGED cluster view for
> > channel keycloak: MergeView::[ip-A|4] (3) [ip-A, ip-B, ip-C], 2
> > subgroups: [ip-A|2] (3) [ip-A, ip-C, ip-B], [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:33,569 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-1,ee,ip-C) ISPN000093: Received new, MERGED cluster view for
> > channel web: MergeView::[ip-A|4] (3) [ip-A, ip-B, ip-C], 2 subgroups:
> > [ip-A|2] (3) [ip-A, ip-C, ip-B], [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:33,573 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-1,ee,ip-C) ISPN000093: Received new, MERGED cluster view for
> > channel ejb: MergeView::[ip-A|4] (3) [ip-A, ip-B, ip-C], 2 subgroups:
> > [ip-A|2] (3) [ip-A, ip-C, ip-B], [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:33,575 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-1,ee,ip-C) ISPN000093: Received new, MERGED cluster view for
> > channel hibernate: MergeView::[ip-A|4] (3) [ip-A, ip-B, ip-C], 2
> > subgroups: [ip-A|2] (3) [ip-A, ip-C, ip-B], [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:33,521 WARN [org.jgroups.protocols.pbcast.NAKACK]
> > (Incoming-19,ee,ip-B) JGRP000011: ip-B: dropped message 54375 from
> > non-member ip-C (view=[ip-A|3] (2) [ip-A, ip-B]) Warning
> > 05:09:33,527 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-20,ee,ip-B) ISPN000093: Received new, MERGED cluster view for
> > channel server: MergeView::[ip-A|4] (3) [ip-A, ip-B, ip-C], 2
subgroups:
> > [ip-A|2] (3) [ip-A, ip-C, ip-B], [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:33,529 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-20,ee,ip-B) ISPN000093: Received new, MERGED cluster view for
> > channel keycloak: MergeView::[ip-A|4] (3) [ip-A, ip-B, ip-C], 2
> > subgroups: [ip-A|2] (3) [ip-A, ip-C, ip-B], [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:33,529 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-20,ee,ip-B) ISPN000093: Received new, MERGED cluster view for
> > channel web: MergeView::[ip-A|4] (3) [ip-A, ip-B, ip-C], 2 subgroups:
> > [ip-A|2] (3) [ip-A, ip-C, ip-B], [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:33,530 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-20,ee,ip-B) ISPN000093: Received new, MERGED cluster view for
> > channel ejb: MergeView::[ip-A|4] (3) [ip-A, ip-B, ip-C], 2 subgroups:
> > [ip-A|2] (3) [ip-A, ip-C, ip-B], [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:33,533 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-20,ee,ip-B) ISPN000093: Received new, MERGED cluster view for
> > channel hibernate: MergeView::[ip-A|4] (3) [ip-A, ip-B, ip-C], 2
> > subgroups: [ip-A|2] (3) [ip-A, ip-C, ip-B], [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:33,518 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-7,ee,ip-A) ISPN000093: Received new, MERGED cluster view for
> > channel server: MergeView::[ip-A|4] (3) [ip-A, ip-B, ip-C], 2
subgroups:
> > [ip-A|2] (3) [ip-A, ip-C, ip-B], [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:33,525 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-7,ee,ip-A) ISPN000093: Received new, MERGED cluster view for
> > channel keycloak: MergeView::[ip-A|4] (3) [ip-A, ip-B, ip-C], 2
> > subgroups: [ip-A|2] (3) [ip-A, ip-C, ip-B], [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:33,525 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-7,ee,ip-A) ISPN000093: Received new, MERGED cluster view for
> > channel web: MergeView::[ip-A|4] (3) [ip-A, ip-B, ip-C], 2 subgroups:
> > [ip-A|2] (3) [ip-A, ip-C, ip-B], [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:33,527 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-7,ee,ip-A) ISPN000093: Received new, MERGED cluster view for
> > channel hibernate: MergeView::[ip-A|4] (3) [ip-A, ip-B, ip-C], 2
> > subgroups: [ip-A|2] (3) [ip-A, ip-C, ip-B], [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:33,527 INFO
> > [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> > (Incoming-7,ee,ip-A) ISPN000093: Received new, MERGED cluster view for
> > channel ejb: MergeView::[ip-A|4] (3) [ip-A, ip-B, ip-C], 2 subgroups:
> > [ip-A|2] (3) [ip-A, ip-C, ip-B], [ip-A|3] (2) [ip-A, ip-B]
> > 05:09:33,577 INFO [org.infinispan.CLUSTER]
(transport-thread--p14-t12)
> > ISPN000310: Starting cluster-wide rebalance for cache authorization,
> > topology CacheTopology{id=10, rebalanceId=3,
> > currentCH=DefaultConsistentHash{ns=80, owners = (3)[ip-A: 27+53, ip-C:
> > 27+53, ip-B: 26+54]}, pendingCH=DefaultConsistentHash{ns=80, owners =
> > (3)[ip-A: 27+53, ip-B: 26+54, ip-C: 27+53]}, unionCH=null,
> > actualMembers=[ip-A, ip-B, ip-C]}
> > 05:09:33,579 INFO [org.infinispan.CLUSTER]
(transport-thread--p14-t12)
> > ISPN000310: Starting cluster-wide rebalance for cache offlineSessions,
> > topology CacheTopology{id=10, rebalanceId=3,
> > currentCH=DefaultConsistentHash{ns=80, owners = (3)[ip-A: 27+53, ip-C:
> > 27+53, ip-B: 26+54]}, pendingCH=DefaultConsistentHash{ns=80, owners =
> > (3)[ip-A: 27+53, ip-B: 26+54, ip-C: 27+53]}, unionCH=null,
> > actualMembers=[ip-A, ip-B, ip-C]}
> > 05:09:33,580 INFO [org.infinispan.CLUSTER]
(transport-thread--p14-t12)
> > ISPN000310: Starting cluster-wide rebalance for cache loginFailures,
> > topology CacheTopology{id=10, rebalanceId=3,
> > currentCH=DefaultConsistentHash{ns=80, owners = (3)[ip-A: 27+53, ip-C:
> > 27+53, ip-B: 26+54]}, pendingCH=DefaultConsistentHash{ns=80, owners =
> > (3)[ip-A: 27+53, ip-B: 26+54, ip-C: 27+53]}, unionCH=null,
> > actualMembers=[ip-A, ip-B, ip-C]}
> > 05:09:33,582 INFO [org.infinispan.CLUSTER]
(transport-thread--p14-t15)
> > ISPN000310: Starting cluster-wide rebalance for cache sessions,
topology
> > CacheTopology{id=10, rebalanceId=3,
> > currentCH=DefaultConsistentHash{ns=80, owners = (3)[ip-A: 27+53, ip-C:
> > 27+53, ip-B: 26+54]}, pendingCH=DefaultConsistentHash{ns=80, owners =
> > (3)[ip-A: 27+53, ip-B: 26+54, ip-C: 27+53]}, unionCH=null,
> > actualMembers=[ip-A, ip-B, ip-C]}
> > 05:09:33,589 INFO [org.infinispan.CLUSTER] (remote-thread--p7-t130)
> > ISPN000336: Finished cluster-wide rebalance for cache loginFailures,
> > topology id = 10
> > 05:09:33,589 INFO [org.infinispan.CLUSTER] (remote-thread--p7-t130)
> > ISPN000336: Finished cluster-wide rebalance for cache authorization,
> > topology id = 10
> > 05:09:33,590 INFO [org.infinispan.CLUSTER] (remote-thread--p7-t131)
> > ISPN000336: Finished cluster-wide rebalance for cache offlineSessions,
> > topology id = 10
> > 05:09:33,601 INFO [org.infinispan.CLUSTER] (remote-thread--p7-t133)
> > ISPN000336: Finished cluster-wide rebalance for cache sessions,
topology
> > id = 10
> > 05:09:34,001 ERROR [org.jgroups.protocols.TCP] (Connection.Receiver
> > [IP-A:35361 - IP-C:7600],ee,ip-A) ip-A: failed submitting DONT_BUNDLE
> > message to thread pool: java.util.concurrent.
RejectedExecutionException:
> > Task org.jgroups.protocols.TP$SingleMessageHandler@17c86a0c rejected
> > from java.util.concurrent.ThreadPoolExecutor@52cae691[Running, pool
size
> > = 4, active threads = 4, queued tasks = 100, completed tasks =
1589693].
> > Msg: RequestCorrelator: id=200, type=REQ, id=607, rsp_expected=true,
> > FORK: ee:keycloak, NAKACK: [XMIT_RSP, seqno=206], TCP:
[cluster_name=ee]
> > ERROR
> > 05:09:34,010 ERROR [org.jgroups.protocols.TCP] (Connection.Receiver
> > [IP-A:35361 - IP-C:7600],ee,ip-A) ip-A: failed submitting DONT_BUNDLE
> > message to thread pool: java.util.concurrent.
RejectedExecutionException:
> > Task org.jgroups.protocols.TP$SingleMessageHandler@4fec3655 rejected
> > from java.util.concurrent.ThreadPoolExecutor@52cae691[Running, pool
size
> > = 4, active threads = 4, queued tasks = 100, completed tasks =
1589694].
> > Msg: RequestCorrelator: id=200, type=REQ, id=609, rsp_expected=true,
> > FORK: ee:keycloak, NAKACK: [XMIT_RSP, seqno=208], TCP:
[cluster_name=ee]
> > ERROR
> >
> > (last line repeated many, many times)
> > ---------------------->%-----------------------
> >
> >
> >
> > Infinispan subsystem configuration in standalone-ha.xml:
> >
> > ---------------------->%-----------------------
> > <subsystem xmlns="urn:jboss:domain:infinispan:4.0">
> > <cache-container name="keycloak"
jndi-name="infinispan/
Keycloak">
> > <transport lock-timeout="60000"/>
> > <local-cache name="realms">
> > <eviction max-entries="10000"
strategy="LRU"/>
> > </local-cache>
> > <local-cache name="users">
> > <eviction max-entries="10000"
strategy="LRU"/>
> > </local-cache>
> > <distributed-cache name="sessions" mode="SYNC"
owners="3"/>
> > <distributed-cache name="offlineSessions"
mode="SYNC"
> owners="3"/>
> > <distributed-cache name="loginFailures"
mode="SYNC"
owners="3"/>
> > <distributed-cache name="authorization"
mode="SYNC"
owners="3"/>
> > <replicated-cache name="work" mode="SYNC"/>
> > <local-cache name="keys">
> > <eviction max-entries="1000"
strategy="LRU"/>
> > <expiration max-idle="3600000"/>
> > </local-cache>
> > </cache-container>
> > <cache-container name="server" aliases="singleton
cluster"
> > default-cache="default"
module="org.wildfly.clustering.server">
> > <transport lock-timeout="60000"/>
> > <replicated-cache name="default"
mode="SYNC">
> > <transaction mode="BATCH"/>
> > </replicated-cache>
> > </cache-container>
> > <cache-container name="web" default-cache="dist"
> > module="org.wildfly.clustering.web.infinispan">
> > <transport lock-timeout="60000"/>
> > <distributed-cache name="dist" mode="ASYNC"
l1-lifespan="0"
> > owners="2">
> > <locking isolation="REPEATABLE_READ"/>
> > <transaction mode="BATCH"/>
> > <file-store/>
> > </distributed-cache>
> > </cache-container>
> > <cache-container name="ejb" aliases="sfsb"
default-cache="dist"
> > module="org.wildfly.clustering.ejb.infinispan">
> > <transport lock-timeout="60000"/>
> > <distributed-cache name="dist" mode="ASYNC"
l1-lifespan="0"
> > owners="2">
> > <locking isolation="REPEATABLE_READ"/>
> > <transaction mode="BATCH"/>
> > <file-store/>
> > </distributed-cache>
> > </cache-container>
> > <cache-container name="hibernate"
default-cache="local-query"
> > module="org.hibernate.infinispan">
> > <transport lock-timeout="60000"/>
> > <local-cache name="local-query">
> > <eviction strategy="LRU"
max-entries="10000"/>
> > <expiration max-idle="100000"/>
> > </local-cache>
> > <invalidation-cache name="entity"
mode="SYNC">
> > <transaction mode="NON_XA"/>
> > <eviction strategy="LRU"
max-entries="10000"/>
> > <expiration max-idle="100000"/>
> > </invalidation-cache>
> > <replicated-cache name="timestamps"
mode="ASYNC"/>
> > </cache-container>
> > </subsystem>
> > ---------------------->%-----------------------
> >
> > JGroups subsystem configuration:
> >
> > ---------------------->%-----------------------
> > <subsystem xmlns="urn:jboss:domain:jgroups:4.0"
default-stack="tcp">
> > <channels default="ee">
> > <channel name="ee" stack="tcp"/>
> > </channels>
> > <stacks>
> > <stack name="tcp">
> > <transport type="TCP"
socket-binding="jgroups-tcp"/>
> > <protocol type="S3_PING">
> > <property
name="access_key">S3AccessKey</property>
> > <property name="secret_access_key">
> S3SecretAccessKey</property>
> > <property
name="location">S3PingBucketName</property>
> > </protocol>
> > <protocol type="MERGE2"/>
> > <protocol type="FD_SOCK"
socket-binding="jgroups-tcp-fd"/>
> > <protocol type="FD"/>
> > <protocol type="VERIFY_SUSPECT"/>
> > <protocol type="pbcast.NAKACK"/>
> > <protocol type="UNICAST2"/>
> > <protocol type="pbcast.STABLE"/>
> > <protocol type="pbcast.GMS"/>
> > <protocol type="UFC"/>
> > <protocol type="MFC"/>
> > <protocol type="FRAG2"/>
> > <protocol type="RSVP"/>
> > </stack>
> > <stack name="udp">
> > <transport type="UDP"
socket-binding="jgroups-udp"/>
> > <protocol type="PING"/>
> > <protocol type="MERGE3"/>
> > <protocol type="FD_SOCK"
socket-binding="jgroups-udp-fd"/>
> > <protocol type="FD_ALL"/>
> > <protocol type="VERIFY_SUSPECT"/>
> > <protocol type="pbcast.NAKACK2"/>
> > <protocol type="UNICAST3"/>
> > <protocol type="pbcast.STABLE"/>
> > <protocol type="pbcast.GMS"/>
> > <protocol type="UFC"/>
> > <protocol type="MFC"/>
> > <protocol type="FRAG2"/>
> > </stack>
> > </stacks>
> > </subsystem>
> > ---------------------->%-----------------------
> >
> > with kind regards,
> >
> > Edwin de Jong
> >
> > -- Simacan B.V. Data Engineer
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
> --
>
> --Hynek
>
>
> ------------------------------
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
> End of keycloak-user Digest, Vol 44, Issue 23
> *********************************************
>
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
2462
days inactive
2463
days old
3 comments
4 participants
participants (4)
-
Bill Burke -
Doug Drouillard -
Pedro Igor Silva -
Simon Payne