Michal Kleczek wrote:
On Tuesday 26 of October 2010 15:27:17 Peter Firmstone wrote:
Hi Michal,
Sorry for taking time to respond, I've been busy and am still digesting
the code.
Michal Kleczek wrote:
In my code there is a simple hack to force creating a different
ClassLoader for each unique Module - before calling to a delegate
RMIClassProviderSpi I set a TCCL to a new ClassLoader that is unique to
the Module. (That is also the reason I had to provide a slightly
modified version of BasicJeriTrustVerifier so that not the proxy
ClassLoader but also its parent are verified) See AbstractRmiModule for
details.
Module uniqueness: two Modules are considered the same iff their equals
returns true.
In case of ProxyTrustModule (which is the most interesting) - two
ProxyTrustModules are equal when their codebases are equal and their
ProxyTrusts are equal. so for two different services - each providing its
own ProxyTrust for Modules - we create two different ClassLoaders
regardless of the codebases. (This is not based on Subject but on
service proxy identity) Basing it on Subject would be a little tricky
IMHO because actual service Principals are dependent on what the client
requires.
Ok I see your point, we should be using service proxy identity, not the
Subject. A server might use a number of subjects. Since not all proxy's
are services, would it be better to use the BasicObjectEndpoint identity.
ProxyTrust, doesn't by default implement equals or hashcode, if the
client is handed a reference to a remote object, that is a smart proxy,
from another client, it could end up with two separate instances if
ProxyTrust uses the default Object equals implementation.
So thinking about it a little more, perhaps we could use the Uuid of the
BasicObjectEndpoint?
Hmm... I've checked BasicInvoationHandler and it implements equals for its
proxies by (among other stuff) comparing object endpoints.
So in basic scenario (when ProxyTrust is a simple Jeri proxy) all is fine.
For smart proxies I would simply require "sensible" implementation of equals.
It is in the interest of a service to provide a client with the right Module
identity - otherwise the service just won't work properly (but it will not
affect client's security). Equals for me seems to be the easiest and general
enough. I wouldn't want to base it on some internal stuff since that would
preclude Modules that are not Jeri based etc...
Michal
Ok Interesting, anyone implementing a Service should be quite capable of
implementing equals, we should then specify that equals and hashcode
methods should be implemented for ProxyTrust.
For my benefit can you go over the process of how your new code works?
I'm interested in the choices you've made & why.
I still would like to wrap the ClassLoader in a GuardObject, this way
less trusted code (you don't want it to see the ClassLoader) cannot
obtain a ClassLoader reference, but it can delegate the functionality by
passing the GuardObject to more trusted code.
A little off topic, but based on what we can do if we solve the DOS
problem. I was just thinking today that we could create an Internet
Service Browser, that discovered any service available over the
internet, utilising ServiceUI, with which users can interact. Just like
Web servers and Web browsers, a River Service browser, wouldn't need to
implement service (unless it advertised trusted services perhaps), it
could be a lightweight app for minimal download. It would be the web
browser for services. This could be done using DNS-SD to discover
Unicast addresses of Lookup services. This would render the app store
model obsolete, anyone could advertise their service applications with
their own lookup service. It would blur the lines between applications
and internet web sites. We would also need delayed unmarshalling of
proxy's or partial unmarshalling (only deserialize Entry's) until the
desired service is found.
I'm wondering how we could use PGP Certificates web of trust and utilise
JAAS to associate with local Principals? Would these local Principals
have standard names, representing levels of trust? For maximum trust
you would expect the Service to authenticate with all these Principals.
How could we authenticate the Service with these principals?
If a friend trusts and uses a service, can we use and trust that service
too? Might that trust be the number of Principals our friends
authenticates the service with? Or would we use a lesser trust? Could
this be a role of an extended lookup service, to find services that have
some kind of trust relationship? Or would it be some kind of trust service?
If we can spell out these trust levels, then the service implementer
knows which Principals are needed to gain certain permissions. These
principal based permission grants could be configured by default in the
client.
Services might also expect clients to authenticate with these services.
Any ideas?
Thanks,
Peter.
