|
|
|
|
|
||
|
|
|
This is version 5.
It is not the current version, and thus it cannot be edited. DRAFT FOR COMMENTS The SEEK Certificate Authority needs to provide authentication credentials for a large number of users distributed across multiple institutions, and also be trusted and manageable. The Knowledge Network for Biocomplexity project has already established an LDAP-based authentication system for a group of over 5000 scientists. The current institutions participating in this system are the National Center for Ecological Analysis and Synthesis (NCEAS), the Long Term Ecological Research Network (LTER), the Partnership for Interdisciplinary Studies of Coastal Oceans (PISCO), the University of California Natural Reserve System (UCNRS), and the Organization of Biological Field Stations (OBFS). It is a distributed system based on referrals so that each organization manages its own set of users. Referrals are set up to institution-specific LDAP servers that are run by administrators that can be trusted to maintain the security of the LDAP tree. This LDAP system is password-based, but the SEEK EcoGrid needs to utilize X.509 certificates for GSI authentication. Thus, some modifications would be needed to use this system. For the SEEK EcoGrid, we propose to leverage this extant LDAP system, utilizing both the Distinguished Name formats and the referral system. We will store user and host certificates in the LDAP tree for easy retrieval.
Distributed CA ServersThe Root LDAP server for the SEEK EcoGrid will have a DN: o=EcoGrid,ou=seek.ecoinformatics.org,cn=EcoGrid CA This CA will in turn sign certificates for a set of subordinate CAs that will actually manage the user accounts and the LDAP tree. These will include:NCEAS: o=EcoGrid,ou=nceas.ucsb.edu,cn=NCEAS CA LTER: o=EcoGrid,ou=lternet.edu,cn=LTER CA PISCO: o=EcoGrid,ou=piscoweb.org,cn=PISCO CA UCNRS: o=EcoGrid,ou=ucnrs.org,cn=UCNRS CA OBFS: o=EcoGrid,ou=obfs.org,cn=OBFS CA DN FormatDistinguished names for each of the participating organizations will follow a prescribed format, namely:NCEAS: uid=mjones,o=NCEAS,dc=nceas,dc=ucsb,dc=edu LTER: uid=mjones,o=LTER,dc=lternet,dc=edu PISCO: uid=mjones,o=PISCO,dc=piscoweb,dc=org UCNRS: uid=mjones,o=UCNRS,o=ucnrs.org OBFS: uid=mjones,o=OBFS,dc=obfs,dc=org Other institutional formats will be added as needed. Our goal is that all of the DN formats will contain a uid attribute and an o (organization) attribute, which allows us to easily create referrals in the tree. The suffix portion of the DN can vary by organization, although we recommend using the domain component (dc) syntax as it is consistent and known to be unique.
Adding New CA serversNew institutions that wish to participate in the EcoGrid will need to provide both a trustworthy CA and a trustworthy LDAP installation. The new institution can then contact the **note: who do they contact?** in order to register their CA and have it be listed in the root EcoGrid node. We are also considering requiring each CA node to run a grid service registry node to distribute this functionality across a wider set of servers. More details on this to follow.
End-user toolsFor a certificate-based system to be effective, we need to make it simple for users to request certificates and install both the public and private keys in appropriate locations. I think we shoul dbuild a simple web-based system for a user to generate a certificate request, send it to the correct CA, and retrieve the signed certificate from the CA. This means that there needs to be a mechanism for the CA to check the validity of the request: this probably can occur through a combination of email and phone contacts to the scientist. In larger organizations such as LTER, we may want to delegate even further down the tree to individual LTER sites so that the CA managers have personal knowledge of the end users.
One immediate issue surfaces: how do we manage private keys? Private keys need to be created on the client side for privacy reasons, but installed in many possible locations. For example, we expect many people to interact with the system using Kepler. Kepler needs a mechanism to generate key requests, and store and manage private keys. Even with this, users will still encounter problems trying to run Kepler on other desktops (where the key isn't present), or run other applications that use different key sotrage approaches. One potential solution to this is to use a centralized key management service such as http://grid.ncsa.uiuc.edu/myproxy/ MyProxy
EcoGridCommunity
|
| This material is based upon work supported by the National Science Foundation under award 0225676. Any opinions, findings and conclusions or recomendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation (NSF). Copyright 2004 Partnership for Biodiversity Informatics, University of New Mexico, The Regents of the University of California, and University of Kansas |
. THe problem with MyProxy and other centralized schemes is that there needs to be a password based mechanism for obtaining the certificate, and so the whole system is still based on a centralized authentication module, which certificates are designed to bypass.
