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
Related
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
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.
I need to set up JBOSS EAP6 WebApp to integrate with Siteminder with IDP initiated SAML2 artifact binding.The current integration is using Form based header authentication. Siteminder is onPrem and JBOSS/App is in AWS. I have little visibility to the siteminder set up or it's requirement to integrate to JBOSS. I have a clarity on setting up the ServiceProvider in JBOSS for SSO and Single Log out with post binding.
My question are:
1. To integrate with an OnPrem Siteminder IDM, what components other than JBOSS and it's configurations are to be present in the server hosting JBOSS?
Something like a siteminder agent to be run in the server?
From a purely JBOSS perspective ,where does the JBOSS set up boundary starts?
I went through the net and could not find a conclusive list of components required to meet this integration.
2. Artifact binding is not supported by JBOSS EAP 6 per doc, so I must ask the IDM team to support SSO with post binding, correct?
Thank you in advance for your help.
You need to implemented your own JAAS security module. There is information on JBoss and CA websites on how to do this. This module will provide the authenication (user) and authorization (roles) to the applications deployed on JBoss. When developing I suggest setting the log level of org.jboss.security to trace.
It is picketlink that needs to be configured.Github has [examples][1]
[1]: https://github.com/jboss-developer/jboss-picketlink-quickstarts .
There is no need of siteminder agent if SP set up alone in the scope.
Also IDM team has to be requested to stick to POST Binding.
This covers the questions I asked.
On the Bluemix Liberty feature list, it says Spnego-1.0 is supported. Does anyone have any Bluemix documentation (not plain Liberty, because this would mean I installed the Liberty server on my own enterprise domain) on how to even begin to use this? It seems to me that if SPN are locked down to a domain name, how would this even work for an app running on a domain such as this: "www.ng.bluemix.net"?
Does this mean there is a requirement to have Bluemix infrastructure installed onto our enterprise infrastructure to even begin thinking about Spnego?
SPNEGO makes sense if you're trying to achieve SSO between say a Microsoft Desk Top and say a WASaaS (WAS or Liberty) running a web app in a Softlayer VM behind a private firewall, then a SPNEGO solution would work. In a more public setting, OpenID Connect should be considered as an option.
If SPNEGO really needs to be used, see the Liberty documentation. You can then customize a Liberty server.xml file in Bluemix to get this to work. To use a custom Liberty server.xml file, see the info noted under standalone applications.
As a security measure my organization requires me to validate a header attribute to allow a request to go through the business rules. Where would I need to configure this in the Jboss eap 6.3? This configuration was done before me and i am not sure how it was achieved before in the earlier jboss 5.x. Please let me know how would I configure the container security without making any application changes.
You could do this in a Global Valve, which is like a servlet filter but with more access to JBossWeb (Tomcat) internals and applies to all requests. Details are in the documentation at https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6.4/html/Administration_and_Configuration_Guide/chap-Global_Valves.html
That is not portable between containers, and will not work in WildFly or EAP 7+ since the web container has changed from JBossWeb to Undertow.
In my understanding, this has to be done in applications. Not sure if this can be done generally in JBoss configuration.
Try this https://www.owasp.org/index.php/How_to_add_validation_logic_to_HttpServletRequest
Turns out we had a different way of handling it. We used the single sign on feature of Jboss 5 and at the container level validated the header. When the header was validated, a generic role name was exposed which was used by Applications to limit the resources to the specific role name.