• 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 ...
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
  • Mikalai Zaikin

controlling security context propagation

Posts: 17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
after working on several spring based web applications I am working on my 1st EJB 3.0 app.

The main user groups are "customers" that perform actions on their own behalf and "agents" who perform acts on behalf of customers.

I don't want to pollute my service layer method signatures with a "user" parameter for every method that needs to know the user it is executing an action on behalf of.

I believe the various methods on the EJBContext related to authentication/authorization such as getCallerPrincipal(), isCallerInRole() etc are used to resolve these issues. For instance, the impl of a method named getActiveOrders() could use the name of the Principal to look up the customers active orders.

However, when an "agent" executes methods (e.g. getActiveOrders()) they are typically acting on behalf of a user. So when an agent executes getActiveOrders(), they want to see the orders for the user they are serving.

Using a custom HTTP based stack for service method invocation, I could propagate this information by adding the "acting on behalf of user XX" information as HTTP headers on the client side and reading them on the server side using an HTTP filter.

However, I have no idea how to accomplish this inside the confines of an EJB application (JSP front end - presentation and service layer may or may not be collocated in the same VM)? I would strongly prefer a standards based solution.

Ranch Hand
Posts: 457
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
you've correctly surmised that the getCallerPrincipal() method will handle the agent authentication, but in the example you are stating the user is just another data point being manipulated,

whether you move to a stateful session or pass the data around will be driven by various other design concerns
    Bookmark Topic Watch Topic
  • New Topic