Next Keycloak Release
by Schuster Sebastian (INST-CSS/BSV-OS2)
Hi everybody!
Does anybody know when the next Keycloak version will be released? Will it be 7.0.0 or 8.0.0 as indicated by https://github.com/keycloak/keycloak/commit/17e9832dc6418ce516ad47946ed77...
Thanks and best regards,
Sebastian
Mit freundlichen Grüßen / Best regards
Dr.-Ing. Sebastian Schuster
Open Source Services (INST-CSS/BSV-OS2)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com<http://www.bosch-si.com>
Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Fax +49 30 726112-100 | Sebastian.Schuster(a)bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com>
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber, Michael Hahn, Dr. Aleksandar Mitrovic
5 years, 6 months
Resteasy 4.2
by Ben Tatham
Hi all,
I've submitted a jira ticket
<https://issues.jboss.org/browse/KEYCLOAK-11142> and PR
<https://github.com/keycloak/keycloak/pull/6254>, but coming back here to
get others input.
We use keycloak-admin-client
<https://github.com/keycloak/keycloak/tree/master/integration/admin-client> in
our code to talk to our keycloak instance. We also use Resteasy in our
application, and we have moved to 4.2.
As such, we can either share the keycloak-admin-client, or we can upgrade
the keycloak-admin-client to Resteasy 4.2. Unfortunately, the client is
part of the whole keycloak project, which makes sense because it depends on
keycloak-core, etc. But it also means that upgrading just the client
library means upgrading all of keycloak.
In general, I think libraries should always try to stay update to date with
3rd party code (in this case, both happen to be jboss, but still...), or
better yet shade the 3rd party libraries themselves so downstream user
don't have "dependency hell".
My course of action, if my PRs don't get accepted (or even if they do, but
take a while to get released), are to either:
a. make a shaded version of keycloak-admin-client in my own code.
b. fork keycloak, releasing just the keycloak-admin-client and its
dependencies and deploy that to our own internal artifact manager.
Thoughts? Any reason keycloak should not upgrade to the latest resteasy
versions? (I'm not definitely not a resteasy expert...)
-Ben
5 years, 6 months
Same tokens for different data centers
by Vinesh Kumar
Hi all,
If we are dealing with multiple data centers (Active- Active), then load
balancer will forward the request to which data-center. How is this
decided..? And if a session is created for a user in one data center and
token is returned, so can we use the same token for accessing data from
other data centers..?
Regards,
Sai
5 years, 6 months
User Event SPI
by Václav Muzikář
Hi,
I've created a design draft for User Event SPI [1] which should eventually
replace the generic Event SPI for user-related actions. I would be really
grateful for any feedback provided.
Thank you!
[1] https://github.com/keycloak/keycloak-community/pull/21/files
V.
--
Václav Muzikář
Senior Quality Engineer
Keycloak / Red Hat Single Sign-On
Red Hat Czech s.r.o.
5 years, 7 months
EventListener plugin: retrieving synced users
by Paul Edison
Hi,
I’m trying to write a plugin for Keycloak that should work (“export”) with the data of users that get freshly created or imported.
Currently writing it as a EventListerner Plugin that acts on adminEvents.
If a user is created in Keycloak itself in the local store this works fine.
With the event I get the "resourcePath=users/0958198e-7a5d-4fb3-9b1b-2481841bff3f"
and with that I can access the user:
> UserModel user = session.users().getUserById(<ID>, session.getContext().getRealm());
Thats fine – but with federation I got problems.
In the event of synchronisation I don’t get this information.
I only get the "resourcePath=user-storage/381a8a65-c425-487e-b14a-a1186fda5940/sync"
How would I get the users form that info?
Is there a way to get form the session the list of synced users form that ID? Where is the information stored with that ID?
I would need to know which users are new created an which are just updated.
A compelte list could be obtained from:
> List<UserModel> listLocalStoredUsers = session.userLocalStorage().getUsers(session.getContext().getRealm())
But that woudl always get me a big list that is always growing.
Kind regards,
Paul
5 years, 7 months
Replacing infinispan with Apache ignite
by abhishekumar005@yahoo.com
Hi all,I was wondering if we can replace the caching mechanism from infinispan to Apache Ignite. If yes, can someone share some documentation for this.
Regards,Abhishek
5 years, 7 months
File-based Vault implementation
by Sebastian Laskawiec
Hey,
We are considering an initial, file-based Vault [1] implementation that
we'll ship out of the box. I imagine a minimum set of requirements as the
following:
- Easy to write by hand (for testing)
- Works out of the box in Kubernetes (Kubernetes can mount Secrets as files)
- Make sure we do not cache file content anywhere, so we don't compromise a
secret value in Keycloak
Essentially, there are two approaches for such an implementation.
The first option is to put all secrets into a shared file representing
key-value pairs (a properties file is a natural candidate for such an
implementation). This approach very easy to use but it's pretty hard to
search for a particular key in a file. We would need to make sure that we
don't cache anything wile parsing the file (in BufferedInputStream for
example). Such an implementation would also be pretty slow, since whenever
we'd access the vault for a particular key, we would potentially need to
search the whole file.
The second option is more complicated. Imagine the following file structure
(inside a vault directory):
my-secret-1 (secret value in its content)
my-secret-2 (secret value in its content)
my-secret-3 (secret value in its content)
In other words, each key is a file in a vault directory and its content
corresponds the secret value. Such an implementation is not very easy to
use as we'd need to create many small files. However, it's super fast for
searching and we can securely read the value without a risk of compromising
other secret values provided by the vault.
I wonder what do you think about this? My personal take on this is that we
should provide both implementations. The former (single file) would be used
in our testsuite (because of simplicity) and the latter (multiple files) in
production and in Kubernetes.
Thanks,
Sebastian
[1]
https://github.com/keycloak/keycloak-community/blob/master/design/secure-...
5 years, 7 months