Last week, we had the author of TDD for a Shopping Website LiveProject. Friday at 11am Ranch time, Steven Solomon will be hosting a live TDD session just for us. See for the agenda and registration link
We have been trying to port our application onto GlassFish, from its long standing usual home running on WAS. We have run into trouble trying to get the security within the application working as it does on WAS. Our application is broken up into three separate enterprise archives and uses ejb 2.1 for several stateless session beans. When a log in is performed for a user in the first ear, then a call is made to another ejb in a separate ear, the caller principle populated in the SessionContext for that ejb is not the authenticated user which was logged in and it should be running as. Instead the caller principle is either ANONYMOUS or the GlassFish admin user for that domain.
On WAS, propagation of the authenticated user between the different enterprise archives and ejbs was handled by using the IBMs helper APIs, such as . We have attempted to perform the similar authentication on Glassfish using , but while this appears to run the action as that user, the user is lost during the first call from one enterprise archive to another.
If multiple enterprise archives, deployed in the same J2EE container, are mapped with similar role descriptors in the application and ejb descriptor files, is it possible to have the authenticated user propagate across various ejbs held in separate enterprise archives?
Thanks for your reply. For legacy reasons, the full application has been developed and is sometimes sold as separate components. So, unfortunately, we cannot roll all three components into a single enterprise archive, although it would indeed make life easier. I am trying to ascertain if it is possible to have a single-sign-on approach using multiple enterprise archives all sharing some sort of trust domain.
I am trying to ascertain if it is possible to have a single-sign-on approach using multiple enterprise archives all sharing some sort of trust domain.
Using ejb 3.0 in glassfish 2.1 this is possible. See next.
ejb in app1 (app1.ear)
ejb in app2 (app2.ear)
There are no ejb-jar.xml descriptors in any app's ejb.jar.
The file realm has two users: "user1" and "user2", in the group "users".
The auth entry point is a servlet in app1 with basic authenticaton, that calls the ejbApp1. The auth identity is propagated to this and then to the ejb in app2.
Input: insert the credential ("user1", "pass") in the html form for the servlet.
Output: "result = Hello, this is ejbApp2! the principal i'm seeing is user2"
Maybe you could try to replicate this example in 2.1.
For legacy reasons, the full application has been developed and is sometimes sold as separate components. So, unfortunately, we cannot roll all three components into a single enterprise archive, although it would indeed make life easier.
Maybe you could consider automating the generation of ears for each component combination, if feasible and your business model allows it...
Regarding SSO from the web layer in glassfish, you may find this interesting.
I'm all tasted up for a BLT! This tiny ad wants a monte cristo!
free, earth-friendly heat - a kickstarter for putting coin in your pocket while saving the earth