Hi,
In the security example/how-to that ships with JOnAS 2.1.1
security authentication is done by Tomcat while access
verification for the EJB container is delegated to the AVS service.
Note also that the propagation of the security context is operational
with Jeremie only (contribution for propagation on RMI are welcome:-))
This delegation of verification uses the java.security.Guard interface.
There are 2 Guards used by each container, one for the Methods, one for
the role-ref map.
In JOnAS server, the AVS is wired to the server, but nothing prevent you
from rewriting it. In the upcoming version of Enhydra Enterprise that
will integrate JOnAS2.1.1, the AVS service will be deployable on the
platform.
So anyone will be able to provide it's own implementation of AVS.
One could even have several AVS implementation running on the same platform.
Since I am doing this integration, I also intend to provide Tomcat filters
delegating web-container access verification to AVS and authentication to an
Authentication Service. This will allow an easy integration of a very
dynamic
security/authentication/access control.
Hope this helps,
Christophe
Christophe Ney - mailto:[EMAIL PROTECTED]
Enhydra Project - http://www.enhydra.org
Lutris Technologies - http://www.lutris.com
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Halas, Miroslav
> Sent: Wednesday, November 08, 2000 11:07 PM
> To: jonas
> Cc: 'John Ellis'
> Subject: RE: 2.1.1 Security Problem
>
>
> I would prefer the authentication through the JNDI tree how
> John described
> it. It makes the implementation of security layer for J2EE
> application more
> application and web server independent. This is from my past
> memory (when we
> still used Weblogic instead of Jonas 8-) how Weblogic handles
> authentication.
> Our application has very dynamic
> security/authentication/access control
> rules and therefore we had to code most of them relying oon
> the app server
> for getCallerPrincipal and authentication. We are using Jetty
> as our web
> server and therefore we cannot rely on the provided Tomcat
> implementation.
> What we do is what John described, we construct JNDI context
> with proper
> security credentials and rely that once the creation is
> complete and we get
> home interface the user is authenticated to access server.
> This solution can
> be used in any type of client with any type of server.
> What are your thought?
>
> Thanks for a great product,
>
> 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: John Ellis [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, November 08, 2000 3:57 PM
> To: jonas
> Subject: 2.1.1 Security Problem
>
>
> We have an RMI-based JNDI implementation that handles user
> authentication. I had modified the GenIC, etc. from JOnAS 2.0 to
> generate classes that get the principal from the JNDI tree for the
> "getCallerPrincipal" call.
>
> First, a little background on how this works: I wanted to base the
> principal on the principal that the client machine used to get the
> InitialContext, so I needed to set the principal at the time when the
> user got the Home out of the JNDI tree. This would be the only time.
> If I relied on thread storage, a user in a thick client might
> get a home
> and pass it off to another thread then use that home. In
> that case, the
> proper principal would have been lost. What I did was
> implement a class
> that had a call to set the principal in the generated Home
> implementation. I then created a "HomeProxy" that was serializable.
> This was actually what was sent down to the client (compelete with the
> correct principal). I had planned on later adding a signature to the
> principal so that I could be sure it was legit in later
> calls. Now, any
> method that was called on the HomeProxy would also send up
> this pincipal
> and the actual home would set the created/found bean's Context.
>
> With 2.1.1, of course, non of this works. This doesn't bug
> me, because
> now I can get rid of alot of code. What is a problem, is
> that I cannot
> get the Security features to work in 2.1.1 and also, I think, from
> looking at the code, that even if they were working, they are
> not what I
> am expecting from a J2EE application. Here is my
> understanding: In my
> situation, I would implement SecuritySender and SecurityReceiver to
> setup the SecurityContext, but I cannot find any code that calls those
> methods (specifically, "sending_request" other than in
> "SSHandler.getRequestContext", but then I can't find any calls to that
> method). Indeed, I have tried setting up a bean with secured methods,
> and installed the TomcatSender, but the bean's methods are still
> completely accessible. I am happy, for the immediate future,
> sitting on
> what I've got, but I do have a few question about the
> (planned) security
> implementation:
>
> 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?
>
> I am sure that, if you are planning on doing authentication
> through the
> JNDI tree, we could submit our JNDI implementation (which has several
> other cool features like EventContext support, a heirarchical tree and
> Access control by tree branches).
>
> Thanks,
>
> John Ellis
>
>
> ----
> 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".
