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.