What I implemented is the EJB2.0 run-as feature. The servlet 2.3 run-as
feature will be next, but I'm not sure it handles what your looking for.
> I have WAR clients that need to access EJB's via the WAR app and not directly.
This case is an unauthenticated client accessinga servlet that in turn accesses
an EJB. The servlet 2.3 run-as feature will allow you to specify a role to use
for security purposes. The J2EE 1.3 spec also mentions supporting this in
different ways. See below.
> I also need to have a 'loaded-on-startup' servlet (A scheduler in a WAR) to
> access EJB's without a 'real' user logging on. However if a 'real' user does
> access the servlet, they need authenticating in the normal manner.
This is not handled by the servlet 2.3 run-as. You cannot conditionally fix the
identity based on whether the caller to the servlet is authenticated. You
would have to deploy an unsecured version that has the fixed run-as identity
and a secured version that passes the caller identity. If your talking about accessing
the EJB from a thread created by the servlet, then you have to set the security
identity yourself as though your were a Java client.
The only docs for run-as are the servlet 2.3 spec. These are the two places it
is mentions in the 2.3pfd2 spec:
<servlet-2.3pfd2 spec>
SRV.12.7 Propagation of Security Identity in EJB Calls.
A security identity, or principal, must always be provided for use in a call to an
enterprise bean. The default mode in calls to enterprise beans from web applications
is for the security identity of a web user to be propagated to the EJB container.
In other scenarios, web containers are required to allow web users that are not
known to the web container or to the EJB container to make calls:
. Web containers are required to support access to web resources by clients that
have not authenticated themselves to the container. This is the common mode
of access to web resources on the Internet.
. Application code may be the sole processor of signon and customization of
data based on caller identity.
In these scenarios, a web application deployment descriptor may specify a
run-as element. When it is specified, the container must propagate the security
identity of the caller to the EJB layer in terms of the security role name defined in
the run-as element. The security role name must one of the security role names
defined for the web application.
For web containers running as part of a the J2EE platform, the use of run-as
elements is supported both for calls to EJBs within the same J2EE application,
and for calls to EJBs deployed in other J2EE applications.
<!--
The run-as element, if defined for a servlet, overrides the security
identity used to call an EJB
by that servlet in this web application. The role-name is one of the
security roles already
defined for this web application.
DEPLOYMENT DESCRIPTOR 106
Used by: <servlet>
-->
<!ELEMENT run-as (description?, role-name)>
</servlet-2.3pfd2 spec>
Now, the J2EE 1.3pfd3 spec talks about providing support for unauthenticated users.
I am going to add support at the war level for specifying the unauthenticated user
run-as role using a jboss-web.xml application level element.
<j2ee-1.3pfd3 spec>
J2EE.3.4.3 Unauthenticated Users
Web containers are required to support access to web resources by clients that have
not authenticated themselves to the container. This is the common mode of access to
web resources on the Internet.
A web container reports that no user has been authenticated by returning null
from the HttpServletRequest method getUserPrincipal. This is different than
the corresponding result for EJB containers. The EJB specification requires that
the EJBContext method getCallerPrincipal always return a valid Principal
object. The method can never return null.
Components running in a web container must be able to call enterprise beans
even when no user has been authenticated in the web container. When a call is
made in such a case from a component in a web container to an enterprise bean, a
J2EE product must provide a principal for use in the call.
A J2EE product may provide a principal for use by unauthenticated callers
using many approaches, including, but not limited to:
. Always use a single distinguished principal.
. Use a different distinguished principal per server, or per session, or per
application.
. Allow the deployer or system administrator to choose which principal to use
through the Run As capability of the web and enterprise bean containers.
This specification does not specify how a J2EE product should choose a
principal to represent unauthenticated users, although future versions of this
specification may add requirements in this area. Applications are encouraged to
use the Run As capability in this case.
</j2ee-1.3pfd3 spec>
----- Original Message -----
From: "Lewis Henderson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, June 15, 2001 3:22 AM
Subject: RE: [JBoss-user] :-) EJB2.0 RunAs
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
