From your original post It sounded like you were using the embedded API to embed an ejb container in some existing process/vm, and that your client program was running "standalone" in another process, and that your clients were not satisfying the access control policy set on your ejb.
if your client is also running in the process/vm in which you have embedded your server, then as you suggest, the client side orb *should* recognize that the target service is *local*, in which case it will short-circuit the network invocation (over rmi/iiop) and perform a local invocation; which will bypass the ejb container's network authentication system (within the server-side orb). In this case, the security context associated with the client thread, will be internally propagated and applied in the ejb container access decision.
As you suggest, if that is your model, then you need to do something *like* a JAAS login to associate a security context with the client call thread, and as Nithya recommended, you should be able to do that using the Glassfish ProgrammaticLogin api.
[Message sent by forum member 'monzillo' (ronald.monzillo_at_sun.com)]
http://forums.java.net/jive/thread.jspa?messageID=384780