Disable Sticky Sessions?
by Tomas Groth Christensen
Hi,
I am using keycloak as a broker where the user in a browser can choose
which identity provider to use for authentication and this works just
fine.
We have also set up a "headless flow" where an application using the
kc_idp_hint can preselect a special identity provider which can
authenticate the user (with a special authenticator) without user
interaction. This used to work fine, but with Keycloak 3.2.x this
breaks, since now Keycloak requires cookies to be enabled. As far as I
can tell this is because the AUTH_SESSION_ID cookie used for "Sticky
sessions" is now a hard requirement.
Is there a way to disable this hard requirement on cookies?
I know that enabling cookies will fix this for the application, but my
problem is that there is multiple implementation of this application,
and I don't control any of them.
Best regards,
Tomas
7 years, 4 months
Does the REST API support event creation
by Geadah, Nicolas (VEC)
Is it possible to create auditing events directly using the REST API? I'm not finding any method by which I could create events (or admin events) directly by calling the REST service.
Ideally some activities in our external applications would create keycloak event entries, but that does not look like it's possible.
Thanks!
7 years, 4 months
Re: [keycloak-user] Delegated User Self-Administration
by Michael Poettgen
Has anyone done delegated user administration with larger numbers of organizations?
Thanks,
Michael
From: Michael Poettgen
Sent: Monday, August 7, 2017 5:14 PM
To: 'keycloak-user(a)lists.jboss.org'
Subject: Delegated User Self-Administration
Hello Everyone,
I've got questions on how to properly do delegated user self-administration with Keycloak.
Some background information:
* We are working with hundreds or even thousands of organizations for which we want to manage access to our applications.
* Some of these organizations are our internal divisions for which we have active directories. Users from these organizations can be integrated through "User Storage Federation" and they will continue to be maintained in the respective directories.
* Some of these organizations are part of larger organizations which have proper identity providers. Users from these organizations can be integrated through "Identity Brokering" and they will continue to be maintained in the respective identity providers.
* For the remaining external organizations (and there are a lot of them) we would have to maintain user accounts ourselves and we would like to delegate that maintenance work to a designated user self-administrator within the external organization.
* A user self-administrator should be able to view, create, lock and unlock user accounts within the same organization.
* Optionally a user self-administrator should be able to grant or revoke access to particular (sets of) applications for the users he is allowed to administer.
I do understand that this could probably be achieved through separate realms and "Dedicated Realm Admin Consoles", but as far as I understand these realms would be entirely separate. This would mean that we would have to set up clients hundreds of times for each of the organizations. We would have to figure out how to direct each user to the proper realm for authentication and each organization would have its own login page.
* Does Keycloak have something like the notion of "sub-realms" where a user can authenticate against a realm, if there is a corresponding user account in the realm itself or in one of the sub-realms?
* It is probably possible to use the "User Storage SPI" to write a custom User Storage Federation Provider, but does that make sense? Would it perform well?
* Another option would probably be to write a custom User Self-Administration application using the "Admin REST API". (Unfortunately there is not even an API to retrieve users filtered by anything other than base properties, so the application could end up retrieving thousands of user accounts to find five accounts belonging to a particular organization.)
* The third option would be to customize Keycloak itself, but we are no Java experts, so is this advisable?
* Has anyone implemented a scenario like this with Keycloak?
* Does anyone know whether there are any plans to extend Keycloak to better support a scenario like this?
Thanks,
Michael
This message is for the designated recipient only and may contain privileged or confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.
7 years, 4 months
Re: [keycloak-user] DB deadlock for concurrent logins
by Vikrant Singh
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
>
7 years, 4 months
Re: [keycloak-user] KeyCloak 3.1.0 on OpenShift randomly unresponsive
by Anton Arntz
You are absolutely right, but at the time this was all the information I had and just wanted to check if anyone else had a similar experience.
We narrowed it down to 1 realm receiving a lot of requests. All the requests are originating from the customer's ADFS that fills up our log. It seems that those requests aren't even logged at the keycloak realm, but the "logout all sessions" button in the sessions part of the realm does stop the storm.
To answer your questions, customers didn't see the login page and keycloak didn't process HTTP requests anymore. KeyCloak is just one instance. I don't know the amount of database connections at that time. Will certainly look into those metrics next time.
-----Original Message-----
From: keycloak-user-bounces(a)lists.jboss.org [mailto:keycloak-user-bounces@lists.jboss.org] On Behalf Of Bill Burke
Sent: dinsdag 1 augustus 2017 16:31
To: keycloak-user(a)lists.jboss.org
Subject: Re: [keycloak-user] KeyCloak 3.1.0 on OpenShift randomly unresponsive
You'll need to narrow down the problem more. i.e. What does "can't login anymore" mean? Do customers still see login pages? Can Keycloak still receive and process HTTP requests? Or is there connection denied? Is Keycloak clustered? Or is it one instance? How many open database connections does the DB have?
On 8/1/17 5:47 AM, Anton Arntz wrote:
> We are currently facing an issue on our production environment in which the KeyCloak server becomes unresponsive at (what still looks like) random.
> Tried to look into memory, cpu load and disk usage of the specific OpenShift gear and gone through all of the logs but nothing out of the ordinary could be found.
> Looks like the application continues to run and still keeps logging, but none of the customers (realms) is able to login anymore.
> Has anyone experienced the same with this KeyCloak version?
>
> Kind regards,
> Anton Arntz
>
> _______________________________________________
> 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
7 years, 4 months
Error: [org.pac4j.oidc.credentials.authenticator.OidcAuthenticator]
by Harshad Keluskar
We have three servers with below listed services.
* Keycloak for IDP
* Apereo CAS for Delegate Authentication
* Liferay CE7 for portals
We followed and configured all steps which suggested for respective tools / applications. And configured authorized SSLs (from godaddy) certificates for above mentioned servers. Liferay authenticates against CAS using the CAS protocol. CAS delegates authentication to keycloak using OpenID Connect.
I'm getting an error while trying check the whole workflow. Please see below for the more details and error.
When I tap on "Sign IN" on Liferay portal, it redirects me to keycloak authentication page via CAS (Auth Delegation) and after entering the valid credentials in the keycloak page, it provides an error in the cas logs which is mentioned below:
> 2017-08-09 18:29:30,906 DEBUG
> [org.pac4j.oidc.credentials.extractor.OidcExtractor] - <Authentication
> response successful> 2017-08-09 18:29:30,906 WARN
> [org.pac4j.oidc.credentials.authenticator.OidcAuthenticator] -
> <Preferred token endpoint Authentication method: null not available.
> Defaulting to: private_key_jwt>
And I got this error message on browser screen:
> "Unauthorized Access Either the authentication request was
> rejected/cancelled, or the authentication provider denied access due
> to permissions, etc. Review logs to find the root cause of the issue."
It would be great, if you could help me to get this resolved.
Thanks,
Harshad.
7 years, 4 months
JGroups failure: failed submitting DONT_BUNDLE message to thread pool
by Edwin de Jong
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
7 years, 4 months
token introspection
by Simon Payne
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.
7 years, 4 months
Recaptcha Provider causing PersistenceExceptions
by John D. Ament
Hi,
After upgrading to Keycloak 3.2 we found on the admin screens they won't
load in certain scenarios, under authentication -> flows. When we choose
the registration or browser flows, the following stacktrace is seen:
17:33:25,251 ERROR [io.undertow.request] (default task-12) UT005023:
Exception handling request to
/auth/admin/realms/qpd-manager/authentication/flows/registration/executions:
org.jboss.resteasy.spi.UnhandledException:
org.keycloak.models.ModelException: java.lang.IllegalArgumentException: id
to load is required for loading
at
org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:76)
at
org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:212)
at
org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:168)
at
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:411)
at
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202)
at
org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221)
at
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
at
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at
io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
at
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
at
org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:90)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
at
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at
io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
at
io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at
io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at
org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
at
io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at
io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at
io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at
io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at
io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at
io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
at
io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
at
io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at
io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.keycloak.models.ModelException:
java.lang.IllegalArgumentException: id to load is required for loading
at
org.keycloak.connections.jpa.PersistenceExceptionConverter.convert(PersistenceExceptionConverter.java:61)
at
org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:51)
at com.sun.proxy.$Proxy66.find(Unknown Source)
at
org.keycloak.models.jpa.RealmAdapter.getAuthenticatorConfigById(RealmAdapter.java:1576)
at
org.keycloak.services.resources.admin.AuthenticationManagementResource.recurseExecutions(AuthenticationManagementResource.java:512)
at
org.keycloak.services.resources.admin.AuthenticationManagementResource.recurseExecutions(AuthenticationManagementResource.java:500)
at
org.keycloak.services.resources.admin.AuthenticationManagementResource.getExecutions(AuthenticationManagementResource.java:464)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
at
org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
at
org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
at
org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138)
at
org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107)
at
org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133)
at
org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107)
at
org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133)
at
org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101)
at
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395)
... 37 more
Caused by: java.lang.IllegalArgumentException: id to load is required for
loading
at org.hibernate.event.spi.LoadEvent.<init>(LoadEvent.java:93)
at org.hibernate.event.spi.LoadEvent.<init>(LoadEvent.java:63)
at
org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.load(SessionImpl.java:2693)
at org.hibernate.internal.SessionImpl.get(SessionImpl.java:975)
at
org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1075)
at
org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1033)
at sun.reflect.GeneratedMethodAccessor319.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:49)
... 56 more
However, keycloak is handling a null return value, that isn't what's
happening in JPA. The ID in this case is null, which causes hibernate to
throw a persistence exception that the ID must not be null to do a load.
I have no idea what is causing this, however it only happens when our
custom providers are deployed to Keycloak. This does not happen in
Keycloak 3.1. The execution in this case is when loading the recaptcha
execution. We have no customized anything with regard to recaptcha.
John
7 years, 4 months
