| Lines 20-21 were replaced by lines 20-21 |
| - The Root LDAP server for the SEEK ~EcoGrid will have a DN:\\ \\ |
| - {{ |
| + The Root LDAP server for the SEEK ~EcoGrid will have a DN: |
| + {{{ |
| Line 23 was replaced by line 23 |
| - }} \\ |
| + }}} |
| Lines 26-33 were replaced by lines 26-33 |
| - 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\\ |
| - }}\\ |
| + 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 |
| + }}} |
| Lines 36-43 were replaced by lines 36-43 |
| - Distinguished 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\\ |
| - }}\\ |
| + Distinguished 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 |
| + }}} |
| Line 55 was replaced by line 55 |
| - 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. |
| + 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/]. |
| At line 56 added 3 lines. |
| + 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. |
| + |
| + |
