ServiceRegistrar

[Peter Firmstone <ji...@zeus.net.au>]

For a ServiceRegistrar implementation where you don't want to register 
Services (A static ServiceRegistrar used only for lookup) would 
returning a null ServiceRegistration suffice?  Or is this fraught with 
danger, has anyone ever tried it?

Use case:  You've got an internet facing Registrar and you don't want 
external Services to register.

Cheers,

Peter.

Re: ServiceRegistrar

[Peter Firmstone <ji...@zeus.net.au>]

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 <tv...@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
>>
>
>

Re: ServiceRegistrar

[Gregg Wonderly <gr...@wonderly.org>]

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 <tv...@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
> 

RE: ServiceRegistrar

[Christopher Dolan <ch...@avid.com>]

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 <tv...@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

Re: ServiceRegistrar

[Patrick Wright <pd...@gmail.com>]

On Mon, Jun 28, 2010 at 10:11 AM, Tom Hobbs <tv...@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

Re: ServiceRegistrar

[Tom Hobbs <tv...@googlemail.com>]

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.

Tom


On Sun, Jun 27, 2010 at 1:29 AM, Peter Firmstone <ji...@zeus.net.au> wrote:

> For a ServiceRegistrar implementation where you don't want to register
> Services (A static ServiceRegistrar used only for lookup) would returning a
> null ServiceRegistration suffice?  Or is this fraught with danger, has
> anyone ever tried it?
>
> Use case:  You've got an internet facing Registrar and you don't want
> external Services to register.
>
> Cheers,
>
> Peter.
>
>
>
>