Lots of errors in cross-datacenter replication mode with Infinispan Server 9.4.x
by Juan Antonio Farre Basurte
Hello,
We've built an installation of Keycloak 6.0.1 with cross-datacenter
replication using Infinispan Server 9.4.15.Final.
About three minutes after starting Keycloak, we start getting lots of
sequences of the following three errors:
ISPN000136: Error executing command RemoveExpiredCommand on Cache 'work'
ISPN000136: Error executing command RemoveCommand on Cache 'work'
ISPN000071: Caught exception when handling command SingleXSiteRpcCommand
Please, see the attached log for more detail.
The attached log is the server.log one of the Infinispan servers.
There you can see that around 17:49 the Keycloak server started and a
couple of warnings regarding cache activity are shown. These warnings are
normal as per Keycloak documentation troubleshooting.
At 17:52, the errors start appearing in a non-stop fashion.
This goes on until one of the infinispan sites automatically goes offline
(only one repetition included in the log file, because it was too big for
the mailing list).
The errors are always related to the work cache only.
Note that the log has been anonymized and host, node, site names, IP's,
ports, etc. do not correspond to the real ones. We have made a best effort
not to obfuscate any relevant information, however.
This log corresponds to an Infinispan 9.4.15 and a Keycloak 4.8.3, both in
domain mode, with one node per data center each.
No error appears in Keycloak logs, even in debug mode (or we haven't found
it).
To discard possible mistakes in the configuration, we have also tested it
with the exact configuration in:
https://www.keycloak.org/docs/latest/server_installation/index.html#setup
These are the results for serveral combinations of versions, always with
the exact example configuration from the docs:
Keycloak Infinispan Result
======== ======== ======
6.0.1 9.4.15 Error
4.8.3 9.4.15 Error
4.8.3 9.4.0 Error
4.8.3 9.3.6 Works
6.0.1 9.3.6 Does not connect
5.0.0 9.3.6 Does not connect
In the three first setups, the log looks exactly the same as the attached
log.
In the fourth setup, everything works fine.
In the two last setups, Keycloak couldn't connect to infinispan, probably
because it's too old.
Our conclusion is that there is a bug showing up only for Infinispan 9.4.x
and not for Infinispan 9.3.x.
Given that the same version of Keycloak works with Infinispan 9.3 and
doesn't work with Infinispan 9.4, this may be an Infinispan bug, but we
have not been able to reproduce it by directly writing onto the work
cache; we have always needed to start Keycloak to reproduce it.
For this reason, we cannot totally discard a problem in Keycloak which
would show up only with later versions of Infinispan.
Any help will be appreciated. If you need any further information, don't
hesitate to ask.
Thank you very much,
Juan
Juan Antonio Farré Basurte
Arquitectura e Innovación
Avda. de Extremadura s/n
37187, Aldeatejada - SALAMANCA
M: +34 647 35 09 72| T: +34 923 70 17 75
E-mail: jafarre(a)viewnext.com | Web: www.viewnext.com
------------------------------------------------------------------------------------------------------------------------------------
Este mensaje va dirigido únicamente a la(s) persona(s) y/o entidad(es) arriba relacionada(s).
Puede contener información confidencial o legalmente protegida. Si no es usted el destinatario
señalado, le rogamos borre del sistema inmediatamente el mensaje y sus copias. Asimismo le
informamos que cualquier copia, divulgación, distribución o uso de los contenidos está prohibida.
---------------
This message is addressed only to the person (people) and / or entities listed above. It may contain confidential or legally protected information. If you are not the recipient indicated, please delete the message and its copies immediately from the system. We also inform that any copy, disclosure, distribution or use of the contents is forbidden
---------------------------------------------------------------------------------------------------------------
Viewnext, S.A. Domicilio Social: Avda. de Burgos 8-A 28036 de Madrid.
telf: 913834060, Fax: 913834090. Reg. M. Madrid: Tomo 3238, Libro:0, Folio: 78, Seccion: 8ª, Hoja M-55112, N.I.F.: A-80157746
4 years, 10 months
Custom Social Login, cache access_token, Enterprise Wechat
by kkzxak47
Hi,
I'm building a SSO service for my company (~1000 employee).
After investigation I decided to adopt Keycloak as the core component.
We are using Wechat Work as IM tool (https://work.weixin.qq.com/),
employee DB is based on its Contacts. So it's natural to integrate it as a
social login into Keycloak SSO service.
In the process of implementing the 'WechatIdentityProvider' and
'WechatIdentityProviderFactory' classes I encountered some trouble.
Just like Twitter / Google and other providers, some of Wechat Work's
OAuth2 flow is not aligned with standards. For example, the processing of
retrieving the access_token is relatively independent of other OAuth2 code
flow, the access_token is valid for 7200 seconds, its API is limited to be
called 2000 times per day for a single client. We are forced to cache a
global access_token for each client. I noticed that Keycloak is heavily
using Infinispan. My question is can I use it for caching access_token too?
Is it safe to do so? What is your recommendation?
And I'm working based on version 6.0.1 in standalone mode, is it
appropriate?
My main programming language is not Java by the way. I learned it ~10
years ago and Spring is new to me. So I'm still learning. It's of great
help to give relevant document links or code snippets, thanks!
Victor
4 years, 10 months
Keycloak 7
by Ernedin Zajko
Hi everyone,
as Keycloak was tagged with 8.0.0-SNAPSHOT, any news on 7.0.0 release
(or will it be skipped) ?
regards,
--- eZ
4 years, 10 months
Question about CBAC + Pushing Claims + Authorization Scopes
by Álvaro Gómez
Hi,
We are applying RBAC and CBAC models to evaluate permissions in a
multi-tenant UMA application. We are using Pushing Claims to let custom
policies determine if an user has an specific role in a provided context
(tenant) via Pushing Claims.
Everything works fine if we use non-scoped resources but things get a bit
confusing when we use scoped ones since the pushing-claims (representing
the tenants) end up mixed in the RPT permission claim without leaving any
trace of the scopes with which they were pushed along. Consider the
following example:
We have an application which manages products (represented by resources).
There are profiles (represented by roles) which allow users to sell, modify
or delete products (represented by scopes). A certain user may interact
with one product in the context of a tenant (Determined by the Pushing
claim) with an specific role and with some different role from other
tenant.
- Resource:
* product (With scopes sell and update)
- Roles:
* Seller
* Product-Manager
- Policies:
* Is-Seller (In the Tenant specified in the Pushing Claim "tenant")
* Is-Product-Manager (In the Tenant specified in the Pushing Claim
"tenant")
- Permissions:
* product:sell -> Provides the "sell" scope of the resource "product" if
the "Is-Seller" policy evaluates to grant.
* product:update -> Provides the "update" scope of the resource
"product" if the "Is-Product-Manager" policy evaluates to grant.
- Users:
* Alice -> Alice is "Seller" in the tenant "Organization-1" and is
"Product-Manager" in the tenant "Organization 2" so she should be able to
sell products in the context of the tenant "Organization-1" and update
products in the context of "Organization-2" but neither "update" products
in the context of "Organization-1" or sell products in the context of
"Organization-2".
1.- Alice requests an RPT using the following ticket:
{ "resource": "product", "resource_scopes": ["sell"], "claims": {
"tenant": ["Organization-1"] } }
Since Alice is "Seller" in the "Organization-1" (meaning the Policy
"Is-Seller" will evaluate to "grant" if the provided claim value is
"Organization-1" and the evaluated Identity is Alice) an RPT is emitted
with the following "permission" claim:
[{
"resource": "product",
"resource_scopes": ["sell"],
"claims": { "tenant": ["Organization-1"] }
}]
2.- Alice upgrades the previous RPT with the following ticket:
{ "resource": "product", "resource_scopes": ["update"], "claims": {
"tenant": ["Organization-2"] } }
Here is were things get confusing to us. We'd expect Alice to be granted
when requesting the scope "update" in the context of "Organization-2" since
Alice has the role "Product-Manager" in that tenant. That would be what
happened if Alice was requesting the RPT for the first time instead of
upgrading a previous one. However, since we are upgrading the RPT obtained
in Step 1, when the policy "Is-Product-Manager" is evaluated, the claim
"tenant" is mixed with the one in Step 1 (Since they are not grouped by
scope) resulting in the following permission:
{
"resource": "product",
"resource_scopes": ["sell", "update"],
"claims": {
"tenant": ["Organization-1", "Organization-2"]
}
}
The policy can't evaluate to grant since Alice is not "Product-Manager"
in both tenants "Organization-1" and "Organization-2" (Obtained through
$evaluation.getPermission().getClaims()). When evaluating this policy we
would only be interested in the pushing-claim `{ "tenant":
["Organization-2"] }` which was pushed along with the scope "update" (which
is the one being evaluated by the permission "product:update" associated
with this Policy).
Shouldn't the claims be grouped by the scopes which with they were
pushed along? (See example at the end of this text), Are we missing
something?
Example:
{
"resource": "product",
"resource_scopes": [
{ "name": "sell", "claims": { "tenant": ["Organization-1"] } },
{ "name": "update", "claims": { "tenant": ["Organization-2"] } },
]
Thanks in advance,
Álvaro.
4 years, 10 months
CDI Support in keycloak
by Christian Froehlich
Hi,
CDI (Weld subsystem) is deactivated inside the keycloak server if I understood it right in the documentation. Is there a specific reason why you explicitly deactivate CDI?
Regards
Christian
4 years, 10 months
