Richard Monson-Haefel wrote:
>
> Marc San Soucie wrote:
>
> > Richard Monson-Haefel wrote:
> >
> > > 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.
> >
> > 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.
> In essence you are saying (anonymous clients aside), because Authentication is
> not standardized in the specification, there are no authentication rules
> regarding the use of an EJBObject obtained through the handle. Whether or not
> this a security hole depends on the vendor.
No, there are rules regarding use of an EJBObject obtained through a
handle. Those rules are the access control entries in the deployment
decriptor, and the EJB specification requirement that the container honor
them.
There isn't a rule about who can get a reference to the EJBObject from a
handle. If an EJB server does not perform authorization checks during this
operation, it is up to the customer - the security administrator - to
determine whether a security issue results. This is not a spec compliance
matter - it's a quality of service matter.
Also, calling it a "hole" implies that someone can "crack the system" by
getting an EJBObject reference. Since authorization checks are applied to
method invocations through the reference, I believe the principal possible
issue is a denial-of-service attack, which I haven't heard described
typically as a "hole". But that's just terminology.
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".
