We have a Java 1.4 web service running on AIX 5. We want to have the web service methods execute under the context of the caller, not the hosting web server. How would we go about this?
You should be able to perform JAAS authentication (just like a normal J2EE web application), which will establish the principals associated with the subject. The container automatically ensures that the current worker thread is associated with the identified subject. The subject and its principals are also propagated down to the service/business tier as is the case with a normal servlet.
It might also be worthwhile to determine the web service security features of the underlying application server, as it might offer more features than the basic/digest/form authentication functionality that is present in JAAS. For example, WebLogic Server allows for certificate based authentication of web service clients (with some configuration involved), and that might be true of the application server that you're using as well. Usually, the container security features will ride on top of JAAS and the related security features in J2EE 1.4, thereby ensuring that the J2EE security features used in the other sections of the application will continue to perform as expected.
Related
I have a wls server where there are several web applications deployed. One of these web applications contain a restful web service which can take a long time to execute. Therefore I want it to have a custom WorkManager that can handle threads which otherwhise are considered stuck. As I understand you can set a work manager for a specific ejb by using xpath to point at its dispatch policy, like this
'/weblogic-ejb-jar/weblogic-enterprise-bean/[ejb-name="anEJB"]/dispatch-policy'
Is there a way to do this for restful web services, i.e. set the workmanager for a specific web service (or web application) and not all of the applications which are deployed on the same wls? The examples I have found only does this globally.
The WLS version I am using is 10.3.6
Jolokia is uncharted territory for me, and after having read the documentation, I'm still not sure if it'll work with the scenario I have in mind.
Setup:
Tomcat application server (version ranges from 6.x to 7.x), usually on a Windows platform, occasionally a flavour of Linux.
Deployed third-party Java web application (SAP BusinessObjects) with JMX monitoring enabled (accessible through RMI).
Possible gotcha's:
The Java web application to be monitored is commercial and closed source, so modifications are not possible. The only thing that can be changed is the JMX port number
The JMX endpoint is a custom one, thus not the default jmxrmi endpoint.
The JMX connection requires authentication.
Goal:
What I'd like to do is to deploy the Jolokia WAR file onto the Tomcat server and then configure it so that I can read the MBean attributes from the other web application.
I would code the client myself using Python (version 3) and the Requests HTTP library.
I've been reading through the Jolokia documentation (again, I'm a complete newbie at this point), but can't figure out if this would be possible or not (as I can't seem to find where to enter the JMX/RMI url or the authentication information).
Questions:
Can I use the WAR agent for this setup?
If not, can you please explain why (so I can understand, not because I don't believe you). Also, is there another agent that's more suited for this scenario?
If yes, can you point me in the right direction how to configure the Jolokia to the web application to connect to?
First of all, Jolokia by passes the JSR-160 connector stuff completely, so there is no need for any JMX/RMI authentication. The whole purpose of Jolokia is to provide a bridge over HTTP/JSON to the internal JMX subsystem. Depending on the agent, you can secure Jolokia quite easily. For the WAR agent, securing is the same as for any Java EE web app: Setup some roles and users for tomcat (e.g. in tomcat-users.xml) and reference the role in the security contstraints within the jolokia.war's /WEB-INF/web.xml.
To your questions:
Yes, you can. If you don't have any specific authentication needs, simply drop the jolokia.war into tomcat's /webapps directory. I suggest to try this first before adding security. For deinstalling the agent, simply remove the war.
As an alternative, you could also use the JVM agent, which opens an own HTTP server on an extra port (default: 8778). More on this in the reference manual
There is no need for a dedicated connection to the web app since MBeans are registered globally and are accesible from anywhere in the JVM. A webapp should of course select carefully the management information it exposes. So, there is no extra step needed and you can access the MBeans for the WEB app directly (except when it does something unusual with Java security, but I don't think so).
To test the installation, simply connect to the Tomcat with your browser and the context /jolokia (e.g. "http://localhost:8080/jolokia"). You should see the version information about the agent itself.
The next step would be to explore the JMX namespace, either with the browser (and operation "list" like in http://localhost:8080/jolokia/list , but that's tedious) or with a client like j4psh or hawt.io. Hopefully you will find the MBeans of your webapp you are looking for.
We want to realize a SSO-infrastructure with some IBM Domino / Websphere products and one custom web application. All IBM products are configured for SSO. Therefore, the WebSphere Application Server 8 generates an LTPAToken2 after successful login in one of the IBM products. We want to achieve the same behaviour for our own custom web application. After login into this web app, a LTPAToken2 should be generated.
Therefore my question: Is it possible to generate a valid LTPAToken2 in our custom web application? Or maybe, is it possible to use the WebSphere Application Server APIs for this generation? Which steps would be nessecary to achieve this? At the moment, our custom web application is not hosted in a WAS, but on a Tomcat.
Thanks and best regards
Ben
As long as you have your application hosted on a tomcat server that is not possible. There is no open API from IBM for creating LTPA tokens.
If you would have had the same user directory and using standard Java Security Mechanisms you could move your application to WAS, where SSO is configured. Not only would it be possible, your LTPA tokens would be created on login to your web application without any further configuration.
As it seems have a solution with two different user directories, sharing the same user id but not the password, you need to take other measures to achieve SSO.
One is to have an Access manager software which handles login for all your applications,
A second solution is to write some custom code. Login into the tomcat server could generate a custom cookie. You need to write code to generate this cookie. Then you can write a TAI to intercept it on the WebSphere server thus accepting the login. The TAI would be configured in the container rather than in a separate application itself. (example)
I also assume you could solve this by writing servlet filters to handle the login, rather than a TAI.
If your Tomcat app is on the same domain as (one of) the WebSphere servers, and the Tomcat server has network access to the WebSphere instance, you could have a servlet in your Tomcat app accept credentials on its request and pass them in an outbound http request to something like /<secured app>/j_security_check on the WAS instance, record the LtpaToken2 if successful and then add a cookie with its value in the servlet response on Tomcat.
As long as the two servers are on the same domain the browser will send the cookie back if the Tomcat app links/redirects the user to a secured URI on the WAS app, and you have SSO.
I am newbie to EJB's. From all the reading and searching I have done till now, I understood the following:
EJB are the beans in which an applications business logic is written and maintained.
All EJB's are put into something called EJB container.
EJB container is nothing but a server side program written in order to manage EJB's, and to provide basic functionalities which are meant to be provided by EJB(viz, transaction management, security, collision free envt, etc).
1) My doubt is, does the so called EJB component reside in all application servers?
2) When we say EJB 2.1/3.0/3.1, does it mean that the new version of EJB container has been released?
3) Does the EJB container reside in web servers too?
Thank you.
You understood the EJB idea correctly.
Yes and no. Depends on what you understand as "Application server" (ambiguity described below in answer 3.)
When you say EJB 2.x/3.0/3.1 or so on, you're referring to a particular EJB specification which means that you're referring to a set of services this version supports. In other words - yes, it means that the EJB container must be in a given version.
First the specification is released (you can see the draft versions, vote for new features and basically participate in this process). Then, a reference implementation (RI) is written just to show that it's "doable" and you can use it right away. Then, different vendors might provide their own EJB containers which must conform to the particular EJB specification.
There are few different terms you need to be aware of. Just to be sure, we're talking about the same things:
Web server is a HTTP/HTTPS server like Apache HTTP Server which serves clients requests. This term is not only related with Java EE.
Web container is a Java EE term which can mean few things, but usually it refers to Servlet container and, let's say JSP container. Those containers are serving web clients, so that's why it's web container. Generally, web container have a web server within it (like in the case of Tomcat.) However, you can configure it so that the static resources will be server by only pure web server while dynamic content (your Java App, Servlets, JSP, etc.) will be server by your web container.
Application server is a vague name. In Java EE purists world it can mean only such server that provides all the Java EE services. Non-Java EE purists treats Application server just as an arbitrary server which consists of your application. According to this definition, you can call Tomcat (a web container and web server) an application server.
As you see, the vocabulary is not sharp, as one thing might mean few slightly different things. Moreover, since Java EE 6 we have profiles. This means that you can have Java EE Application Server conforming to the Web Profile or Full Profile. In such terms, just the Web Profile server should be treated as an application server.
Just as a summary - you can use EJB Container in Web Container. Take a look at OpenEJB or basically at project TomEE.
To answer your questions
Generally yes. Application server is generally referred to a server with has EJB container like Glassfish, Jboss etc. But you need make sure that the application server has EJB support.
YES
NO. Web servers or Web containers (Tomcat, Jetty etc ) serve a different purpose than EJB container. But all the application servers do have web servers (along with EJB containers. ).
The EJB container and web container (servers) server are different layers in a Java EE application scenario . Check this link for more info.
As the title suggests, this is in relation to Java EE and Glassfish in particular.
From what i've learned the application client is executed in some application client that has the ability to talk to glassfish. But there seems to be limitations to this regarding annotations.
Can someone give me an example of the difference in connecting to a glassfish application server from the two different application types?
What is the benefit of the application client approach, and what approach is the most commonly used when developing application clients for Java EE?
The code (work you need to do) associated with connecting to the app server in either case is not really all that hard... but it is covered in different docs.
These are the instructions on how to access an EJB from a stand-alone java application.
These are the instructions for using an app client to access an EJB from a Java EE 6 Application Client with GlassFish v3: http://docs.sun.com/app/docs/doc/820-7695/beakt?l=en&a=view
Accessing an EJB from an application client gives you access to more of Java EE services 'automagically' than if you were working with the EJB 'directly'. You can cobble together access to some of these services in the stand-alone case, but the burden shifts onto the application developer/deployer to make that access work.
Creating a stand-alone application that accesses an EJB will seem easy, in the short term, and many folks will invest in that strategy. If they deploy their client application onto a large number of machines, the burden associated with a cobbled together service access strategy can become a burden.
Deploying an application client that uses the application client container is not free either. The advantage is the fact that you have the support of your app server vendor to overcome deployment issues.
If you are using GlassFish (v2.1,v2.1.1 or v3), you can also take advantage of Java Web Start support, which simplifies client application deployment a lot.
An application client is actually run in a container and has full access to Java EE resources defined on your server in the same way that a Servlet or EJB does. This would typically be used for some type of admin client, not a user application. Here is one explanation.
In addition to the Java EE Application Client, there is also the concept of a Thin Client, which allows access to some Java EE resources as well, but not as easily as the App Client. It usually involves using JNDI lookup with absolute names as JNDI references are not available. A typical case for this would be a standalone producer/consumer of JMS messages. It is basically a lighter weight option of the full App Client.
If you are simply creating a user application, you will most likely want to either use a Thin Client model, or a plain old application that simply consumes services from your Java EE app via servlet or web service calls.