[seek-dev] EcoGrid: GSI and certificate authority (CA)

Matt Jones jones at nceas.ucsb.edu
Sun Aug 24 16:38:37 PDT 2003


Raja, Dave, Bing, Jing, and other EcoGrid enthusiasts,

If the EcoGrid is to use OGSA as its infrastructure, it makes sense to 
use the Grid Security Infrastructure (GSI) for our authentication 
mechanism.  I have been exploring this with the GT3.0.1 install on 
dev.nceas.ucsb.edu, and earlier installs.  It seems like a good decision 
to me, but would engender some changes (minor?) in our current approach 
to authentication in the ecogrid query interface.

To use the GSI, we need a Certificate Authority that 1) we can trust, 2) 
is easy to manage, and 3) is accessbile (ie, SEEK admins can create new 
accounts easily without outside intervention).  I have installed and 
experimented with the SimpleCA certificate authority, and it seems 
pretty straightforward to administer it and sign certificates.  If we 
were to go this route, then we would need to:
   1) Establish a DN system for naming hosts and users throughout EcoGrid
   2) Set up and easy-to-use admin interface for the CA
   3) Write a detailed signing and authentication policy, and review the 
trust model that is implicit in it for flaws
   4) Create a system to store public keys for a large number of users 
and hosts (> 5000)

Here's a proposed DN format for the CA, hosts, and users (comments 
appreciated)...
For the CA:  o=EcoGrid,cn=EcoGrid Certificate Authority
  For hosts:  o=EcoGrid,dc=nceas.ucsb.edu
  For users:  o=EcoGrid,dc=nceas.ucsb.edu,cn=Matthew Jones

Our current KNB approach to using a distributed LDAP server works well 
because it leverages already existing directory services, and so we have 
over 5000 accounts in that system.  Generating a parallel system for 
certificates seems crazy, so I've been contemplating trying to store 
certificates in the LDAP system that we already have running. Of course, 
the KNB LDAP server uses different DN conventions 
(dc=ecoinformatics,dc=org,o=NCEAS,uid=jones), and so we would have to 
resolve those.  I'm fairly certain that could be done through simple 
referrals in the tree.  For stability, I suggest that we decide on this 
format early, formalize it, and stick with it (generating new certs for 
everybody would be a monumental pain).

We may want to explore the CAS (Community Authentication Service?) that 
has been proposed as an extension to GSI because of its mechanism for 
allowing management of trust relationships in terms of groups of users. 
  Are there any other existing systems that would make sense to explore?
NPACI's CA?   Other existing CA's?  MyProxy?

I would like to get a formal proposal worked out before the October 
All-hands meeting, so please provide feedback ASAP.  This is a 
fundamental architectural decision for EcoGrid, and I'd like as many 
people to consider it as possible.  So I suggest we follow something 
similar to the following steps:

1) Draft security policy and architecture
2) Build security prototype
3) Request public review of approach from ecology domain and others
     (e.g., anyone considering hosting an EcoGrid service)
4) Revise policy from feedback
5) Implement and test
6) Run community-wide vote on acceptance of approach for interested parties

Thanks in advance for your thoughts,
Matt





More information about the Seek-dev mailing list