dynamic classloading

[tom.elrod]

JBossRemoting currently has the ability to dynamically load classes from the server that do not exist on the client's classpath. This is only enabled when the server is configured with a loader port (see http://labs.jboss.com/portal/jbossremoting/docs/guide/ch04.html#d0e816). In regards to Jira issue JBREM-47, is this enough? To be more specific, should there be 1) ability for the server download classes from the client and 2) security for allowing classloading at all?

For item 1, don't know that is important for the server to be able to load classes from the client. Is there a good use case for this?

The second item, security, would be good to have but the problem is how to implement it. If require full blown authentication/authorization, then would probably be worth using JAAS, which is going to require API changes on the client (as will need a way for user to set principal and credintials) as well as configuration on the server side (as will need to have a way to tie into security manager and set up rolls allowed to do the class loading).

Another way would be to do something simplier such as a secret password that is sent, like is done with AJP. Don't know if this would be enough, but almost seems like would be just as good to say if have loader port turned on, am allowing people to download classes and that be the end of it.

[starksm64]

The only usecase for loading client side classes would be something like an agent service where a client is passing in an implementation of an agent interface to execute on the server. This needs more than just class loading level security.

For the security, why can't there just be an interceptor/aspect that knows how to incorporate the current security context rather than requiring this as part of the api? The same should exist on the server side such that JAAS/JACC or custom security could be introduced.

[tom.elrod]

Ok. So loading classes from the client to the server is going to require either 1.) a way for the server to establish a connection back to the client on a different channel (as is done from the client to the server) or 2.) to have server send back a response message saying that it could not load a class, then have the client send that class (and so forth till all classes loaded).

Option 1 is less practical from user's perspective as would require having a open server socket on the client. Option 2 is easier for the user, but introduces a lot more complexity into the core invocation code as would not only have to check for special response messages, but would probably need security checks now on the client invocation code to ensure can send server classes.

As for security in general, either approach would require a way for the client caller to set their principal/credential info as well as a way to pick those up on the server side and have passed onto security manager for validation. There are no hooks for this currently (and am not even sure how a user would set this information). After figure this out, only covers authentication, still need authorization. So need a way to specify which classes can be loaded by which roles (assuming follow typical JAAS approach using roles), which I have no clue how to do using JAAS.

[starksm64]

The security aspect has to layer into the remoting. It cannot be a hard-coded notion as it has to function in the environment in which the remoting layer is being used. The ejb3 layer is introducing a security behavior on top of remoting, and the same has to be true of any transport specific security configuration.

A case in point is that the JASPI(JSR-196) has a notion of securing a request and a response. This is a pluggable aspect that should be usable in the remoting layer to allow for transport specific security checks.

In terms of the class loading request itself, I don't view a class loading error as much different from a clustered invocation that fails and should be retryed. There is a class not found reponse returned, and if the client proxy has a notion of class loading its aspect will deal with the failure, similar to how a retry aspect would in the clustering scenario.

The problem with respect to remoting is that these concerns are seperate aspects that layer into the a higher level proxy type of view. I don't view these as fundamental aspects that remoting should provide. We need to get together with the next gen aop proxy layer and define the usecases to ensure that they can be implemented on top of remoting.

[anil.saldhana]

A case in point is that the JASPI(JSR-196) has a notion of securing a request and a response. This is a pluggable aspect that should be usable in the remoting layer to allow for transport specific security checks.

Perfect match for JASPI.

JASPI provides insertion of security processing in the request response stream at 4 points - 2 on the client side and 2 on the server side, to secure/validate request-response. This is pluggable via AuthModules that can bridge to a stack of loginmodules. Highly relevant to http/soap request , implies extendable to the remoting layer to secure any kind of message.

http://wiki.jboss.org/wiki/Wiki.jsp?page=GeneralizedAuthenticationLayer
http://wiki.jboss.org/wiki/Wiki.jsp?page=ClassDiagramJSR196

The design forum discussion is at:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=72264

[anil.saldhana]

Tom, when you get a chance and if you find relevant, create a JIRA issue to evaluate JASPI for the remoting project and link off of the main JASPI(JSR-196) issue at:

http://jira.jboss.com/jira/browse/JBAS-2634

The main container JIRA issue for JASPI is:
http://jira.jboss.com/jira/browse/JBAS-2525