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, 11 months
Current server distribution build broken?
by Thomas Darimont
Hello,
I cannot build a working keycloak server distribution from current master
(7774d5c6b8) with:
mvn clean install -Pdistribution -DskipTests
When I try to run the keycloak server-distribution, I see an exception:
WFLYCTL0083: Failed to load module org.keycloak.keycloak-server-subsystem
....
00:01:29,788 INFO [org.jboss.as.controller] (Controller Boot Thread)
OPVDX002: Failed to pretty print validation error: null
00:01:29,789 ERROR [org.jboss.as.server] (Controller Boot Thread)
WFLYSRV0055: Caught exception during boot:
org.jboss.as.controller.persistence.ConfigurationPersistenceException:
WFLYCTL0085: Failed to parse configuration
at
org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:143)
[wildfly-controller-3.0.1.Final.jar:3.0.1.Final]
at org.jboss.as.server.ServerService.boot(ServerService.java:387)
[wildfly-server-3.0.1.Final.jar:3.0.1.Final]
at
org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:370)
[wildfly-controller-3.0.1.Final.jar:3.0.1.Final]
at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_144]
Caused by: javax.xml.stream.XMLStreamException: WFLYCTL0083: Failed to load
module org.keycloak.keycloak-server-subsystem
at
org.jboss.as.controller.parsing.ExtensionXml.parseExtensions(ExtensionXml.java:154)
[wildfly-controller-3.0.1.Final.jar:3.0.1.Final]
at
org.jboss.as.server.parsing.StandaloneXml$DefaultExtensionHandler.parseExtensions(StandaloneXit
ml.java:131) [wildfly-server-3.0.1.Final.jar:3.0.1.Final]
at
org.jboss.as.server.parsing.StandaloneXml_5.readServerElement(StandaloneXml_5.java:219)
[wildfly-server-3.0.1.Final.jar:3.0.1.Final]
at
org.jboss.as.server.parsing.StandaloneXml_5.readElement(StandaloneXml_5.java:142)
[wildfly-server-3.0.1.Final.jar:3.0.1.Final]
at
org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107)
[wildfly-server-3.0.1.Final.jar:3.0.1.Final]
at
org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:49)
[wildfly-server-3.0.1.Final.jar:3.0.1.Final]
at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:122)
[staxmapper-1.3.0.Final.jar:1.3.0.Final]
at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:76)
[staxmapper-1.3.0.Final.jar:1.3.0.Final]
at
org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:126)
[wildfly-controller-3.0.1.Final.jar:3.0.1.Final]
... 3 more
Caused by: java.util.concurrent.ExecutionException:
javax.xml.stream.XMLStreamException: WFLYCTL0083: Failed to load module
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
[rt.jar:1.8.0_144]
at java.util.concurrent.FutureTask.get(FutureTask.java:192)
[rt.jar:1.8.0_144]
at
org.jboss.as.controller.parsing.ExtensionXml.parseExtensions(ExtensionXml.java:146)
[wildfly-controller-3.0.1.Final.jar:3.0.1.Final]
... 11 more
Caused by: javax.xml.stream.XMLStreamException: WFLYCTL0083: Failed to load
module
at
org.jboss.as.controller.parsing.ExtensionXml.loadModule(ExtensionXml.java:195)
[wildfly-controller-3.0.1.Final.jar:3.0.1.Final]
at
org.jboss.as.controller.parsing.ExtensionXml.access$000(ExtensionXml.java:68)
[wildfly-controller-3.0.1.Final.jar:3.0.1.Final]
at
org.jboss.as.controller.parsing.ExtensionXml$1.call(ExtensionXml.java:126)
[wildfly-controller-3.0.1.Final.jar:3.0.1.Final]
at
org.jboss.as.controller.parsing.ExtensionXml$1.call(ExtensionXml.java:123)
[wildfly-controller-3.0.1.Final.jar:3.0.1.Final]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
[rt.jar:1.8.0_144]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[rt.jar:1.8.0_144]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[rt.jar:1.8.0_144]
at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_144]
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
[jboss-threads-2.2.1.Final.jar:2.2.1.Final]
Caused by: org.jboss.modules.ModuleNotFoundException:
org.keycloak.keycloak-server-subsystem
at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:285)
[jboss-modules.jar:1.6.0.Final]
at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:271)
[jboss-modules.jar:1.6.0.Final]
at
org.jboss.as.controller.parsing.ExtensionXml.loadModule(ExtensionXml.java:177)
[wildfly-controller-3.0.1.Final.jar:3.0.1.Final]
... 8 more
00:01:29,791 FATAL [org.jboss.as.server] (Controller Boot Thread)
WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting.
See previous messages for details.
00:01:29,804 INFO [org.jboss.as] (MSC service thread 1-7) WFLYSRV0050:
WildFly Core 3.0.1.Final "Kenny" stopped in 8ms
....
Cheers,
Thomas
7 years, 11 months
Re: [keycloak-dev] Atlassian (Jira, Confluence) SSO adapters for OIDC/Keycloak
by Vlastimil Elias
Hi,
On 6.10.2017 06:43, Stian Thorgersen wrote:
> Do they really need separate adapters? I would have thought Atlassian
> would be smart enough to let you write one auth plugin for all.
They have some common frameworks around auth and user management like
Seraph and Crowd-Embedded used in most of their products, but there are
still some differences in some areas (as some atlassian products are
from acquisitions so not totally same internally). Sometimes even new
version of one product requires changed implementation. My intention is
to create common base for the adapter, and then as tiny special wrappers
for distinct products/versions as possible.
>
> Would be good to have this in Keycloak for sure. I can add a repo for
> you and make you admin of the repo. Does keycloak-atlassian-plugin
> sound right? We already have one for Jenkins
> (https://github.com/keycloak/jenkins-keycloak-plugin) although I have
> no clue what state it is in.
If you can create the repo now and let me work in it then cool,
keycloak-atlassian-plugin name works for me. I'll use same OSS License
as Keycloak for this code.
Thanks
Vlastimil
>
> On Thu, Oct 5, 2017 at 2:55 PM, Vlastimil Elias <velias(a)redhat.com> wrote:
>> Hi, I'm going to implement OIDC/Keycloak SSO adapters for Atlassian
>> SW like Jira or Confluence, starting with Jira first. My intention is
>> to have full SSO integration there, so keycloak will be used for all
>> logins to Jira (jira login page not used in any way), and even
>> automatic login on first jira visit if user has SSO session in
>> keycloak already. I wrote similar stuff for CAS protocol so I believe
>> it is possible to implement it. Do you think a repo for these
>> adapters (one shared for all of them) should be hosted in
>> https://github.com/keycloak organization? Or should I implement them
>> in independent repo first and move under keycloak org later if my
>> implementation will be worth it? I plan to use OIDC adapter from
>> keycloak project for my implementation, but my intention is to write
>> them as universal OIDC adapters, not bound to Keycloak SSO server
>> itself. Vlastimil
>> --
>> Vlastimil Elias Principal Software Engineer, Middleware Engineering
>> Services Red Hat _______________________________________________
>> keycloak-dev mailing list keycloak-dev(a)lists.jboss.org
>> <mailto:keycloak-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Vlastimil Elias
Principal Software Engineer, Middleware Engineering Services
Red Hat
7 years, 11 months
Re: [keycloak-dev] Atlassian (Jira, Confluence) SSO adapters for OIDC/Keycloak
by Stian Thorgersen
Do they really need separate adapters? I would have thought Atlassian
would be smart enough to let you write one auth plugin for all.
Would be good to have this in Keycloak for sure. I can add a repo for
you and make you admin of the repo. Does keycloak-atlassian-plugin
sound right? We already have one for Jenkins
(https://github.com/keycloak/jenkins-keycloak-plugin) although I have
no clue what state it is in.
On Fri, Oct 6, 2017 at 6:43 AM, Stian Thorgersen <sthorger(a)redhat.com>
wrote:
> Do they really need separate adapters? I would have thought Atlassian
> would be smart enough to let you write one auth plugin for all.
>
> Would be good to have this in Keycloak for sure. I can add a repo for
> you and make you admin of the repo. Does keycloak-atlassian-plugin
> sound right? We already have one for Jenkins
> (https://github.com/keycloak/jenkins-keycloak-plugin) although I have
> no clue what state it is in.
>
> On Thu, Oct 5, 2017 at 2:55 PM, Vlastimil Elias <velias(a)redhat.com>
> wrote:
>> Hi,
>>
>> I'm going to implement OIDC/Keycloak SSO adapters for Atlassian SW
>> like
>> Jira or Confluence, starting with Jira first.
>>
>> My intention is to have full SSO integration there, so keycloak will
>> be
>> used for all logins to Jira (jira login page not used in any way),
>> and
>> even automatic login on first jira visit if user has SSO session in
>> keycloak already. I wrote similar stuff for CAS protocol so I
>> believe it
>> is possible to implement it.
>>
>> Do you think a repo for these adapters (one shared for all of them)
>> should be hosted in https://github.com/keycloak organization? Or
>> should
>> I implement them in independent repo first and move under keycloak
>> org
>> later if my implementation will be worth it?
>>
>> I plan to use OIDC adapter from keycloak project for my
>> implementation,
>> but my intention is to write them as universal OIDC adapters, not
>> bound
>> to Keycloak SSO server itself.
>>
>> Vlastimil
>>
>>
>> --
>> Vlastimil Elias
>> Principal Software Engineer, Middleware Engineering Services
>> Red Hat
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
7 years, 11 months
Update to 3.4 release dates
by Stian Thorgersen
Update release dates:
* 16 October - Feature freeze! Only bug fixes after this point please
* 30 October - 3.4.0.CR1
* 6 November - 3.4.0.Final
* 20 November - 3.4.1.Final
* Mid December - master switches to 4.x
Community contribution deadlines for 3.x:
* 12 October - deadline for feature requests and bigger enhancements
* 26 October - deadline for small enhancements
* 1 November - deadline for bug fixes
Anything contributed after these dates will most likely not be
reviewed/merged until 4.x
7 years, 11 months
Atlassian (Jira, Confluence) SSO adapters for OIDC/Keycloak
by Vlastimil Elias
Hi,
I'm going to implement OIDC/Keycloak SSO adapters for Atlassian SW like
Jira or Confluence, starting with Jira first.
My intention is to have full SSO integration there, so keycloak will be
used for all logins to Jira (jira login page not used in any way), and
even automatic login on first jira visit if user has SSO session in
keycloak already. I wrote similar stuff for CAS protocol so I believe it
is possible to implement it.
Do you think a repo for these adapters (one shared for all of them)
should be hosted in https://github.com/keycloak organization? Or should
I implement them in independent repo first and move under keycloak org
later if my implementation will be worth it?
I plan to use OIDC adapter from keycloak project for my implementation,
but my intention is to write them as universal OIDC adapters, not bound
to Keycloak SSO server itself.
Vlastimil
--
Vlastimil Elias
Principal Software Engineer, Middleware Engineering Services
Red Hat
7 years, 11 months
Concurrency & EventsListener SPI
by Poiffaut Romain
Hi,
I am writing a provider for eventsListener SPI.
Could anyone tell me if the provider and its provider factory need to be thread safe ?
With more details, I need to store some events. To do so, I am using a collection created by the factory and a reference to this collection is passed to the constructor to update it.
Does my collection needs to be concurrency-safe or is it not needed?
Best regards,
Romain
7 years, 11 months
Keycloak Website Updates - Security section
by Bruno Oliveira
Good morning,
Today, we sometimes have people disclosing vulnerabilities at
the public mailing list. And later, they will find out that
there's a process to report it.
Now that we have the keycloak-security ML, I would like to suggest to make
such process evident into our website.
It's a common practice to have a "/security" path into your website. We
could do the same just creating an HTML and extracting the content from:
https://github.com/keycloak/keycloak.github.io/blob/master/community.html....
And of course, adding more details about how to do it.
Also, I would like to add it to the main page. That could be
done by replacing "Source" into the main menu with "Security".
"Source" is already referenced inside "Community" page,
people will figure out where to get the sources.
Does anything make sense?
--
abstractj
7 years, 11 months
Make built-in themes read/write
by Stian Thorgersen
Currently the built-in themes are read-only to prevent people from
modifying them as they should create a custom theme to override instead.
The problem is that read-only files is causing an issue with patching in
RH-SSO.
The simplest solution would be to just change the files to read/write.
7 years, 11 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, 11 months
