Hey
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.
My guess/hope is that JAAS will address this. Essentially, with JAAS you
can execute a piece of code "on behalf of" some principal. See JAAS
javadocs for details, specifically Subject.doAs(..).
If this is used then there is no problem as the executing thread has a
Subject attached to it. The getEJBObject() call can simply fetch that
and do some internal authentication of the client.
AFAIK etc.
/Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
Homepage: http://www-und.ida.liu.se/~ricob684
===========================================================================
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".
