Re: [DotGNU]How to authorize?

[Peter Minten]

James Michael DuPont wrote:
> --- Peter Minten <address@hidden> wrote:
>
> > Hi folks,
> >
> > AFAIK there hasn't been much work on the authorization mechanisms in
> > DotGNU for 
> > the last year. 
>
>
> thats completly right !
>
>
> > With DGv1 approaching it seems to me that it's
> > important to have 
> > a clear view on this.
>
>
> Yes, with all respect, I think you are over-engineering this one peter!
>
>
> Lets look at what I see as the goals on an authentication system :
>
> 0. Make it easy to authenticate for the *programmer*, make it easy for
> them to declare "use-cases" or "sections" that maybe controlled easily.
>
> 1. Protect the webservice *provider*, make it simple for them to adjust
> the rights on various operations after the program is deployed.
> That means to protect the webservice from stupid users as well.
>
> 2. protect the *users* from attacks

I think the order is wrong. My order would be (1, 2, 0), the security of the 
provider is most important, then the security of the user, and finally the 
ease-of-use for the programmer. Security is more important than having an 
easy-to-hack system.

> in that order.
>
> For the making it easy, we need a central, server side component that
> handles all the authentication, that the webserver author trusts.

DGEEMACS :-)

> We dont need to make a global passport system in the first round, 
> just allowing a server provider to trust another or share an
> authentication system given a secure communcations channel.
>
> I think that we need to make it simple  : 
> 1. If a user is not trustworthy, and does not have a secure
> communcations channel, then they need to be put onto a more secure
> environment than a user who is well known. 

More limited enviroment you mean?

> 2. If a user has bad passwords (dictionary attack), then we will just
> downgrade the account untill they fix the problem.

Yes.

> 3. If a user loses thier data, it is not as much as a problem as when
> the system is corrupted.

Certainly.


> > Given these problems I'm strongly for the following approach:
> > * Each user has a private key he/she drags along on a floppy or a
> > similar 
> > physical medium.
>
>
> I dont agree : when you are on the road, at a web terminal, you dont
> have the luxury of a disk drive. You dont have the ability to use
> anything but the keyboard.

Hybrid solution: use password only for most webservices and public/private key 
for the really important ones (bank accounts, etc). I'll explain this further in 
another mail.

> > * Each user has an account with an Auth Server. In that account
> > another 
> > public/private key set is stored.
>
>
> I dont know if you need to have the private key on the auth server. It
> may be fine to store the public key, if they can access that via ssh,
> it should be fine.

You need the private key to confirm that it's you who's calling.

> > * If the user connects to the Auth Server from an IP address (and/or
> > some extra 
> > info like username) that's not one of the usual addresses of the user
> > an extra 
> > password is needed (password must be reasonably secure (GNU/Linux
> > login password 
> > kind of secure)).
>
> That makes sense!
>
>
> > * To access a webservice the user must use the key on the Auth
> > server.
>
>
> That makes sense, but as a simplification of the 
>
>
> > * Last but not least a block command can be given by the user to the
> > Auth server 
> > with a reasonably secure password. The block command makes it
> > impossible to use 
> > the private key until the super-password (20 char string) has been
> > entered. The 
> > block command also automatically signals the user. Note that the
> > block command 
> > does not revoce the private key stored in the account (to avoid
> > abuse).
>
>
> good idea.
>
> I would suggest starting by defining what we want to support and
> defining an abstract class model in terms of a web service that
> represents the API of the security model.
>
> here is a shot :
>
> 1. create user
> 2. create groups.
> 3. create critical section/ use case
> 4. assign user to group
> 5. assign access to critical section to group
> 6. Check if user has access to section
> 7. broadcast changes in rights to systems affected.
>
> all of this could be modelled as a webservice, and all can implemented
> as some form of webservice......

Hmm, this reminds me of Forum. In Forum you have users which can be put in 
groups and you have documents that can be accessed by certain users and groups.

Anyway, you seem to be thinking of doing on the webservice level what I'm 
thinking of doing on the Auth Server level: security levels. I think it's safe 
to say that some parts of webservices need a higher security level, and that 
some webservices as a whole need a higher security level. What if we would 
combine that. Say you have three security levels, going from midly secure 
(password) to extremely secure (public/private key combined with biometric). 
Most webservices will be level 1 (midly secure), but some other webservices or 
parts of them may be level 2 or 3 (though 3 is kinda Pentagonish :-). Now you 
also have an auth level, the level with which you are logged into the Auth 
Server. Then the rule is that you can't access a webservice (or part of it) with 
a level that's higher than your auth level.

To make the system more flexible the user should have the power to fake a 
security level for a certain webservice.

This system can be implemented very programmer-friendly, and it's also highly 
user-prone and crack-prone. I believe it should also be doable with MACS since 
the MACS agents simply need to get a security level number to work with this.

Now let's see how I expect this took in real webservice code (DG-Scheme of 
course :-):

(define plus ;(a b)
 (webservice
   :security-level 1)
 (\ (a b)
  (+ a b))

(define move-money ;(from to)
 (webservice
   :security-level 2)
 (\ (from to)
  ...))

It might be useful to discuss auth stuff this weekend. 1600 UTC on Saturday 
sound like a good time? (mds, cds: good time for you too?)

Greetings,

Peter