Using credentials from another provider in an authenticator - failing second time around
by Nikki Pack
Hi All,
I am currently developing an SMS based OTP solution, I¹ve hit a strange
issue which I cannot fathom hence my asking here.
I create a credential (which is the mobile number) in a required action, and
then use it in an authenticator later on (this actually generates/sends the
OTP) - during registration this works as expected, if the user returns and
logs in, the authenticator is failing due to not getting a value for the
credential Am I missing something really obvious here?
Code is all here:
https://github.com/nickpack/keycloak-sms-authenticator-sns/tree/develop/src/
main/java/six/six/keycloak
It is basically an adaptation of the secret-question¹ example and some code
I found that somebody else had started on for a previous version of key
cloak.
Thanks in advance,
Nick
8 years, 4 months
Trying to get tomcat 8.0.x working.
by Jim Tyrrell
I follow the docs here:Tomcat 6, 7 and 8 Adapters | Keycloak Documentation
|
| |
Tomcat 6, 7 and 8 Adapters | Keycloak Documentation
By Keycloak | |
|
The setup for a valve, context, and securing a folder mostly makes sense as that just follows the normal tomcat security setup that has been there forever.
The one question, is the setting BASIC or KEYCLOAK in <login-config> <auth-method>BASIC</auth-method>
KEYCLOAK seems to be used in other configs, however, it locks up the deployment of my application in Tomcat.
The big gap is the JSON config to drive this:Java Adapters Config | Keycloak Documentation
|
| |
Java Adapters Config | Keycloak Documentation
By Keycloak | |
|
A lot of magic info is "injected" into this file. Where and how am I getting values that go into this file is fairly undocumented in the context of getting this working for Tomcat? Does a minimal version of this file exist.
The other gap is it seems I need to setup something around clients in the admin interface, but again the docs are thin.I do get to the point where I see an error "Invalid parameter: redirect_uri" Again I can't find any documentation around this and how do I get this all working in the context of Tomcat.
Does a top to bottom blog posting exist around Tomcat 8.0.x, about how to go about doing this?
Do integration tests exist around Tomcat configuration to make this work?
Thanks in advance.
8 years, 4 months
Accessing authenticator context from a required action
by Nikki Pack
Hi All,
I am currently implementing a custom 2FA provider (SMS via AWS SNS), I have
managed to get the authentication side of things behaving as expected, but I
am struggling to work out the best way of implementing the required action
for the registration side of things.
The main issue I face, is that the authentication provider stores
credentials for the SMS service provider, and I don¹t seem to be able to
access the authenticator context from the required action class (Not to
mention the lack of configuration options for required actions) I am sure
I am being stupid somewhere here.
https://github.com/nickpack/keycloak-sms-authenticator-sns/blob/develop/src/
main/java/six/six/keycloak/authenticator/KeycloakSmsAuthenticator.java#L44
I basically need to be able to do this from the required action (You will
see this is not implemented in that repo yet).
Thanks in advance for any help.
Regards,
Nick
8 years, 4 months
discovery and key security
by Simon Payne
Hi,
I have found that .well-known and jwks_uri endpoints are left unsecured
meaning that unauthenticated clients can discover auth server configuration
and signing keys.
surely we should require minimum of basic authentication using client id
and secret?
thanks
Simon.
8 years, 5 months
ADFS Support Without Keycloak Server
by James .
Hi,
I've read the announcement that Picketlink and Keycloak are merging.
We currently use Picketlink to SSO with AD FS. Is that still possible with Keycloak or do I need a Keycloak server in between the application and ADFS?
If I do need a server at the the moment are there any plans to change this during the merging of the two projects?
Thank you,
James.
8 years, 5 months
Keycloak Spring Boot Bearer Authentication
by Mcshane, James P
I am working on a set of Spring Boot modules all within the same Realm in Keycloak. I would like the service to have bearer only authentication so that the service can only be accessed by authorized clients. For the spring-security adapter, I see the KeycloakRestTemplate, but the factory there requires the SecurityContextHolder, which isn’t present out of the box in the authentication mechanism for the spring-boot adapter.
Is there a different rest template that could use the different container auth solutions provided by the KeycloakAutoConfiguration class? Clearly accessing the bearer authentication values from these systems is app server dependent, so it would seem to make sense to have a KeycloakClientRequestFactory provider that can handle the different types of container auth that is being done by the spring-boot adapter. Has this been done already, but not yet documented? In either case, I would be happy to contribute docs or code that deals with these different implementations.
Thanks,
James
________________________________
This e-mail and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient or the individual responsible for delivering the e-mail to the intended recipient, please be advised that you have received this e-mail in error and that any use, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited.
If you have received this communication in error, please return it to the sender immediately and delete the original message and any copy of it from your computer system. If you have any questions concerning this message, please contact the sender. Disclaimer R001.0
8 years, 5 months
Re: [keycloak-user] token introspection
by Doug Drouillard
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
> *********************************************
>
8 years, 5 months
JSON Web Encryption
by Simon Payne
does keycloak offer access token encryption?
so far i can only see that keycloak signs the JWT rather than encrypting
the content.
Thanks
Simon.
8 years, 5 months
