3 Replies Latest reply on Apr 28, 2014 2:42 AM by David Lloyd

    Musings: Principals and EJB invocations from a remote server instance

    Paul Benedict Newbie



      When reading the above document, I see a predefined username is hardcoded in both server configurations. This tells me the username really represents a system user -- an identity between two machines. The unfortunate downside to this kind of setup is that calling SessionContext.getCallerPrincipal() at the destination will return to you the system user (user "ejb" in the referenced document). If you were hoping to pass an identity that represents a human user, don't count on it... and it won't work because, upon startup, the client server uses the system user to complete a handshake with the destination server.


      The handshake log message looks like this:

      13:58:33,428 INFO  [org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver] (ServerService Thread Pool -- 30) Successful version handshake completed for receiver context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext@20a50d39, receiver=Remoting connection EJB receiver [connection=Remoting connection <70652eb3>,channel=jboss.ejb,nodename=localhost]} on channel Channel ID 89e8fa46 (outbound) of Remoting connection 3adc4833 to pcname/localhost:8080


      AFAIK, the best way to transfer the human user identity (and his credentials too, if desired) is to provide them as part of the EJB payload (i.e, in the method parameters). Such a setup is analogous to using web services, in which HTTP Authentication represents the system user (trust between computers), and WS-SEC which contains the human user credentials.


      If anyone has comments on this design, please let me know. I just wanted to share some lessons learned from my reading and experimenting.

        • 1. Re: Musings: Principals and EJB invocations from a remote server instance
          David Lloyd Master

          We are going to be having some meetings to discuss this very topic early next week.  You are right though, the identity has to be propagated in a clean manner between systems, and a notion of identity "trust" has to be established.  Hopefully sometime next week we'll have a comprehensive "big picture" ready to discuss.

          • 2. Re: Musings: Principals and EJB invocations from a remote server instance
            Paul Benedict Newbie

            Please consider incorporating some of my feedback into your meeting. I am trying to meet a certain use case but there doesn't appear to be a "good way" of currently achieving this. For example, the system user is necessary to achieve secure machine communication, but that's typically irrelevant to business code; business code should be interested in the principal of the human user and his roles. My current opinion is that there is a "leaky abstraction" (love the term) in the implementation; because right now the JEE security annotations aren't particularly useful for system users (and even more so when there's only one).


            I think JBoss needs to clearly delineate between the two necessary forms of principals.


            One possible solution I've been searching for is letting the remoting subsystem authenticate as it does today, but also marshall the human user's identity too. Here is a theoretical enhancement:

            1. Server A uses LoginContext with "client-login" and populates CallbackHandler with human user's principal.
            2. Server A makes EJB invocation
            3. Server A remoting subsystem passes the client's hardcoded system user credentials and LoginContext for the human user
            4. Server B authenticates credentials of system user
            5. Server B populates the EJB security context with the marshalled LoginContext**
            6. Server B executes EJB method against human user's principal and roles -- fully supported by JEE security annotations


            **In my setup, the client is a trusted client who guarantees the human user is already authenticated (thus not needing authentication again at the destination). However, since my case isn't everyone's case, there should be an configuration option at the destination server to authenticate.


            I think this is all due to the remoting subsystem not hiding its security implementation well enough. Truthfully, I can't find a compelling reason (even if it is technically correct) for any business code to know about who the system user is. On the contrary, if both client app and EJBs are within the same container, using "client-login" properly propagates my human user's credentials. It's this kind of schism that has people confused; I think this thread witnesses to that confusion:



            David, I hope this explanation helps some.

            • 3. Re: Musings: Principals and EJB invocations from a remote server instance
              David Lloyd Master

              We will definitely consider this feedback. Thanks for taking the time to give your input.