For propagation the ClientLoginModule needs to push the identity that was authenticated. When was the custom principal created? Describe the full workflow from incoming request to propagation to the ejb.
The JBossSecurityMgrRealm cannot be involved in creating principals as its the security interceptor running in the context of the authentication request that has the knowledge and correct classpath.
1)User logs into webapp.
2) JBossSecurityMgrRealm gets called with userid=aaa,password=hello
//Create a simple principal to be passed to jaas
SimplePrincipal sp = new SimplePrincipal(aaa);
//Get the security manager
/** Note in the isValid call, the jaas framework gets called and custom LM creates a custom principal. ClientLM pushes it on the SA stack. The SA stack has the custom principal on the stack.
4) Request lands at the servlet.
5) In the servlet, there is call on an ejb (There is no explicit jaas login here)
6) In the proxy, the SecurityInterceptor picks up the latest principal from the SA stack (that happens to be the last call on the SA done by the SecurityMgrRealm)
7) The ejb is unhappy that it did not get the custom principal and chokes with a CCE.
This usecase is when the web and the ejb components are in the same VM.
The mismatch occurs because
the jaas auth happens at the beginning of the workflow and the Client Login Module would have placed the custom principal on the stack.
Since the authentication goes through fine, the JBossSecurityMgrRealm pushes its view of the username (a SimplePrincipal) on to the stack for use.
Why isn't the custom principal triggering reauthentication in the ejb container? The realm authenticated the simple principal and this is what should be cached. The custom principal is a derived identity for application consumption only.
Are there two security domains involved here?
One security domain.
There would be a reauth if the custom principal was ever picked up. It is sitting there on the SA stack. The Simple Principal got propagated.
The solution is to provide an option for the user to plug-in a custom principal class into the JBossSecurityMgrRealm.
So the issue is how the ejb container getCallerPrincipal is behaving. Let's get the testcase into the testsuite so I can drill down into why the custom principal is not seen. I would suspect its a conflict between run-as behavior and the ClientLoginModule pushed principal.
I would like to end this discussion as there is no evidence of an issue with custom principal propagation from both outside the VM as well as inside the application server.
Few things to remember:
* A custom principal that is created by a login module is its view of the authenticated user.
* Have the security domain between the layers involved in the propagation to be the same or have atleast one of the modules to be the custom principal creating login module.