Hi and thank you for your response.
To reply to your question, i do not test this feature using an application client because it is not my use case. I have the obligation to activate the security with calls performed from a standalone client (through lookup invocations and programmaticLogin feature)
Effectively, after watching logs, this means that the caller identity is not propagated to the method. So how is it possible to retrieve the wrapper to my bean from the client side if the caller is not set and propagated from the client to the server ?
Yesterday, i tried to solve this problem by adding some security permissions to the server.policy file of the application server. Not an elegant solution but why not ....
I add the following permission to the policy file :
grant codeBase "file:${com.sun.aas.instanceRoot}/applications/2ee-modules/-" {
permission com.sun.appserv.security.ProgrammaticLoginPermission
"login";
};
grant {
permission javax.security.jacc.EJBMethodPermission "TestSecurityBean";
};
I notice that the first permission has no effect on the client application behaviour.
On the other hand, the second permission has a beneficial effect on the behaviour because the method is called and the caller identity is correctly set ( "franck" , my first name). The problem, because there is always a problem, is that when i add in the code an other method with an other role, that is not granted or linked to the calling user, the invocation is authorized on this method. So in this case the authentification seems to work but not the authorization feature...
what's wrong ?
Can you give me an explanation ?
Thanks.
[Message sent by forum member 'franck_mosse' (franck_mosse)]
http://forums.java.net/jive/thread.jspa?messageID=225179