Just for the sake of anyone that comes across the same issue down the
track, I've had no luck getting this to work (tried nightly v2 also). I
can still kick-off initialization of the EJB module via a context
listener or servlet, I'll just have to avoid the use of roles/run-as to
secure it until I get a workaround in place.
Initializing the EJB tier via a web context listener or servlet imho is
just a handy abuse of the web hooks (esp. if you're not thinking of
deploying a WAR with the EAR) but is AFAIK the only cross-container way
of kicking of some initialization logic in the EJB module when the app
is first deployed or the container starts up; was anything added to the
EE 5 spec to address initializing the EJB layer when the container
starts, or destroying-resources/tearing-down when the container stops?
(-- aside from the various proprietary extensions).
Cheers
Joe
-----Original Message-----
From: Shevland, Joe
Sent: Tuesday, 24 April 2007 9:51 AM
To: 'users_at_glassfish.dev.java.net'
Subject: RE: RunAs on servlet being ignored
Thanks Bobby - the web security constraint was really just to test that
I could authenticate as one of the user's in the new realm (which works
as expected), whereas the intent of the RunAs annotation in the
InitServlet is to run as a 'system role' when the EAR is started to
initialize some services using an EJB call (which I don't want anyone
else to be calling interactively), so I'd prefer no user interaction
there... I will try just using the default realm though to see if theres
a difference. As far as I can tell the @RunAs is just being ignored (as
well as a the <run-as> element in the web.xml when I try that), so I
think I've just missed something obvious, will have a fresh look at it
now.
Cheers
Joe
-----Original Message-----
From: Robert.Bissett_at_Sun.COM [mailto:Robert.Bissett_at_Sun.COM]
Sent: Tuesday, 24 April 2007 1:19 AM
To: users_at_glassfish.dev.java.net
Subject: Re: RunAs on servlet being ignored
>
> I have an EJB (SystemService) that is annotated with the
> @RolesAllowed("fooadmin"), and a servlet (InitServlet) that is
> annotated with the @RunAs("fooadmin") annotation.
Since you're also restricting all pages in the web app to users in the
"fooadmin" role, then you don't need the @RunAs annotation in the
servlet -- it will run as the user that is calling the servlet. I have
included a sample below just so you can check what you have against it.
>
> As far as I can tell, I've put mappings pretty much everywhere they
> can be, [...]
Right now only top-level role mappings (in sun-application.xml) are
read, but this is about to change so you can put them in sub-modules as
well. Since you're being asked to log in when accessing the servlet, I
think you have this right. Have you tried with the default ("file")
realm first just to check? You might try that, remove the @RunAs
annotation in the servlet, and also maybe have the servlet output
HttpServletRequest.getRemoteUser() just to make sure it's really being
called as who you think it is.
Someone else may have other ideas about what problems can happen when
using your own realm -- sorry I can't comment on that any better.
Cheers,
Bobby
-----------------------------------
Simple example, showing the parts related to security below. This app
uses the default realm, though.
The bean:
@Stateless
@Local({MessageLocal.class})
public class MessageBean implements MessageLocal {
@RolesAllowed("ejbrole")
public String getMessage() {
return "Hello from ejb";
}
}
The servlet:
public class EjbTest extends HttpServlet {
@EJB
private MessageLocal messageBean;
protected void doGet(HttpServletRequest request,
HttpServletResponse response) throws ServletException,
IOException {
response.setContentType("text/html;charset=UTF-8");
PrintWriter out = response.getWriter();
out.println("<h2>" + messageBean.getMessage() + "</h2>");
out.close();
}
}
sun-application.xml:
<sun-application>
<security-role-mapping>
<role-name>ejbrole</role-name>
<!-- could also map to a group here -->
<principal-name>bobby</principal-name>
</security-role-mapping>
<realm>....</realm>
</sun-application>
parts of sun-web.xml:
<security-constraint>
<display-name>ejb-constraint</display-name>
<web-resource-collection>
<web-resource-name>EJBTestServlet</web-resource-name>
<description/>
<url-pattern>/*</url-pattern>
<http-method>GET</http-method>
</web-resource-collection>
<auth-constraint>
<description>Only ejbrole can access ejb test</description>
<role-name>ejbrole</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>....</realm-name>
</login-config>
<security-role>
<role-name>ejbrole</role-name>
</security-role>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
For additional commands, e-mail: users-help_at_glassfish.dev.java.net
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.