river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: ServiceRegistrar
Date Mon, 05 Jul 2010 13:35:48 GMT
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:pdoubleya@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 <tvhobbs@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
>>
>
>



Mime
View raw message