Re: [DotGNU]Authorization and Security

[Chris Smith]

Just a few lightweight comments from a Webservice execution point of view - 
and these might be slightly blinkered :o)

On Sunday 20 Jul 2003 00:45, Mario D.Santana wrote:

> On Tuesday, July 15, 2003, at 07:08 AM, Mike Peters wrote:
> > In terms of DotGNU and Webservices what we need is to:
> > 1. Protect data and programs outside of the webservices execution
> > environment from the webservices we are running.
>
> This sounds like a sandbox type of thing.

Yep - webservices can be protected from each other by the DGEE itself - it's 
one of it's design goals - they all run in seperate processes.  However, how 
webservice data is stored has not been defined really, so I don't know how to 
answer this issue... DGEE will sandbox currently (alas it's a little 
complicated to setup and has some issues, so has been disabled) and it 
sandboxes the whole dgee and not on a 'websevice [set]' level.
More thought needs to go into this.

> > 2. Protect the webservices we are running and their data from programs
> > running outside the execution environment.

If we consider the Unix environment, this is probably pretty much protected as 
is - unless you're root ?
Again the same problem with data.
OF course, data could be in a database as opposed to files on disk - so some 
sort of access control could be employed.  But WS's may want data on disk, 
and this troubles me...... and when we start thinking distribution.... sigh.

> > 3. Protect webservice Foo and its data from webservice Bar and its
> > users.

Again the DGEE protects webservices from interfering from each other by 
running them in seperate processes.  Does that have a bareing here?
Data... if you're talking about storage then again this has a whole sea of 
discussion coming.

> > There should also be a system for auditing and logging connections and
> > usage.
>
> MACS is extremely verbose.  0.8 will have a more structured audit log
> and viewer.  There are also sophisticated real time log analysis and
> reporting tools planned for the not-too-distant future.  So for the
> DGEE, using MACS would take care of this.  For individual applications,
> this is a thing for the individual developers to consider -- by
> choosing MACS, their applications get the same benefits as the DGEE.
> And for System.Security, the MACS model would perform all its auditing
> as a side-effect.

The DGEE has good logging.
For security auditing though and auditLog is required.  This can be handled 
internally by the DGEE if required and any applications/Webservices running 
in the DGEE can - if required/allowed - perform audit logs.  I don't know how 
public this would be - I presume only architectural componets of the security 
system/dgee would have access to this interface.

> > It seems to me that the thread 'How to Authorize?' resulted from a
> > confusion as to whether the thread was discussing DotGNU authorization
> > or administrative authorization of the execution environment (ie the
> > DGEE) itself. [...]
>
> After clearing this up with Mike (melzo on irc,) my response is that I
> think the DGEE's auth should be a component-specific implementation of
> the general DotGNU auth policy, designed to interoperate with other
> DotGNU components.  I have no idea what a the general DotGNU auth
> policy should look like, though.  :-/

I agree.
There are two distinct areas of athentication within the dgee.
1) Authentication _with_ the dgee so that the dgee can authorise access to ITS 
services (administration etc)
2) Authentication with webservices (or groups of) running _within_ the dgee.  
This is application level, but could be facilitated via some dgee level 
components on behalf of applications so they don't have to do all the work 
themselves.


Just random bits :o)


Cheers
Chris

-- 
Chris Smith
  Technical Architect - netFluid Technology Ltd.
  "Internet Technologies, Distributed Systems and Tuxedo Consultancy"
  E: address@hidden  W: http://www.nfluid.co.uk