[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