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.
Related
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
I have a 4 applications running on my jboss server, i want to disable "X-PoweredBy" header response for particular application.
if i run the shell script and try to change it, it will be applicable for all the instances on the server.
How do i do it for one application alone ?
Try to create a servlet filter for the application you are interested! To be specific, you must call HttpServletResponse#setHeader(name, value) or the HttpServletResponse#addHeader(name, value). Bear in mind that this can not override the header added by the web container but this can add the header if the web container does not add the same header.
I'm writing a REST server using Jersey for Tomcat. I'm proficient in Java but this is my first time writing for web, so I hope this question isn't dumb. I've tried searching all over but can't come up with an answer I understand well.
I'm trying to utilize HTTPS and basic auth, but I don't know if I have to write anything in the actual Java to accomplish this. Does Tomcat take care of all encryption/decryption of SSL info, or do I have to do something in my server code to take care of this? In the client I know I will have do this manually, but I can't find anything about how to do this on the server end. Is it a Tomcat setting? Do I have to set Tomcat to only forward HTTPS traffic to my server, and then it will decrypt and send the decrypted information to my server, where it will act just as though it was a regular unencrypted command?
For the server, you first need to make sure Tomcat is configured to support HTTPS/SSL/TLS. This includes setting up the keystore and editing a configuration file. You can see all the details of how to do that at SSL/TLS Configuration HOW-TO. Note that link is for Tomcat 8. For Tomcat 7, you should search for the according docs.
Once you have that set up, all there is left to do to actually make use the HTTPS, is to set the <transport> to CONFIDENTIAL in the web.xml file of your web application.
<security-constraint>
...
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
If you have never set up the web.xml seucurity yet, then you'll want take time to read Securing Web Applications. There is also a section on setting up Basic auth with web.xml configuration.
When you get the section about Basic auth, you will notice a configuration of <realm-name>. The realm is something that needs to be set up with Tomcat. This is basically the access point to the store of users that Tomcat will lookup the authenticate. To read more about setting up a realm, see Realm Configuration HOW-TO (again this is a Tomcat 8 link). There different types of realms to choose from, so just pick one, like the JDBC realm.
And that's it. Rather than give a tutorial, I think the links I provided are goods officials sources that will do a better job at explaining than I could do. If this is all new to you, it might take you a day to set everything up, but I'm sure you will learn a lot from those documentations.
Another thing, if you want to do authorization, once you set up the realm in tomcat with roles (see example in JDBC realm section), you can either use the roles authorization configuration in the web.xml (see "Securing Web Applications" link) or you can use Jersey's role based authorization, which will give a little more fine control. For that see Authorization - securing resources
I'm trying to find the best way to grammatically determine if my program is running on Jboss 5 or Jboss 7 (eap-6.1). The ways I've been finding so far are jboss 5 or jboss 7 specific, which doesn't work because the code has to work in both. Tried both solutions from here: How do I programmatically obtain the version in JBoss AS 5.1? and they didn't work. One complained about org.jboss.Main not existing in jboss 7, the other complained aobut not finidng "jmx/rmi/RMIAdaptor".
The only way I can see is to do Class.forName to look for "org.jboss.Version" (should be found if jboss 5) and if that fails, do Class.forName "org.jboss.util.xml.catalog.Version" (jboss 7). But that seems like a terrible idea.
The reason I need to know if the war is running on jboss 5 or 7 is because there are some custom files that are located in different places in both. So it's like "if jboss 5, execute this piece of code, if jboss 7 execute the other.
Ok i just saw what the problem is.
I would suggest you to think about design issues/refactoring of your software.
If you want to provide your software within different environments, seperate your logic from
technology dependencies.
Build facedes and interfaces to meet environmental requironments.
In my oppionen thats much better as to think we must support all integration platforms and support all there versions. This is completely impossible.
So decouple your business logic and offer specific interfaces. These interfaces (adapters) are much simplier to implement and to maintain.
Hope it helps.
UPDATE DUE TO COMMENT.
I think a solution is for servers 4 to 6 is to use
the MBean Server of JBoss to lookup the registered web application
which is associated to the deployed WarFile.
I suggest first to lookup the registered MBean of the web application manually using the JBoss jmx-console. The name of the WebApplication should be found under the capital "web" or "web-deployment" within the jmx-console.
If you found that name you can implement an own jmx based lookup mechanism
to check for that name.
Here is an Tutorial: pretty old but i think it gives you an idea how to do.
There must be more tutorials for this problem:
http://www.theserverside.com/news/1364648/Using-JMX-to-Manage-Web-Applications
Within JBoss 7 i just can give you the hint that its architecture is based on OSGI. So to lookup for other services you should have a look to this mechanism.
In any case you don't have direct access to the file system and the deployment directory
from an application which is deployed within a JEE container, except of
using the mechanisms provided by the container. JNDI Lookup, JMX ManagedBean mechanism, Java Connector Archicture (JCA) (makes no sense in your case)
It's not an answer just an suggestions since the implementations are completely different
One way could be to use the "interceptors" which are executed during bootstrap and before any ejb invocation and there you have access to the invocation context in other words ejb container.
I can't give you any example but this would be an access point to start.
Another accesspoint is to check for system wide JMX Beans by looking through the
Adminstratore console of the JBoss Server.
You can inject JMX Bean state into your application through the Context Mechansim.
Take a look from Version 4 to 6 at the JMX Managed Bean mechanism. The JMX Achitecture is the main concept of JBoss 3 to 6, so at this point you can influence and maintain the JBoss behaviour.
Aditionally i think you have differences from 4 to 6.x version and 7.0 because since
7 it's a completely new architecture. Since 7.0 the JMX architecture doens't exists anymore.
we are migrating one application from JBoss AS 6 to 7.
This new instance is useing the standalone-ha profile. On the previous version, we used a custom Infinispan loader which stored the cache entries into our custom database.
Now, on JBoss 7.1, when trying to change this configuration using the visual administration console, it don't work. The value that we type on the tab "Store Class Impl" on "Replicated caches" is not being stored on the profile configuration as it should be. So, here is my question: is it possible to change this configuration using xml? How can I configure this custom loader for our replicated caches? Does anyone here ever experience this kind of dificulty?
Unfortunately I can't provide you any valuable information about JBoss admin console.
Anyway, I would suggest you to set up cache stores/loaders for your Infinispan caches declaratively (using configuration xml file) or programmatically (using fluent API builder just in code).
Here you can find more details about stores/loaders and some example configurations: https://docs.jboss.org/author/display/ISPN/Cache+Loaders+and+Stores
And also take into account that in the recent Infinispan version (5.2) there is no possibility to change cache configuration "on fly". You need to restart your service with new configuration in case of any wanted change.
(What do you exactly mean by custom Infinispan loader?)