All over the internet CVE-2022-34169, this vulnerability is popping up now.
The older Keycloak (JBoss server) and many other applications are heavily using xalan jar and it is dependent on many other libraries.
Does anyone know how to fix or remediate this vulnerability?
Here is some example of how Keycloak and other library is dependent on this.
Keycloak/modules/system/layers/base/com/sun/jsf-impl/main/module.xml
Keycloak/modules/system/layers/base/org/apache/santuario/xmlsec/main/module.xml
Keycloak/modules/system/layers/base/org/apache/xalan/main/xalan-2.7.2.jar
Keycloak/modules/system/layers/base/org/jboss/as/jdr/main/module.xml
Keycloak/modules/system/layers/base/org/jboss/as/standalone/main/module.xml
Keycloak/docs/licenses/full-feature-pack-licenses.html
Keycloak/docs/licenses/full-feature-pack-licenses.xml
Keycloak/modules/system/layers/base/org/apache/ws/security/main/module.xml
Keycloak/modules/system/layers/base/org/apache/xalan/main/module.xml
Keycloak/modules/system/layers/base/javax/servlet/jstl/api/main/module.xml
Keycloak/modules/system/layers/base/org/jboss/as/host-controller/main/module.xml
Keycloak/modules/system/layers/base/org/jboss/as/webservices/server/integration/main/module.xml
Keycloak/modules/system/layers/base/org/jboss/as/cli/main/module.xml
Keycloak/modules/system/layers/base/org/jboss/as/appclient/main/module.xml
Keycloak/modules/system/layers/base/org/wildfly/bootable-jar/main/module.xml
Keycloak/modules/system/layers/base/org/jboss/as/server/main/module.xml
Related
What is meaning of (https://www.keycloak.org/archive/downloads-17.0.1.html)
Keycloak: Distribution powered by Quarkus
Keycloak WildFly (deprecated): Distribution powered by WildFly
When i see documentation it says:
The default distribution of Keycloak is now powered by Quarkus, which brings a number
of breaking changes to you configure Keycloak and deploy custom providers.
For more information check out the Quarkus Migration Guide.
The WildFly distribution of Keycloak is now deprecated, with support ending June 2022.
We recommend migrating to the Quarkus distribution as soon as possible.
However, if you need to remain on the legacy WildFly distribution for some time,
there are some changes to consider
I am using Wildfly as application Server where projects are deployed.
Shall this means i use Wildfly distribution of Keycloak only whose support is ending June 2022.
or
Does this mean that Keycloak use Wildfly underneath and not use that anymore and quarkus is used? (now here can quarkus distribution work fine with wildfly settings we currently have)
Unfortunately, it has nothing to do with WildFly anymore. Until recent versions, the Keycloak was being packaged as a Java EE archive file (or as WildFly module) that you could deploy into WildFly application server.
Quarkus on the other hand is a framework to develop cloud native Java applications. It's runtime relies on many open source projects for underlying services (e.g. Vertx, SmallRye projects, etc.) and has a completely different architecture. As part of such a migration, Keycloak is now being packaged as an standalone java application (that is a typical output for an app developed using Quarkus) and contains all its dependencies. So there is no deployment/installation on WildFly anymore.
Quarkus applications are being designed by default to be run on cloud environments like Kubernetes. So you may also require to consider if you can benefit from this if you have such an infrastructure in your organization (however it's not mandatory and you can just run it as a normal java app on your server). But you can definitely not use your WildFly specific configurations (e.g. the Keycloak subsystem or OpenID subsystem) anymore.
You can find more details here.
Quarkus is a variation of Wildfly that is packaged in such a way as to make containerization (i.e. Docker, Kubernetes, etc.) much easier. Applications written for Wildfly (and JEE in general) can be made to run in Quarkus quickly.
Wildfy 25 and above include OIDC functionality internally. Therefore, you don't need to install the Keycloak extensions like you used to. And Keycloak, as of version 15, is based on Quarkus too. Because of this there is a build phase of the installation that lets you set many of the options before the run phase. For example, I used to setup a data source in the standalone.xml for my database. Now, I use the resources.properties to setup my database for Keycloak. The concepts are similar.
If you're using a version of Wildfly less than 25 then you'll still want the Keycloak adapter.
We are a Java shop and use maven. Our app is on wildfly 18. Does anyone have any experiences on migrating a wildfly app to OIDC? We were given a security library that we can use to make OIDC calls to, but it requires a config file co-located with this library. Do we need to use a module for this? If so, do we need a particular section filled out in our standalone.xml?
You asked about Wildfly 18. This one for sure needs add-on modules, such as those provided by the keycloak project (https://www.keycloak.org/downloads).
Since Wildfly 25 the OpenID Connect functionality was added to the Wildfly releases, and since then the addon modules are no longer required. In fact, they should no longer get installed as they seem to break Wildfly.
See also
Secure WebApp in Wildfly 25 using OpenID Connect (OIDC) without installing a Keycloak client adapter
https://docs.wildfly.org/25/WildFly_Elytron_Security.html#validating-jwt-tokens
https://www.youtube.com/watch?v=2gQO4_7Z5CI
My organization has decided to use Drools as a decision management framework. We are using the new UI business-central which is deployed as a WAR file in WildFly server for managing the rules and the assets related to the rules.
We have licensed Gsuite for our emails and other activities. We want to use Google login for the users of the business-central system instead of the username and password-based auth provided.
One way to do it is by using a Keycloak server which will provide us a way to manage users and authentication. But we do not want to maintain an extra server just for authentication.
Can someone please help me in achieving this authentication? Also, it would be helpful if I can know in advance the pitfalls of such a type of authentication approach.
Here are the version details for the drools system:
Java: openjdk version "1.8.0_242"
Drools: 7.33.0.Final
After doing a lot of trial and error and quite a bit of googling around. I have reached the conclusion that providing social login in business-central should be done via Keycloak if you are using Wildfly.
There are a lot of security-related features that you will get out of the box and you won't have to tweak around the drools code and later on finding out that you have missed a use case.
We could see JBI in Glassfish V2 but it is not in V3, what's happening? Which application server is useful for SOA development?
can I deploy WSO2 on Glassfish or JBoss?
RGDS
I'm not sure this answer is definitive, just based on my own experience with these systems.
JBI isn't a Glassfish feature (if it ever was its news to me). Its a (kinda/sorta) Sun community standard which has many implementations (ServiceMix to name one of several) that can be installed on any J2EE container (such as Glassfish to name one). Although it was once very popular it seems to have fallen on hard times of late, perhaps simply because ESB hype got swamped by the new wave of cloud hype.
WSO2 is much larger and includes JBI as one of its many options. By default its based on its own embedded Tomcat, but WSO2 claims its possible to run it on an external Tomcat (I never managed to make this work). To my knowledge no one has tried or succeeded to make it work on Glassfish.
I need to use some EJBs which are deployed on JBoss version 4.x from another EJB deployed on JBoss version 3.2.x. Is this possible?
I ask because I have a third party application which uses some strange bridge's to do that and don't know why (though I haven't try to do this on my own).
This is unfortunately not possible. One of the major drawbacks of remote EJBs is that there is nothing in the specification that guarantees or even suggests any kind of interoperability between different vendors or between different EJB versions from the same vendor.
In practice I found that at least with JBoss AS it never works. Even minor upgrades break binary compatibility completely. There have been some very hacky attempts with special class loaders that are only been given access to the client libs of the target JBoss AS, but this is very tricky to get right.
I guess this "strange bridge" you are talking about is using such a trick. Kudos to whoever build that bridge for getting this to work at all.
See this topic I started on the JBoss community forum for some more details: http://community.jboss.org/message/587180