Re: [Auth][PG-Proposal] <revised> dotGNU authentication and authorization subsystem. (fwd)

[Rob Knapp]

On Thursday 12 July 2001 15:42, you wrote:
> I had someone send me e-mail asking me to post this to the list, since
> they couldn't find it in the archives, so here you guys go.
>
> -----------------------------------------------------------------------
> Project:        dotGNU authentication and authorization subsystem
> Proposed Mailing List name:     address@hidden
> Description:
>
>         The purpose of this project will be to find a replacement for a
> single server/entity control over authentication (i.e.  passport) that
> will allow the following.


This looks fairly similar to something that I was trying to work out for
GnosisLIMS(a laboratory information management system).  The idea is to 
enable laboratories to easily share information with each other and their
customers.

This needs a fairly rigorous authentication system due to the sensitive 
nature of the data. (While most labs don't do anything sensitive, enough do 
to be concerned.)

The quick-n-dirty method I was going to use is actually pretty simple:
Heavy encryption
A DNS-like server
LDAP-like repository
Personal permission system

This is going to be a little hard to describe so let:
The client(C) be the system needing authentication information
The client security server(CSS) be the server that handles security for the 
client or it's entity(person/bussiness/cat).
The entity security server(ESS) be the security server of the entity with the 
information
The entity(E) is the entity(system/person/bussiness) about whom the 
information pertains.
The personal permission system (PPS) is a system that allows the entity to 
set policy about who/what and where data is transmitted. For example, I might 
tell my PPS that my wife has access to all of my information, but that Dirk 
Stronginthearm has no access (or that I get prompted for each request).

[note: I'm assuming for the sake of simplicity that ESS and CSS expose the 
same apis, hooks and protocols. In other words, they serve the funciton of
retrieving and suppling security info).]

Basically a client would pass a string to the client's security server.  
Something like(this of course would be encrypted):
auth://request-datum&123456789ABCDEF/bankacounts/checking
(the number is a key identifying the entity).

The client's security server then would track down the server responsible for 
entity 123456789ABCDEF, and put the client in direct contact with
the entity security server. Much like DNS, and in many ways solving the
same problem(although gnutella may be a better approach to follow).

The the ESS communicates with the PPS whether such information can be 
tranismitted to the client. It may even prompt the user if such a transaction 
is OK.

Once the information is confirmed to be allowable, the ESS goes to the 
repository and retrieves the nesscessary info.

The problems I ran into where:
1) What kind of encryption to use
and
2) How to ensure that requests are not spoofed.

It seems like a system like this would meet the criteria if the last two 
points are found.  I was looking for a system I could strap together from
mostly existing parts and pre-existing GPL'd pieces since it was not
the main point of my project. So, it may end up being a worthless design for
the needs of the dotGNU folks, but what comes out of dotGNU might be
very usefull for me :) so I thought I send my ideas your way.

I hope this helps, and if not I hope it doesn't hurt,
RobK