the runAs role has been declared, a non-group principal has been mapped to
the role, and an appropriate runas principal (from the role) has been set
on the StartupServlet; this should be more than sufficient to establish the
run as identity of the servlet.
fwiw, depending on the contents of the role mapping, steps 1 and 2 may be
sufficient to cause the Glassfish deployment system to select a run-as
imo, the effect of runas during servlet initialization is not explicitly
prescribed by the servlet spec, and I would not be surprised if Glassfish
only establishes runas during the invocation of a service method of the
servlet. You can confirm that your run as config is working for the more
typical case, by moving your ejb call into a service method (e.g.; doGet).
I was surprised to read that runas sometimes works for you during init. we
will have to look into why that might be.
it probably makes sense for the servlet spec to require that a runas
designation be in effect during init (modulo the jsr 250 annotation
overriding semantics). in that case, the init time run as identity of
servlets configured to run as their caller, would need to be specified
(presumably as undefined or unauthenticated).
Since runas is specified for a servlet, I would not expect runas to apply
during context initialization; such as when ejbs are called from servlet