Re: [DotGNU]How to authorize?

[James Michael DuPont]

--- Peter Minten <address@hidden> wrote:
> James Michael DuPont wrote:
> > --- Peter Minten <address@hidden> wrote:
> > 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.


OK, I see your point. But consider this :

1. if it is easy to use, people will use it.
If you have enough users and a clear and simple way to declare the
security cases. If this is difficult and does not have support of the
hackers, then it does not matter how good the security is, no one will
use it. 

That is the case with many of the good security models, that is why we
have some many simple authentication protocols, because of the lack of
a simple programmatic interface.

2. When you have enough users, then you will get more implementations.
This is the idea of collecting clients and then going shopping for
those clients.

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

more limited, and with greater firewalls around it. Slower access
speed, whatever.

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

I dont think so. You only need to put the public key  in the
authorized_keys of ssh to connect to a server, it never needs to know
your private key. 

I think it is a bad idea to store the private keys on a central server
I dont want to have any repsponsability for caring for other peoples
private keys.

> > 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 just see how easy it is to create webservices, these interfaces are
prototypes for other more faster services.

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

Ok in c# you can make a security attribute that can be applied to many
objects.

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

I dont know if I will have time this weekend. 1600 is bad.

Breakfast club is better for me 07:00 CET.


mike

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

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