keycloak-documentation translation
by Hiroyuki Wada
Hello,
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
keycloak-documentation repository,
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
officially.
Best Regards,
--
Hiroyuki Wada,
Nomura Research Institute, Ltd.
6 years, 7 months
Authenticating Desktop Applications with Keycloak and the keycloak-installed adapter
by Thomas Darimont
Hello folks,
I played a bit with the undocumented? [0] keycloak-installed adapter [1]
for integrating
desktop applications with Keycloak SSO and found some issues with it, which
I'd like to share.
Small explanation for those who are reading the list but don't know the
adapter... [2]
First some general notes / suggestions:
Is the keycloak-installed adapter something that will stay in keycloak or
was this just a PoC?
In the former case I think there are some things that could be improved or
extended a bit:
- Allow users to customize the locale used for the login pages opened by
the adapter
- Provide customizable response templates (perhaps by leveraging a provided
ResourceBundle)
- Allow to customize pages shown after login / logout served by the
keycloak-installed adapter
- Add support for TLS (with custom certificates) for https:// with localhost
I noticed that some browsers (e.g. Chrome) show an error page when trying
to
redirect to the local mini-webserver after a successful login since the
mini-webserver
(...server-socket) embedded in the adapter doesn't respond with a valid
HTTP response.
With that fixed, it worked with all browsers I tested (IE, Firefox, Chrome).
My current modifications of the keycloak-installed adapter
(with HTTP response fixes and response customizations) are here:
https://github.com/thomasdarimont/keycloak/commit/b8ee52a946e73503b1737f5...
An extended example (using the the modified keycloak-installed adapter) can
be found here:
https://gist.github.com/thomasdarimont/c59c14f45ea2ee00d7b6fbe2c013c5f1
WDYT?
Cheers,
Thomas
[0] Not mentioned here:
https://keycloak.gitbooks.io/documentation/securing_apps/topics/oidc/java...
[1] https://github.com/keycloak/keycloak/tree/master/adapters/oidc/installed
[2] For those that haven't seen the adapter yet, it allows to authenticate
against Keycloak
from a desktop app (e.g. swing, javafx) by opening a desktop browser window
where a user
uses the regular keycloak login pages to login.
The trick is now that login page is opened with redirect URL that points to
a small local
"web server" (server-socket) on a free ephemeral port which is started by
the adapter.
After logging in the mini web-server receives performs the authenorization
code flow and eventually receives the tokens (access_token, refresh_token,
id_token) which can then be
used to call backend services from the client or retrieve new tokens
A nice side effect of this is, that the desktop application never sees a
users
password and one can leverage existing SSO sessions.
Btw. the google cloud cli uses the same approach to authenticate with gcp.
The Keycloak repo contains a small example for this:
https://github.com/keycloak/keycloak/blob/master/examples/demo-template/c...
6 years, 11 months
offlineSessions data in cache vs db
by Tonnis Wildeboer
Hello Keycloak Devs,
[I posted this to keycloak-user, but got no response.]
Ultimately, what we want to do is migrate three nodes from one namespace
to another within a Kubernetes cluster as follows:
Start with three nodes in one Kubernetes namespace that define a
cluster. Then add three more nodes to the cluster in a new namespace
that shares the same subnet and database, then kill off the original
three nodes, effectively migrating the cluster to the new namespace and
we want to do all this without anyone being logged out. The namespace
distinction is invisible to Keycloak, as far as I can tell.
What we have tried:
* Start with 3 standalone-ha mode instances clustered with
JGroups/JDBC_PING.
* Set the number of cache owners for sessions to 6.
* Start the three new instances in the new Kubernetes namespace,
configured exactly the same as the first three - that is, same db, same
number of cache owners.
* Kill -9 the original three (I know now that it should be a kill -3,
but don't know if that matters in this case).
But it seems this caused offlineSession tokens to be expired immediately.
I found this in the online documentation
(http://www.keycloak.org/docs/latest/server_installation/index.html#server...):
> The second type of cache handles managing user sessions, offline
tokens, and keeping track of login failures... The data held in these
caches is temporary, in memory only, but is possibly replicated across
the cluster.
> The sessions, authenticationSessions, offlineSessions and
loginFailures caches are the only caches that may perform replication.
Entries are not replicated to every single node, but instead one or more
nodes is chosen as an owner of that data. If a node is not the owner of
a specific cache entry it queries the cluster to obtain it. What this
means for failover is that if all the nodes that own a piece of data go
down, that data is lost forever. By default, Keycloak only specifies one
owner for data. So if that one node goes down that data is lost. This
usually means that users will be logged out and will have to login again.
It appears, based on these documentation comments and our experience,
that the "source of truth" regarding offlineSessions is the data in the
"owner" caches, is NOT the database, as I would have expected. It also
seems to be the case that if a node joins the cluster (as defined by
JGroups/JDBC_PING), it will NOT be able to populate its offlineSessions
cache from the database, but must rely on replication from one of the
owner nodes.
Questions:
1. Is the above understanding regarding the db vs cache correct?
2. If so, please explain the design/reasoning behind this behavior.
Otherwise, please correct my understanding.
3. Is there a way to perform this simple migration without losing any
sessions?
Thanks,
--Tonnis
7 years
Better support authenticationSessions in multiple browser tabs
by Marek Posolda
I am looking at https://issues.jboss.org/browse/KEYCLOAK-5797 issue now.
It's about the fact, that when user has opened browser with multiple
browser tabs, then after successful login in tab1 (clientA), he may be
redirected to the incorrect client (clientB, which was opened in tab2).
The thing is, that authenticationSession was tracked by the cookie and
didn't support multiple clients. So both browser tabs "tab1" and "tab2"
used same authenticationSession, which can reference just one of the
clients, hence there could be the conflict and one of the tabs
redirected to incorrect client after authentication.
I am working on a fix, that allow better support for multiple clients.
What I am doing is, that there is "RootAuthenticationSessionModel",
which is now referenced by the ID from the cookie. That root session can
reference more actual authentication sessions through the map like
"Map<String, AuthenticationSessionModel>" . The key is the client UUID.
In the Authentication SPI, there are no changes. Those still use the
AuthenticationSessionModel as before.
This is easily possible as we have "client-id" parameter already
available during authentication flows in every tab. So every browser tab
can reference correct client and redirect to it.
However even with the fix, there is another corner case about support
for multiple browser tabs with *same* client. This will be still an
issue, especially for the javascript clients. I've created another JIRA
https://issues.jboss.org/browse/KEYCLOAK-5938 with the example issue,
which can be simulated with our admin console. To properly support
multiple tabs of same client, the key will need to be like: "client-id +
state" instead of just "client-id" The "state" will need to be either
the OIDC/SAML state or some randomly generated string (As in both the
OAuth2 and SAML, the state/relayState parameter is not mandatory AFAIK),
which will need to be added to the URL during authentication flows as well.
Fixing this will take me another few days of work (maybe 2?) as there
will need to be change in many files for adding the new parameter + some
more authenticationSession model changes etc. So I wonder if we want to:
1) Fix this in 3.4.1 . Will likely mean to delay the release?
2) Fix this in 3.4.2. It will affect many files and there is some chance
of regression (hopefully not big as we have lots of the tests for
various other corner cases)
3) Fix this later in 4.X .
My vote is 1 or 2. WDYT? Any other possibility?
Marek
7 years
Is there a way to log the details from ErrorResponseExceptions?
by Jared Blashka
Some of our clients are generating many REFRESH_TOKEN_ERROR events but I
don't see anywhere that the error description from the exception is
logged/stored. The keycloak event itself only says 'invalid token', but I'd
like to see the '{"error":"invalid_grant","error_description":"Session not
active"}' details as well to be able to provide specific guidance around
why their refresh calls are failing.
I tried registering an Exception Mapper provider, but it doesn't looks like
that's supported yet (
http://lists.jboss.org/pipermail/keycloak-dev/2016-June/007361.html).
We're running RH-SSO 7.1.3.
Thanks!
Jared Blashka
Red Hat
7 years
Importing big realms
by Buda, Mikolaj
Hi,
I've just created a tool that prepares a full backup of realm in json (the
same as during export at standalone startup). Sometime it is 60MB of data
(many users). Import process takes a long time. Do you have any ideas how
to speed up this process?
7 years
