Right now I inherited legacy application to support and I found a very strange thing. The application is Vaadin based app and it is hosted on JBoss EAP 5.1. On JBoss there is configured login-config module - org.jboss.security.auth.spi.LdapExtLoginModule. This module works fine and does its job. What would I like to do is how to get access to JBossGenericProncipal which is created by this login module? When I debug app and check session (StandardSessionFacade) I can see that it has a field principal but it is private and there is no way to access this principal.
Do you know how to retrieve this Principal? :)
Thanks in advance!
Kamil
If you are referring to the class org.jboss.web.tomcat.security.JBossGenericPrincipal
you can call the method getCallerPrincipal() that returns a java.security.Principal
Here's a reference from docjar: http://www.docjar.com/docs/api/org/jboss/web/tomcat/security/JBossGenericPrincipal.html.
There's also a org.jboss.as.web.security.JBossGenericPrincipal class, but is not available on JBoss EAP 5.
You can also retrieve the java.security.Principal calling the method getUserPrincipal() from HttpServletRequest
Related
I am migrating an existing app from teiid-8.8.1c1/jboss-as-7.2.0 to WildFly 9.0.2
Teiid 8.13.4. I have been able to update dependencies in all cases except one:
I have one class getting an Admin instance from org.teiid.adminapi.AdminFactory as follows:
AdminFactory.getInstance().createAdmin(...)
So that is can get and check status on a VDB.
But is seems that the AdminFactory is no longer part the teidd adminapi. Is there some new way to get an admin instance?
Per teiid message board, it was moved to teiid-jboss-admin jar:
[TEIID-3503] Development with Embedded teiid should not require dependency on EAP - JBoss Issue Tracker separated out the EAP dependent Admin functionality into the teiid-jboss-admin jar. It doesn't look like that was called out in the release notes or a specific migration doc, so I'll make sure that gets updated.
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.
I am having a project where we want to migrate from WebLogic Server to JBoss.
The project is WebPortal Build using Beehive and NetUI, NetUIX xml portal/portlets.
Is it possible to migrate those directly to Jboss with very limited changes to view like the entire structure can be reused in view which is defined in .portal files.
I also doubt that we can use tiles instead of using portals in JBoss, as Tiles when getting loaded in browser are not going to call to individual controller's begin methods and load default content from there.
I request you to please help me find solution for this migration problem.
Thanks,
Amit
From my experience, the migration from weblogic portal to jboss required a rewrite of the entire application.
If you are using weblogic portal (perhaps a 9.x version since you mentioned netui), i.e. the portal framework on top of weblogic server, there are far too many libraries specific to the portal framework p13n and netui alike that requires migration with no guarantee that these will be supported in Jboss.
Likely to face trouble retrieving entitlements from the p13n jars for users.
Regarding netui beehive, I think that is retired now (not sure), but I didn't got much support for it besides there are more lightweight frameworks out there that can help.
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.
I am new to Java EE 6 and working on getting a number of demo applications running finally.
I have an application scoped bean that has a #Schedule annotation on it that should in theory trigger that method every minute. However, that method doesn't appear to ever be invoked. It simply writes to the logs that it was called.
Can I use EJB3.1 on embedded glassfish? Do I need to do anything special to make it work?
Walter
(...) However, that method doesn't appear to ever be invoked. It simply writes to the logs that it was called.
Hmm... What?
Can I use EJB3.1 on embedded glassfish? Do I need to do anything special to make it work?
Embedded GlassFish is like a full GlassFish, there are no restrictions. So you can use EJB 3.1 with the full Java EE profile imeplementation and you can use EJB 3.1 Lite with the Web Profile implementation. I'm not sure #Schedule is part of EJB 3.1 Lite tough.