I have two sub-flows set up as follows:
Subflow 1 - Alternative
Execution 1 - Required
Subflow 2 - Alternative
Execution 2 - Required
Execution 1 is runs a custom authenticator that does the following:
1. Issues a challenge
2. Returns ATTEMPTED status
The resulting behaviour is that the whole flow fails. I was expecting a jump to Subflow 2, which is what happens if the authenticator returns ATTEMPTED without first issuing a challenge. Is this a bug? I thought that perhaps REQUIRED might apply to the whole flow rather than to a particular sub-flow, but I couldn't find an explicit clarification in the documentation. However, this scenario was mentioned in passing on this list before:
The behaviour seems to originate in `org.keycloak.authentication.DefaultAuthenticationFlow.processResult`.
This email (including any attachments) contains information which is confidential and may be subject to legal privilege. If you are not the intended recipient you must not use, distribute or copy this email. If you have received this email in error please notify the
sender immediately and delete this email. Any views expressed in this email are not necessarily the views of IRESS Limited.
It is the duty of the recipient to virus scan and otherwise test the information provided before loading onto any computer system.
IRESS Limited does not warrant that the information is free of a virus or any other defect or error.
Keycloak, Node.js and documentation are all forked for 7.2. It's to late to
update code now unless it's a blocker for the release. In that case let me
know asap. For documentation we can update, but that means PR to master and
7.2.x branch in private repo. Any docs changes to 7.2 has to be approved by
Matthew and Pavel prior to merging.
Master (except quickstarts, see below) is open for 4.x development. One
thing to note here is that we have now started the review process so all
PRs have to be reviewed. The general rule one jira, one commit and one PR
applies. Also, only complete work including test and docs should be
For quickstarts master is still aiming 7.2. So send changes to master. If
it's only for 4.x hold off for now! Same rule applies any changes to
quickstarts now need approval of me and Pavel before merging.
I'm considering deployement of Keycloak serving as an OAuth2 / Open ID
provider for users managed in multiple MS Active Directory and Active
Directory Lightweight services. For internal desktop users Kerberos should
be used to prevent credentials re-entry following log-on to domain-joined
The tricky part is that usernames are considered to be unique only withing
single AD domain, so username 'godlewsm' can exists both in Kerberos realm
ACMEPL.LOCAL AND ACMECZ.LOCAL. For LDAP storage provider (
there is assumption that only username part of principal name would be used
further, which prevents distinguishing accounts properly.
Is there plan to change this behaviour or the only way would be implement a
custom UserStorageProvider based on LDAPStorageProvider ?
and when it is done a Windows Defender's popup alerts about a Trojan inside.
Windows Defender info:
adapter file: keycloak-js-adapter-dist-3.4.2.Final.zip
trojan name: Trojan:JS/Jorv.A!cl
Am I the only one with this problem?
I may have found a bug (or lack of feature?) in the proxy. I'm running the
proxy behind a AWS load balancer which is handling HTTPS but the redirect
urls that the proxy is generating are HTTP.
While this isn't blocking usage as HTTP is redirected to HTTPS it is a
small security hole that I would like to close.
Is this something wrong with the proxy, a feature that needs to be worked
on or out of scope of the proxy all together and I should be asking another
I played a bit with the undocumented?  keycloak-installed adapter 
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
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
- Provide customizable response templates (perhaps by leveraging a provided
- Allow to customize pages shown after login / logout served by the
- 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
redirect to the local mini-webserver after a successful login since the
(...server-socket) embedded in the adapter doesn't respond with a valid
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:
An extended example (using the the modified keycloak-installed adapter) can
be found here:
 Not mentioned here:
 For those that haven't seen the adapter yet, it allows to authenticate
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
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
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:
Our backup product is using Keycloak for SSO. We are migrating all our users to a new instance of keycloak in AWS environment. One of the requirement is all the existing clients which is an agent on the user box running in background which does backup, should not see any re-authentication or login window from their end after migration . User initially login when they have first installed our product and they never see any login any more(our client is non-intrusive, most users don't ever remember the login ), we just refresh every 15 minutes get new set of tokens and so on... and it works for us. We have tested locally where we have migrated the present keycloak database to our new keycloak aws instance just by using pg_dump and restore command for database of keycloak and we made sure the realm, redirect urls , client secrets are exactly same. We are assuming if everything is exactly the same refresh tokens should still workand we can avoid the login screen. Is this right assumption?
In our test what we have found is, we made a DNS swap where the client initially going the old env gets routed to our new keycloak aws instance(We did CNAME change on the old env to route traffic to new environment ). The reason for this Is to make sure our redirect url does not change and the client could still talk to same old urls it is aware of. Long story short, old key cloak env and new key cloak env has exactly same of everything...What we have seen is that the client which is initalliay pointing to the old env, after the migration and after doing the DNS switch the old tokens still work on new environment. Once we remove the switch and when the clients go back to old env the tokens still work. Is this a bug or is this expected?