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, 8 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...
7 years
ProviderFactory::postDeploy?
by Dmitry
Hi,
At the moment, the ProviderFactory::postInit() method is not called
during hot (re)deployment of providers, only during server startup.
This is considered a bug (see discussion in keycloak-user, KEYCLOAK-
5131 and PR #4282).
Meanwhile, Marek and I have been discussing the problem of accessing
data model from postInit (see the keycloak-user post). Turns out that
the semantics should be significantly different depending on whether
postInit() is called during server startup or hot deploy. In the first
case, one should listen for PostMigrationEvent. In the second case, the
event is not available and thus shouldn't be listened for. However, the
provider should be able to somehow distinguish the cases. There are
some hacks like analyzing current thread name, querying JNDI or
Resteasy, but maybe we can come up with something more clean and
simple?
Marek has suggested that the new method should be introduced on the
ProviderFactory interface, with empty default implementation (in order
not to break the code). What do you think?
Dmitry
7 years, 1 month
Claims parameter support
by Aron Bustya
Hello!
I need the 'claims parameter' support in keycloak that has been thought
about in this jira ticket and postponed/rejected:
https://issues.jboss.org/browse/KEYCLOAK-3226
The proposed alternatives don't work for me, because I am implementing a
specification that explicitly requests data to be passed this way.
In addition to the JIRA above we also need to support passing the claims
parameter in the signed request object - not just as a separate query param.
I've solved the problem for our own use case by writing a ProtocolMapper
but some changes were also needed in the keycloak request parser (to
support the parsing of json objects from the request object - not just
strings).
The ProtocolMapper I've written doesn't support the whole claims parameter
feature though - it can only add the default value of the claim to the the
tokens.
I'm now trying to figure out how much of this code could be put back into
keycloak, and what needs to be changed to do so.
My goal would be to use an 'official' keycloak with cutomization only in
Service Providers and configuration.
Current code commit is here:
https://github.com/abustya/keycloak/commit/41fecf57a982ffdb9
6e210d8bd302d23fa7884da
What do you think about the direction of the development, does it make any
sense to put some of it back into keycloak?
Regards,
Áron Bustya
7 years, 2 months
Change in enabling / disabling features
by Marko Strukelj
This is a heads up about an upcoming change in how to enable or disable
features in Keycloak.
Keycloak has a notion of features, which makes it possible to disable
certain functionality that is enabled by default, or enable certain
functionality that is disabled by default.
There are four sets of functionality you can enable or disable as features:
impersonation, script, authorization, and docker. See [1] for more info.
Currently a file called profile.properties can be used to enable / disable
features, or system properties can be used, which override any
configuration inside profile.properties as explained in [1].
This is an aberration from how other configuration is specified on the
server via standalone.xml.
Also, the reason config file is called profile.properties, and not
features.properties is because the set of enabled/disabled features is
different for upstream project (where all but 'docker' are enabled), for
product based on Keycloak - RHSSO (where only 'impersonation' is enabled),
and for technology preview versions of RHSSO.
This additionally complicates things. The idea is to simplify that and
remove the notion of profiles, stop using profile.properties, and move all
configuration to standalone.xml where all the available features will be
listed with default values:
<subsystem xmlns="urn:jboss:domain:keycloak-server:1.1">
...
<features>
<feature name="authorization" enabled="true" />
<feature name="impersonation" enabled="true" />
<feature name="scripts" enabled="true" />
<feature name="docker" enabled="false" />
</features>
...
</subsystem>
This is how configuration would look like in Keycloak distribution. In
product distributions different features would be enabled / disabled - no
more named profiles.
However, in order to allow system properties override the idea is to do it
slightly differently:
<features>
<feature name="authorization"
enabled="${keycloak.feature.authorization:true}" />
<feature name="impersonation"
enabled="${keycloak.feature.impersonation:true}" />
<feature name="scripts" enabled="${keycloak.feature.scripts:true}" />
<feature name="docker" enabled="${keycloak.feature.docker:false}" />
</features>
We should probably also facilitate transition for current deployments, and
take old style system properties into account if they are used - converting
them to the new ones before configuration is applied.
Deprecated: -Dkeycloak.profile.feature.impersonation=enabled
New style: -Dkeycloak.feature.impersonation=true
We don't want to keep support for this indefinitely (maybe for one minor
version?) so if use of deprecated system properties is detected a warning
will be logged.
Also, Stian proposed that features not considered stable yet, should carry
a suffix '-preview' in the name. So the actual feature name, and system
property name may still change for some features.
You can follow progress on JIRA issue [2].
-
[1]
https://keycloak.gitbooks.io/documentation/server_installation/topics/pro...
[2] https://issues.jboss.org/browse/KEYCLOAK-4994
7 years, 3 months
regarding expired sessions and token life-span
by Kishan Sagathiya
Hi,
I am trying to figure out how Keycloak deals with expired sessions and how
token lifespan affects Keycloak database size and performance.
But I dont understand the directory structure and where to find the
relevant code.
If someone could give some pointers regarding this that would be great
Thanks :)
-Kishan Sagathiya
7 years, 3 months
KEYCLOAK-5032 - Implementation question
by carl-kristian.eriksen＠telia.no
https://issues.jboss.org/browse/KEYCLOAK-5032 describes two requested query parameters: acr_values and nonce
Our requirements are for acr_values and prompt, and I’m working on a pull request for these two.
How many pull requests do you want?
Should I make sure that (each)PR includes support for one, two or three query parameters
Can the “prompt” parameter be added to KEYCLOAK-5032, or do I need another Jira task for the “prompt” parameter?
Br / mvh
Carl Kristian Eriksen
t: +47 95147848
VEGA / GDPR / Access Management Infrastructure
Telia Norge AS
7 years, 3 months
Allow additional attributes to be pushed into Freemarker templates (login and account themes) by extension developers
by Vlastimil Elias
Hi,
I was asked by Stian to post my proposal around
https://issues.jboss.org/browse/KEYCLOAK-2671 to be discussed here with
wider KC dev team.
What we need is to pass some additional attributes into Login and
Account freemarker templates as part of our extensions - eg. to
configure client side validations for registration form based on actual
authentication session. Other use case we need is selection of Theme
based on calling client.
There are already Login and Account Form providers which may be
customized (they are SPI), only problem is that current Freemarker
providers use private fields and methods, so it is hard to customize
them (I have to copy complete code which is hardly maintainable during
keycloak upgrades).
I believe we should resolve the problem by small refactoring of existing
FreeMarkerLoginProvider and FreeMarkerAccountProvider providers similar
you already done in FreeMarkerEmailTemplateProvider. So things like:
* change fields and methods from private to protected to allow
use/override in subclasses
* refactor some features to protected methods (eg. Template loading
from template provider - again, you did it in
FreeMarkerEmailTemplateProvider provider already) to allow override
in subclasses
* add one protected callback method called just before template and
attributes are passed to the freemarker engine for the processing -
this allow subclass simply add additional attributes to be passed
into template
Only bigger change (and blocker for one of our important features) is
passing of current AuthenticationSessionModel to the LoginFormsProvider
instance at all places where the form provider is called. This is really
missing now to be able customize GUI based on current client and
authentication flow needs.
I don't think those are big changes, but they will make life of
extension developers much easier.
I believe I'm able to provide pull request for this change if no better
solution will be found there by experienced KC dev team.
Thanks a lot in advance for any comments to my proposal.
Vlastimil
--
Vlastimil Elias
Principal Software Engineer, Middleware Engineering Services
Red Hat
7 years, 3 months
Single-use cache for OAuth code, Code changed to be JWE
by Marek Posolda
I've sent PR https://github.com/keycloak/keycloak/pull/4512, which
implements first part of
https://docs.google.com/document/d/1C1vFhyGPBOnN3pprw6XPZnK08azyTm-HVIqO9...
Some details:
- Partially implemented support for JWE, so we can use encrypted JWT.
- OAuth code is changed to be JWT. It's encrypted and
integrity-protected with AES128-CBC-HMAC-SHA256 algorithm. Code is
encrypted with realm AES key (new symmetric key generated by default for
every realm similar to HMAC key) and signed with HMAC key.
- I've added support for AES keys, so we now have RSA, HMAC and AES keys.
- Code JWT doesn't yet contain much at this moment. There is just unique
ID, userSession ID, client UUID and expiration (60 seconds). Next step
is to add more into it, especially notes as mentioned in the docs.
- Single-use cache is used to track which codes were already used. For
now, it's reusing existing "actionTokens" infinispan cache. It's using
"putIfAbsent" to add codes into the cache, hence now we are sure that
the particular code is really used just once. The previous approach with
the note on userSession didn't allow this. I've added new testcase to
ConcurrentLoginTest for check that code is used just once. It's passing
for cross-dc as well, however we may allow people to save some
performance with the small possibility that same code will pass on both
datacenters.
- Now we also pass the scenario when SSO login with same client is
opened on 2 browser tabs concurrently. Also added test to
ConcurrentLoginTest and it's passing for cross-dc too. Previously this
scenario may not work correctly as the "code" in the clientSession note
may be generated concurrently by both requests and one of them will then
fail to verify.
Next steps:
- Continue with the stuff described in the docs
https://docs.google.com/document/d/1C1vFhyGPBOnN3pprw6XPZnK08azyTm-HVIqO9...
(Remove protocolMappers and roles from clientSession etc).
- It should be easy to use same stuff for refreshTokens . From what I
see, the performance of AES128-CBC-HMAC-SHA256 is much better than RSA
and provides the encryption too.
Any comments?
Marek
7 years, 3 months
