Sim IJskes - QCG wrote:
On 10/08/2010 01:09 PM, Michal Kleczek wrote:
On Friday 08 of October 2010 13:02:17 Sim IJskes - QCG wrote:
On 10/07/2010 09:57 PM, Michal Kleczek wrote:
So...
I've spent a day on some thinking and prototyping and hopefully I
got an
idea. Here is an outline:
1. We annotate classes with an object implementing Module interface:
Is it safe to say that you are basically enhancing the codebase
annotation pattern?
Basically - yes.
Although I am not sure I understand precisely your question... :)
You understood correctly. :-) (i should have said, construct, well ok).
I noticed the readAnnotation of MarshallInputStream reads an Object
and then casts it to a String. Are we sure that this is not a possible
vector for a deserialization attack? Personally i would have taken a
UTF-8 String (with limited length), but if you only unmarshall Objects
from TLS connections, that you check first, i guess its ok.
So your solution is allowing for different credentials between the TLS
and the code source, and checking these credentials.
Is this package pluggable onto river without modifications in river?
Are you sure that's a good idea? Not modifying River I mean?
Michal's given this issue some thought.
It appears to solve the following problems:
1. CodeSource identity is no longer based on it's originating URL
location.
2. Two services using the same proxy CodeSource don't share the same
ClassLoader, one service can't gain the privileges of the other.
I'd had some thoughts about using Subject's in ClassLoader's with
Identical CodeSource for distinct identity, however the Subject isn't
known until after the classes are loaded.
I think we need to set up an issue on Jira and in skunk where we can
collaborate and explore further development.
Something I'd like to further explore is a ClassLoader inheritance
structure that places Service API and Jini Platform classes in a Parent
ClassLoader and all application, service and proxy classes in child
ClassLoaders, so they're forced to cooperate using the Service API, Jini
and Java Platform classes. This also ensures implementation classes
aren't visible to proxy code, for good security.
Cheers,
Peter.
