Thanks you comments are all much appreciated.
I'm having some thoughts about a ServiceRegistrar that is only a
downloadable proxy without a server, that contains only the marshalled
smart proxy instances of Services, that a single host provides, decided
prior to deployment. Sort of like an advertising medium found using
discovery.
In other words, a static ServiceRegistrar smart proxy.
This would allow all languages to participate in providing services, in
untrusted uncontrolled networks, using any Protocol they want. To work
where Surrogate doesn't, in environments, where there may be no
Registrar at all.
It would require a standard tool for developers to create the Serialized
form of the Registrar, containing the Marshalled Proxy's of the Services
that are going to be advertised. We could provide a standard download
codebase for the Static Registrar, the implementing developer would need
to create codebases for his / her service smart proxy's.
The problem of course is, how do you provide security for the client,
when you don't know what protocol the Service is using. I'm thinking
that it is simpler to deny trust. The codebases, however they are
attained, would need to advertise their size, in an Entry. The codebase
download would be aborted if the codebase size exceeded the advertised size.
Even without trust, and a restriction on codebase size, a misbehaving
Service Proxy can enter an endless loop, perhaps it should be
encapsulated inside a Security Layer Delegate, that runs a time limited
thread that executes the Proxy methods on the clients behalf, if the
proxy doesn't return within a set time limit, it terminates the proxy's
thread and throws an IOException.
When you think about the possibility of Permission's being advertised in
the jar file, if it was signed by a trusted developer, and there was a
way for the codebase to also indicate if it uses, a communication
protocol with privacy and integrity (another Entry?), you could grant
that codebase some Permission's but you still couldn't trust who or what
was on the Server end of that proxy, even if the communication was
private. However it does allow enough trust to be established to
authenticate the Service
You might say that there's a flaw in the above, a protocol that is
considered secure at the time of development may no longer be secure
when the client access the Service.
There is a simple way to fix this without un-abstracting the underlying
protocol used, it is simply another service that developers use to
advertise codebase implementations with security flaws, with a list of
permissions that if revoked, will prevent the security attack.
Of course you'll need to look at the code from my latest commit to see
how this is possible ;)
Thoughts? What have I missed?
Cheers,
Peter.
Gregg Wonderly wrote:
I agree, doing both would be the best choice of implementation.
Gregg Wonderly
Christopher Dolan wrote:
Best would be to block on both client and server side. Client to
help performance and server to prevent malicious intent. Server side
would be the minimum implementation.
Chris
-----Original Message-----
From: Patrick Wright [mailto:pdoubl...@gmail.com] Sent: Monday, June
28, 2010 3:17 AM
To: river-dev@incubator.apache.org
Subject: Re: ServiceRegistrar
On Mon, Jun 28, 2010 at 10:11 AM, Tom Hobbs <tvho...@googlemail.com>
wrote:
Does this not hook into the security discussions on internet-visible
services?
You can satisfy your use case with authorisation levels and just not
give
"everyone" the authority to register services. To my mind, this seems
cleaner (although not necessarily better or easier), than having two
breeds
of ServiceRegistrar.
Just a thought--it seems to me you would want to block this on the
client side, to prevent DDOS attacks on the LUS if the LUS is visible
"globally". Block all attempts to register with a locally-generated
and thrown exception (via smart proxy returned by LUS on lookup).
Patrick
