In standalone.xml I'd use "feature.scripts" sys properties instead of the
longer "keycloak.feature.scripts". It's just shorter and simpler and
won't
cause any conflicts.
We need to support the old
"keycloak.profile.feature.<featurename>=enabled|disabled"
as is, including if set in profile.properties. This is important in case
customers have explicitly disabled impersonation for example. +1 To
printing a warning in this case. Then let's remove the old deprecated
properties in Keycloak 3.5x as well as the profile.properties.
On 28 August 2017 at 15:57, Marko Strukelj <mstrukel(a)redhat.com> wrote:
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/profiles.html
[2]
https://issues.jboss.org/browse/KEYCLOAK-4994
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev