We have a plan to translate keycloak-documentation to Japanese for the
community at our company.
Because there is no place to manage the translation resources in
we are planning to put the resources into own repository and publish
the built documents to our corporate site.
Do you have any concerns?
Of course, we can contribute it if there are any plans to translate it
Nomura Research Institute, Ltd.
I saw there are activities to replace client templates with client scopes. UMA 2.0 uses the term “client scope” to determine what the OAuth client wants to do with the granted access (e.g. this could be used to determine the purpose of processing some data for GDPR compliance). Since Keycloak will also support UMA 2.0, I am a little concerned this might lead to some confusion. As you know, there are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors. ☺ WDYT?
Mit freundlichen Grüßen / Best regards
Dr.-Ing. Sebastian Schuster
Engineering and Support (INST/ESY1)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com<http://www.bosch-si.com>
Tel. +49 30 726112-485 | 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
These are my thoughts for implementing offline access tokens:
* offline access tokens MUST be validated. This means that if they
are used during bearer token requests, the service must validate the
token with the token endpoint.
* These tokens MUST be rejected by older keycloak clients as our
adapters dont' have support for them.
* offline access tokens will not be stored in the database. Instead
they will be JWEs or JWS that link to an offline user session. (our
current offline access implementation). They will be revokable just
like any other offline session and in the same manner. This makes the
* There will be 4 modes for configuring clients
- client automatically receives offline access tokens (maybe not
include a refresh token in this case)
- client may request an offline access token
- client requires consent before providing an offline access token
- client is not allowed to ask for offline access tokens (default)
Any other thoughts on this?
Maybe this should be implemented in conjunction with a reference token
I have a golang client utility (kcinit) that I need to integrate with
tests in our testsuite. Its possible to integrate golang with maven
using this maven plugin:
To integrate my tool into the arquillian testsuite, I've pulled in
this plugin to pull down and build my golang tool so that it can be
executed within a test. The way it works is that the maven plugin
will first download the Golang SDK and store it within ~/.mvnGolang.
It will also store any source code it pulls down and builds there. It
will build a binary that is specific to the platform it is running on
so this is perfect for our testsuite.
Next question is distribution. "kcinit" is a command line utility.
Should I add this to our current client tools directory in the disto
or create a separate dis zipt? Ok to include binaries for linux, osx,
and windows? This will require the maven plugin to individually
cross-compile for each platform. Its not superfast and our distro
build will be slower, but we will have one place to pull this stuff
together. I will need to eventually create an RPM for this tool so
that it can be automatically installed in Fedora/RHEL.
I wanted to make a small pull request into keycloak
<https://github.com/keycloak/keycloak/> but it passed more than a our but I
still not even built the project.
First of all it was cloned about 4 minutes. No so much, but a long as for
Then I started build process and it took a long time to download all
dependencies which exists on Maven Central. Meanwhile I opened Keycloak
project in Intellij and it started to index all files.
Finally at some point build failed with OOM :(
I checked and found that Keycloak sources contains about 100Mb of built
examples and about 300 Mb of node_modules in themes folder.
So my proposition is: how about to split mono repository into few smaller?
As I see we can easily move examples and themes into separate repos under
keycloak organisation on Github.
This will decrease network load and simplify project initialization. But
we'll still be able to build examples and themes.
Sergey Ponomarev <http://www.linkedin.com/in/stokito>
I missed one cool new feature. We also now have support for UMA 2.0
including allowing users to manage resource permissions in the account
On Thu, 22 Mar 2018, 21:03 Stian Thorgersen, <sthorger(a)redhat.com> wrote:
> I'm very pleased to announce the first release of Keycloak 4!
> To download the release go to the Keycloak homepage
> HighlightsBrand new login pages
> The login pages have received a brand new look. They now look much more
> modern and clean!
> Themes and Theme Resources
> It's now possible to hot-deploy themes to Keycloak through a regular
> provider deployment. We've also added support for theme resources. Theme
> resources allows adding additional templates and resources without creating
> a theme. Perfect for custom authenticators that require additional pages
> added to the authentication flow.
> We've also added support to override the theme for specific clients. If
> that doesn't cover your needs, then there's a new Theme Selector SPI that
> allows you to implement custom logic to select the theme.
> Native promise support to keycloak.js
> has support for the old style promises as well. Both can be used
> Edit links in documentation
> To make it easier to contribute changes to the documentation we have added
> links to all sections of the documentation. This brings you straight to the
> GitHub editor for the relevant AsciiDoctor file. There's also a quick link
> to report an issue on a specific page that will include the relevant page
> in the description.
> HTTPS support on keycloak.org
> Thanks to GitHub pages and Let's Encrypt there's finally HTTPS on
> keycloak.org. About time?
> Loads more..
> The full list of resolved issues is available in JIRA
> Before you upgrade remember to backup your database and check the upgrade
> guide <http://www.keycloak.org/docs/latest/upgrading/index.html> for
> anything that may have changed.