Sim IJskes - QCG wrote:
Peter Firmstone wrote:
Anyone got any opinions about Lookup Service Discovery?
How could lookup service discovery be extended to encompass the
internet? Could we utilise DNS to return locations of Lookup Services?
For world wide lookup services, our current lookup service might
return a massive array with too many service matches. Queries present
the opportunity to reduce the size of returned results, however
security issues from code execution on the lookup service present
problems.
I haven't seen any world wide deployments yet, at least not on my bench.
:-) And i would like to reserve my definite judgement before i have had
an actual production deployment of such a service.
When we have several reggies running on the internet, it would be
handy to find them via DNS SRV records. It would only create an extra
layer of indirection. With DDNS zone updates one could build some kind
of super registry, but i would prefer just to code it in java.
About MDNS (Bonjour) SRV records. MDNS is a multicast protocol
so it has the same pattern as the multicast discovery as currently
implemented. In a broad sense one could suggest that this might suffer
from the same deployment issues as een MDNS discovery would suffer.
Except that MDNS is more mainstream and on more sites there might be a
working infrastructure(substrate?) for it. (like MDNS holes in personal
firewalls). But still MDNS does not work in the internet.
But anyhow, would this solve the problem. In order for a
world-wide-registry to work, wouldn't we need to have clearly defined
services? I wouldn't connect to a registry which i cannot verify for
source and meaning. To be honest, i can only look as far as using jini
scoped for projects under my control, and wouldn't dare to connect to
outside services, unless there are clear agreements.
Running Jini on a LAN, creates no problems, as the LAN is under
central authority. But to venture out on the internet, which services
would i like to expose? I guess we have to define internet-jini. Is
the internet a global anonymous crowd, or is the internet a way to
connect isolated LAN's? Or just a happy few, romaing the internet,
having the right certificate chain to identify them.
Internet-Jini: My thoughts are that it is a Global anonymous crowd,
where trust relationships are used to allow collaboration to occur in
proportion to the degree of trust established.
A Global Registry Service, provided it's interface only uses built in
Java or core River types, will never require remote code to be executed.
For Jini services to be distributed over the internet, they will require
signed bundles provided by codebase services and trust agreements.
Bundle signing creates an identity on which a level of trust is based,
predefined by agreement between parties. A service client can use,
signed, trusted bytecode, that doesn't originate from the untrusted
service (all services are initially untrusted until identified), then
the client can be assured that the bytecode used for unmarshalling is
trustworthy within the bounds of predefined trust agreement. Although
for full security we need to check Serialized objects defensively copy
and verify unmarshalled data (we need a source code auditing process for
serialization).
The client of a codebase service would have a trust relationship with
that codebase service ( A company might run their own codebase service )
and the codebase service would itself have trust relationships with
signers who upload code. A company might require a source code pass an
audit process for client code of service implementations prior to use.
The codebase service would itself sign the bundles if they are already
signed by fully trusted parties and have the correct message digest.
The trust relationships are based on the OSGi model of trust agreements.
Using bundles for client service code (currently provided in a single
jar file), might mean better code reuse, additional bundles can be
downloaded based on dependency requirements and package imports.
General purpose components could be vetted for security, performing
common functions for untrusted client code, enough to make code useable
without breaching security.
Clear trust agreements can be made between parties, companies etc, the
bundles downloaded can contain required permissions. Untrusted bundles
would be sandboxed and all downloaded bytecode would have to pass the
JVM verification process.
Once bytecode is verified, other verification processes can be used,
such as user authentication certificates, if required.
For this to succeed, Type must become divorced from originating codebase
URL's, hence the requirement for a codebase service. Marshalled Object
Type must be compared based on fully qualified class names and
originating bundles, based on OSGi's versioning system. Therefore, if
bundle version is compatible and the fully qualified class name equal,
then two marshalled objects have the same type.
Perhaps upon establishing the Software infrastructure, we could create a
staging area for submission of client bundle source code, for vetting
and signing by multiple parties?
Cheers,
Peter.
