The current issue is an implementation/integration issue. Whoever is constructing the
Invocation object on the server side has taken care of setting the principal and cred, but
has not dealt with the security context.
The ejb containers can ensure that there is a security context on the invocation (somebody
has to do this before the security processing starts). I think I am going to stick with
the explicit requirement that any invocation coming into the containers have the security
context set on the invocation, by the invocation builders on the server side.
In reality, we do not need the principal and the credential on the invocation because the
security context would anyway contain them.
There can be a chain of security interceptors right after the containers on the call path.
So the security context has to be established on the server side.
The client side security interceptors take care of constructing a security context and
then send it on the invocation over the wire. Now if the server side invocation
constructors ignore the sc that came on the wire, it is bad.
I think we really need some type of Invocation construction factories that take care of
such concepts. Every integration layer (ProxyFactory, BaseLocalProxyFactory,
CMPFieldBrigdexxxx, WS integration layer) who are constructing the Invocation objects can
use the factories.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041466#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...