Re: [DotGNU]Signing Webservices ?

[James Michael DuPont]

Just some thoughts as well :

1. Internal data structures, internal apis, these are going to have a
different license than the public apis?

2. As to the validity of a function for execution, is is possible to
make function calls that are checked by the dotgnu runtime? 

3. The penalty for loading must be on the startup, when a webservice is
registered to run, the validity must be established. The signing idea
is good.

Basically the person running the server must trust the person writing
the webservice. That means like a browser operator who accepts a
certificate, the server admin must accept the certificate of the
program that is to be executed. 

The idea is that certain functions in the program are run under
different trust levels.... That is something that is supposed to be
provided by SEE?

mike

--- Chris Smith <address@hidden> wrote:
> There is a requirement for some classes of webservice to be able to
> 'break 
> out' of the sandbox and have access to low-level DGEE resources such
> as the 
> Goldwater message queue API etc.
> 
> If certain webservices are allowed to do this it makes the design of
> the dgee 
> administration services a lot simpler, also the Abdabi front-end
> webservices.
> It also means that we can extend the functionality of the DGEE by
> adding 
> webservices - so we're using the DGEE to support the DGEE :o)
> 
> For the DGEE to allow webservices access to strictly private internal
> 
> resources it needs some machanism by which it may 'trust' the
> webservice.
> 
> Possible solutions include signing, known message digests etc.
> 
> Whatever solutions are proposed the DGEE _cannot_ impose a penalty on
> 
> webservice invoking because it has to verify the webservice each
> time.
> 
> When the DGEE VM's load a webservice and are about to invoke it to
> satisfy a 
> request it must set a security level for that webservice to control
> what 
> internal resources it can see (This is different to the whole concept
> of 
> sandboxing the filesystem etc.. that cannot be done this way without 
> intercepting calls to the OS etc.. anyway, that's another discussion
> :o)
> 
> So when we have a webservice in a buffer in memory, how can we know
> it's one 
> of a set of known 'trusted' webservices that are basically part of
> the DGEE 
> infrastructure ?
> 
> [ An idea occurs to me... every webservice has a dgmx resource file. 
> This 
> file contains a notion of an owner, and a public key and will
> probably be 
> signed.. perhaps we can do something with that?
> Perhaps 'lowlevel' webservices need to be signed by the DotGNU
> group.... but 
> how will that work if you're building from src?
> Or  even these 'lowlevel' webservices live under a special private
> namespace.  
> The DGEE recognises this and fetches them from a very private an
> local area 
> on disc instead of the resource manager.]
> 
> Hmm, I'm happiest with the latter idea as it's the simplest and
> probably as 
> secure as anything else especially if this chosen namespace is
> strictly 
> private.
> 
> Hmm, I've started to think out loud.  Sorry :o)
> 
> (Note these webservices are not 'installable' like normal webservices
> - they 
> are part and parcel of the DGEE and cannot be added or removed).
> 
> 
> It's on the table for discussion.
> Thoughs, ideas, and fix-everything solutions greatfully received.
> 
> Chris
> 
> -- 
> Chris Smith
>   Technical Architect - netFluid Technology Ltd.
>   "Internet Technologies, Distributed Systems and Tuxedo Consultancy"
>   E: address@hidden  W: http://www.nfluid.co.uk
> _______________________________________________
> Developers mailing list
> address@hidden
> http://dotgnu.org/mailman/listinfo/developers

=====
James Michael DuPont
http://introspector.sourceforge.net/

__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com