Richard Monson-Haefel wrote:
> This issue was brought up without resolution over a year ago. I had hoped
> that it would be adequately addressed in EJB 1.1, but it hasn't. In fact
> now it seems worse, because now the security flaw is mandated not implied
> as was the case in EJB 1.0.
>
> According to section 8.7 of the EJB 1.1: "At the minimum, a program running
> in one JVM must be able to obtain and serialize the handle, and another
> program running in a different JVM must be able to deserialize it and
> re-create an object reference."
>
> Since the only method available on Handle is getEJBObject( ), its assumed
> that authentication is NOT used to obtain the EJBObject reference. If no
> authentication is used no identity is presented, so authorization (access
> control) can not be done (how can you authorize an identity that has not
> been made available). Its possible that the Handle is supposed to store the
> identity and credentials of the client that serialized it, and then use
> that information to automatically authenticate when the Handle is used, but
> this seems like a serious security flaw.
There aren't many reasons to perform authorization checks on the
getEJBObject() method of Handle, because from the point of view of a
security system, a handle and a stub for an EJB object are functionality
equivalent. Both refer to the object but contain no information. Having a
stub gives you no more than the handle gives you.
One reason to perform an authorization check would be to prevent
denial-of-service attacks from rogue clients processing Handles at a
resource-exhausting rate. It is a really good idea to do this if the act of
generating and returning the stub causes system resources such as memory or
sockets to be consumed.
Your comment that "if no authentication is used no identity is presented"
is not really correct. Identity is always presented, but sometimes the
identity is the anonymous identity of a client presenting no credentials.
If the EJB server performs authorization checks on clients requesting
various services, it behooves the client to identify itself appropriately,
using the security services of the EJB server. Until the APIs and
programming model for those security services are standardized, this will
remain a server-specific coding task.
Once the stub is fetched from the handle, identity must be established
(again using server-specific services) before the EJB server will allow the
client to use the stub to invoke any bean methods, unless the EJB server
and deployer (and security administrator) allow for anonymous clients to
use that bean.
Marc San Soucie
GemStone Systems, Inc.
Beaverton, Oregon
[EMAIL PROTECTED]
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
