Hi Daniel,
Daniel Schulze wrote:
DS> I was reading the j2ee 1.3 spec this weekend
DS> (http://java.sun.com/j2ee/j2ee-1_3-pr-spec.pdf).
DS> Please have a look at chapter 9!
Thank you for the good reference, I have read it.
DS> They consider a component container for client-applications to provide
DS> them with a secure context. This container is responible for
DS> authentication (or he can direct this to the application itself if a
DS> CallBackHandler is specified). I think this is the right approach to
DS> get a generic security framework (and we meet the spec compliance).
Let's distinguish application clients as J2EE component that are
executed inside the application client container from other
client applications. Let's call them for short "J2EE clients" and
"independent clients".
AFAIK, independent clients are not forbidden by J2EE specification.
Surely, jBoss should eventually support both, but jBoss security
services shouldn't be limited to J2EE clients.
Note, that in general J2EE clients don't replace independent clients,
don't think of independent clients as of ones that haven't been
brought into accord with J2EE specification, but should be.
J2EE clients are more secure than independent ones, but also more
restricted.
They cannot dynamically access any bean, but only those described in
the correspondent application-client/ejb-ref element of ejb-jar.xml,
and so on.
In many cases J2EE clients would be inappropriate.
Note, that for J2EE clients security the specification provides
application-client/callback-handler element of ejb-jar.xml:
"In addition, an application client may provide a class that
implements the javax.security.auth.callback.CallbackHandler interface
and specify the class name in its deployment descriptor"
And note, that uCallbackHandler in the client part of my scheme meets
the requirements!
So my scheme can be easily adapted for use with the J2EE clients.
Thanks,
Oleg
