Hi Mary,
I can imagine what the reasoning behind this specification is. While it may be
nice to do some kind of wildcarding based on the fields of the X.509 certificate,
this probably leads to a lot of users having numerous certificates since they may
belong to several different collaborations. I assumed that this is where akenti
comes in. If akenti could provide the ability of assigning individuals to various
groups and we did all of our authorization via akenti wouldn't that be a more
manageable solution? I don't know if web servers like appache are extensible in the
authentication/authorization mechanism. If they are then we could use akenti for
this purpose.
I agree that the certificates should contain more info such as the
person/server's primary affiliation just so you some inkling of who the person is.
But on the other hand if this was all tied into akenti then you could provide some
utilities for getting info about the certificate from the akenti database.
Of course, this is all based on the assumption that I know something about
Akenti which is a very bad assumption. Correct me if I'm wrong about what
functionality Akenti might provide in this area.
Cheers,
Tom
Mary Thompson wrote:
> Having just looked at the CA Policy for naming for the DOE Science Grid
> CA I would like to make one final argument for adding some flexiblity
> that would allow us to experiment with different forms of Certificate
> based authentication schemes.
>
> The current specification is:
>
> for user names
> dc=org,dc=doesciencegrid,cn=Mary R. Thompson 23678
>
> for server names
> dc=org,dc=doesciencegrid,cn=server.lbl.gov/FTP
>
> The two dc components are DNS domain components registered to ESnet for
> the Science Grid CA. Every user name is going to have 5 digits added to
> ensure randomness. The character part of the CN is supposed to represent
> the individual person. There are to be no shared certificates.
>
> I have two problems with this scheme. First, it does not allow a human
> reading a certificate to have much idea who the person holding the
> certificate is. The old X.509 org-person gave you enough information to
> feel like you knew who it represented.
>
> Second and much more important, it forces any site or application which
> wants to use these crendentials to make authorization decisions to have
> a complete listing of the DNs for every authorized individual, as there
> is nothing in the DN to group people for authorization pruposes. Thus
> anytime a new user joins a virtual organization, his DN will have to be
> entered in some ldap server, or CAS file, or grid-map file or some other
> mechanism. This is certainly one of the things that currently makes
> using Globus hard.
>
> I was hoping for some virtual organization element to be allowed so that
> the members of say the National Fusion Collaboratory could be recognized
> by their credentials and given access some subset of resources, e.g. the
> group Web pages. (The current version of apache/ssl lets you set access
> lists based on DN components). I would agree that for write access or
> access to expensive resources, you will want some scheme that itemizes
> all the allowed users. But we certainly found in the Diesel
> Collaboratory, that there were plenty of resources such as Web pages and
> running demo programs that we wanted to allow to all collaboratory
> members and guests, but not allow to random web browsers. This was
> easily accomplished by allowing access based on a credential signed by
> our CA and containing O=Diesel Combustion Collaboratory.
>
> Since the DOE SG CA will be signing certificates for several virtual
> organizations, I can not use the certificate alone, but will have to
> maintiain and consult a complete list of NFC users.
>
> Mary
>
> --
> ---------------------------------------------------------------------
> Mary R. Thompson <MRThompson@lbl.gov>
> Distributed Security Research Group (510) 486-7408
> Lawrence Berkeley National Lab http://www-itg.lbl.gov/~mrt
> ----------------------------------------------------------------------
>
> ===============================================================================
>
> This message was sent to the SciDAC National Fusion Collaboratory (NFC)
> workers list nfc-workers. Visit the Collaboratory at
> <http://www.fusiongrid.org/>.
>
> To unsubscribe from this list, please send a message to
> majordomo@fusion.gat.com with the following text in the *body* of the
> message: unsubscribe nfc-workers
>
> David P. Schissel: <schissel@fusion.gat.com> <http://fusion.gat.com/~schissel/>
===============================================================================
This message was sent to the SciDAC National Fusion Collaboratory (NFC)
workers list nfc-workers. Visit the Collaboratory at
<http://www.fusiongrid.org/>.
To unsubscribe from this list, please send a message to
majordomo@fusion.gat.com with the following text in the *body* of the
message: unsubscribe nfc-workers
David P. Schissel: <schissel@fusion.gat.com> <http://fusion.gat.com/~schissel/>
This archive was generated by hypermail 2.1.1 : Thu Feb 07 2002 - 15:40:41 PST