• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Caller principle propagation across multiple enterprise archives

 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,

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?

I have also posted this problem, along with a simple sample application to highlight the issue onto the GlassFish forums here --> http://forums.java.net/jive/thread.jspa?messageID=396643

Can anyone provide me with a little insight into whether this is possible, and if so, how I should be going about it...

Thanks,
Rob.

 
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I know that this is not an answer to your specific question but I suggest that you concurrently explore the option to migrate everything into the same ear, if you can.
 
Robert Sloss
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi John,

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.

Regards,
Rob.
 
Jonh Smith
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic