1 Reply Latest reply on Mar 10, 2009 6:47 AM by Fin Steenbjerg

    Service EJB to DAO EJB Design Issues

    matt mcgrillis Newbie

      I'm stumped...

      I have a JSF which calls a serviceEJB which in turn calls a daoEJB. Now when serviceEJB calls getUserPrinciple it returns the principle correctly. serviceEJB then calls methodA of daoEJB with a @RunAs set to “SERVICE� (to stop the JSF web client being able to call daoEJB directly - with RolesAllowed set on the DAO). Though when I call getUserPrinciple within daoEJB gets a caller principle on ‘anonymous’ instead of the correct principle set by JAAS.

      Now you can use @RunAsPrincipal... to manually set the principal when the dao EJB is delared... but as far as I can see, there's no way of passing in the original principal

      Surely there's a hole in the spec if this anyone using a Service-DAO ejb pattern can't use caller principle in the DAO?

      I can't be the first to of hit this type of problem, whereby I need to use 'run as' to change the ROLE in the service so the DAO can't be called directly(by using RolesAllowed)...

      I just don't understand why it is acceptable to change the Principle? Surely it should be fine to let that be set by JAAS and maintained, and just the role changed by 'run as' rather than changing the role (as expected) but also deleting the principle?

      Does anyone know if there is another way round getting the DAOs not be called by the webclient without using RunAs?

      I could remove the RunAs though this screws up my security model as in theory my JSF beans could call my dao EJBs directly (which I don't want)

      Or ideally... does anyone know of any way of retaining the orignal principal set by jaas when an ejb calls another ejb when @RunAs is being set???



        • 1. Re: Service EJB to DAO EJB Design Issues
          Fin Steenbjerg Newbie

          I am not sure if this suggestion is good. But anyway ...

          I would use ejb-client jar file that contains the classes that your clients (your jsf) are allowed to use in this case the interface for your service bean. In this way your clients do not have the classes/interfaces for your dao EJBs. In addition, I would make the DAO EJB a local bean to reduce accidental access to the dao.

          This would not make it impossible to call the dao from your clients, but it would certainly be difficult.