Re: [DotGNU]How to authorize?

[James Michael DuPont]

--- 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

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.

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. 

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

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

> 
> A number of approaches are possible in authorization:
> * Password
> * Public Key Infrastructure
> * Biometric

* you can also use a rsa secureID like system.

> 
> Third dragging your private key along everywhere you go is
> rather irritating.
yes it is! It is impossible.

> For the third problem the middle man authorization software (the Auth
> Server) 
> can offer a solution by storing the private key on a remote server
> and letting 
> the server authorize on request of the user. That destroys the
> advantage of the 
> private key system (two data sets you need: key + passphrase)
> however.
> 
> Plain old password authorization is not good either since users tend
> to use 
> really dumb passwords like 'secret' or 'sparky'.

you can limit that, by trying to crack whatever is entered in...
making the passwords strong and authenticated.


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

> * 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.

> * 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......


miek

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

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com