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.
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:
- Server A uses LoginContext with "client-login" and populates CallbackHandler with human user's principal.
- Server A makes EJB invocation
- Server A remoting subsystem passes the client's hardcoded system user credentials and LoginContext for the human user
- Server B authenticates credentials of system user
- Server B populates the EJB security context with the marshalled LoginContext**
- 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.
We will definitely consider this feedback. Thanks for taking the time to give your input.