Ok, after looking at Jonathan code, I have determined that I will implement it by
loading classes with the SecuritySender and SecurityReceiver interfaces.
I am concerned that those interfaces do not seem to take into account the
possibility of a ssecurity context that needs to passed with the EJB (or EJB Home)
between threads. There is no way in the interfaces to authenticate the user in one
thread and get a home then use that home in another thread with the same security
context. What I would suggest is that you pass something unique to the object
instance being acted on (EJB or EJBHome) into the call in addition to a unique
number that identifies the call being made. This would allow an implementation of
these interfaces to tie the authentication verification portion to an EJB or EJBHome
and would allow the plugin to retrieve the correct context later. Implementation,
such as the one for Tomcat, of course, could ignore the extra parameter as it
already does the request_id.
I am also concerned about the the fact that there is no way to replace (without code
changes to JOnAS which is usually avoidable) the role to principal mapping
mechanism. You were already probably figuring on something for this, but I am going
to need that functionality more immediately, so I was thinking about making the
"getInstance" create some "SecurityService" object based on a configurable class
name and if that fails then just returning, by default a "SecurityServiceImpl". It
seems like the best place to do so.
Any thoughts would be appreciated.
thanks,
John
John Ellis wrote:
> Actually, Miro, it seems to me that it is very generic. The only Tomcat
> specific stuff is "plugged into" the server. If one wanted to do what you and I
> want, we would simply write out own implementations of sender and receiver, and
> pass a class that extends SecurityContext so that server-side verification can
> be done by the receiver.
>
> I am interested in implementing this for RMI, in which case I would still use
> the sender and receiver in the same way they are being used now (so that one
> wouldn't have to write several senders and receivers to accomplish the same task
> in different deliveries of JOnAS).
>
> I still have a few question, but I am downloading Jonathan now to see if I can
> answer them myself.
>
> 1. When/where does the "jonathan.prop" file get loaded fo the client?
> 2. Would this work for a client that was an Applet?
> 3. How should I use/supply the "request_id" that is being passed in?
>
> I expect to find the answers in the code... but if any of you have them off the
> top of your head, let me know.
>
> Thanks,
>
> John
>
> "Halas, Miroslav" wrote:
>
> > Hi Phillipe and John,
> >
> > thank you for the great document, it explained a lot. One first impression
> > is that the current implementation of the security authentication is very
> > Tomcat specific, but once the client call gets past the authentication and
> > the security context is set, everything else (methos level access checks) is
> > managed by Jonas and therefore is transparent for the application. John, I
> > would be interested in seeing your design if it is available, because the
> > JNDI authentication seems to be more generic and should work with different
> > types of clients. Phillip, what are your expectations in how Jonas
> > team/application developer will provide security features for different
> > types of clients (fat client, different web server)?
> >
> > Thanks,
> >
> > Miro Halas
> >
> > Miroslav Halas
> > Software Engineer
> > Compuware Corp.
> > 15305 Dallas Parkway Suite 900
> > Addison, TX 75001
> > phone: 9720-960-0960
> > fax: 972-960-8489
> > email: [EMAIL PROTECTED]
> >
> > -----Original Message-----
> > From: Philippe Coq [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, November 09, 2000 9:38 AM
> > To: John Ellis
> > Cc: jonas
> > Subject: Re: 2.1.1 Security Problem
> >
> > John Ellis wrote:
> > >
> > > Christophe,
> > >
> > > Thanks for your reply, but I am still a bit confused. I was searching
> > <all> the
> > > source code to find where the propigation was being done. I couldn't find
> > it.
> > > Also, I am not as interested in making it work now (I have a workable
> > solution
> > > for the present) but in making sure I understand (and can maybe influence)
> > the
> > > eventual direction of authentication in JOnAS in general. It seems that
> > you are
> > > making the assumption that all clients are the source for the secrutiy and
> > are
> > > secure themselves (which is the case for a Tomcat client, but not a thick
> > Java
> > > Application client or an Applet). Another point of clarification is that
> > I
> > > don't care about security on methods, but I do care that the
> > > "getCallerPrincipal" call returns some valid and authenticated result.
> > These
> > > direct questions will address my concerns.
> > >
> > > 1. When does the SecuritySender and SecurityReceiver get called?
> > > 2. Is the SecurityContext kept with the bean for the life of
> > > the bean?
> > > 3. If this is all tied to threads, how would you handle the situation
> > > where a thick client logged in to a JNDI Context then passed that
> > > Context to another thread?
> > > 4. How does a client VM (seperate from the EJBServer) get the
> > > SecuritySender, or does it even need one?
> > >
> > > Thanks again,
> > >
> > > John
> > Hi John
> > you will find as attached file a description of how is propagated
> > the security context in JOnAS with Jeremie.
> > I hope it will help you.
> > Best regards,
> >
> > --
> > Philippe
> >
> > Philippe Coq Evidian Phone: (33) 04 76 29 78 49
> > Bull S.A - 1 rue de Provence - 38432 Echirolles Cedex France
> > Download our EJBServer at http://www.objectweb.org
> > ----
> > To unsubscribe, send email to [EMAIL PROTECTED] and
> > include in the body of the message "unsubscribe jonas-users".
> > For general help, send email to [EMAIL PROTECTED] and
> > include in the body of the message "help".
>
> ----
> To unsubscribe, send email to [EMAIL PROTECTED] and
> include in the body of the message "unsubscribe jonas-users".
> For general help, send email to [EMAIL PROTECTED] and
> include in the body of the message "help".
----
To unsubscribe, send email to [EMAIL PROTECTED] and
include in the body of the message "unsubscribe jonas-users".
For general help, send email to [EMAIL PROTECTED] and
include in the body of the message "help".
