| Line 1 was replaced by line 1 |
| - __DRAFT FOR COMMENTS__ |
| + __DRAFT FOR COMMENTS__ |
| Lines 3-4 were replaced by lines 3-4 |
| - 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 SEEK Certificate Authority needs to provide authentication credentials for a large |
| + number of users distributed across multiple institutions, and also be trusted and manageable. |
| Line 6 was replaced by line 6 |
| - authentication system for a group of over 5000 scientists. The current institutions participating |
| + authentication system for a group of over 5000 scientists. The current institutions participating |
| Lines 8-13 were replaced by lines 8-13 |
| - 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. |
| + 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. |
| Lines 16-17 were replaced by lines 16-17 |
| - Distinguished Name formats and the referral system. We will store user and host certificates |
| - in the LDAP tree for easy retrieval. |
| + Distinguished Name formats and the referral system. We will store user and host certificates |
| + in the LDAP tree for easy retrieval. |
| Line 19 was replaced by line 19 |
| - !!Distributed CA Servers |
| + !!Distributed CA Servers |
| Lines 21-28 were replaced by lines 21-33 |
| - 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 |
| + {{{ |
| + 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 |
| + }}} |
| Line 30 was replaced by line 35 |
| - !!DN Format |
| + !!DN Format |
| Lines 32-43 were replaced by lines 37-53 |
| - 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 servers |
| - New 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. |
| + {{{ |
| + 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 servers |
| + New 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 tools |
| + For 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. |
| Lines 45-46 were replaced by line 55 |
| - !!End-user tools |
| - For 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 storage approaches. One potential solution to this is to use a centralized key management service such as [MyProxy|http://grid.ncsa.uiuc.edu/myproxy/]. |
| Line 48 was replaced by line 57 |
| - 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]. 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. |
| + 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. However, the certificate is still used to generate proxy certificates so that services can invoke new requests on behalf of the user, so some of the advantages of the GSI proxy certificate are maintained. For example, this will be especially relevant when running analyses through an environment like Kepler and a user invokes a computation through a grid service which in turn can invoke other grid services on behalf of the user by generating and sending another proxy certificate. |
| Lines 50-51 were replaced by lines 59-61 |
| - ------------------------------------------- |
| - [EcoGrid Back to EcoGrid Main Page] |
| + |
| + ------------------------------------------- |
| + [EcoGridCommunity] |
