SURAgrid Two-Tiered PKI AA System
SURAgrid has been looking at how to provide enhanced access management for applications
running on SURAgrid resources and eventual access to resources beyond SURAgrid. The means
to provide this new level of access should integrate as seamlessly as possible with SURAgrid’s
current system that is based on local campus authentication. What SURAgrid wants to add to its
authentication and authorization (AA) system is a means for users to continue to use their
credentials from recognized authoritative sources to access not only SURAgrid resources but
resources and services that may become available through gateways to other initiatives and
future grid-to-grid integration.
The solution being proposed is a two-tiered AA system that will support production services and
provides the basis for integration into a more global grid fabric while still being accessible to
SURAgrid participants whose local AA or grid deployment is still under development and would
typically not meet high-level assurance criteria. The use of the SURAgrid’s Bridge Certificate
Authority (BCA) is central to SURAgrid’s current authentication design and would be expanded
under the two-tiered model. SURAgrid’s original BCA and related policies and practices that
focused on accommodating a range of operations and use by applications that don’t require a
high LoA comprise will remain intact and will comprise the first tier in the new model. The
second tier - hardware, software and a companion set of policies and practices – will provide
AA at a higher LoA for applications within SURAgrid or integration with external initiatives.
The distinction between the two tiers is predominantly in the policies and practices for
SURAgrid and the participating campuses that will support the higher level of assurance. For
SURAgrid sites operating in the second-tier, a new (and still to be defined) SURAgrid approval
process will ensure the methods they use to locally authenticate and issue credentials are
consistent with relevant policy frameworks (e.g., PKI-Lite, TAGPMA, USHER Expected
Practices). The requirements will be outlined in a Policy and Practices document that addresses
topics such as how users are identified, how the CA private key is protected, and user key
management.
Figure 1 below defines the components and their functions within each tier.
Local
Authentication
Participant
CAs
The set of policies and processes a campus uses to positively identify local
users. Local authentication is incorporated and translated into SURAgrid
authentication.
Tier 1
Tier 2
Campuses authenticate their local
Campuses authenticate their local
users. SURAgrid does not monitor or users. SURAgrid ensures that the
approve the policies and practices its policies and practices used to
members use to authenticate their
authenticate are operating at the
users.
appropriate level of assurance.
SURAgrid participants use their own CA to issue digital certificates to their
users.
Tier 1
Tier 2
Campuses issue credentials to their
Campuses issue credentials to their
local users. SURAgrid does not
local users. SURAgrid ensures that
monitor or approve the policies and
the policies and practices used within
practices its members use to issue
the campus CA infrastructure
credentials.
correspond to the stated LoA.
1
SURAgrid Two-Tiered PKI AA System
SURAgrid
BCA
BCA Crosscertificate
Process
SURAgrid
User ID
Directory
Components
The BCA defines the trust relationship between institutions and enables the
relying parties at each institution to trust the certificates issued at other
participant sites.
Tier 1
Tier 2
The BCA is also an off-line computer
The BCA is housed on a dedicated
that is powered-on only when PKI
off-line Linux laptop, which is kept in
tasks need to be completed. This CA
a secure location and powered on to
operates under a set of practices that
cross-certify new sites.
support a higher LoA.
The BCA process results in a set of cross-certificates for each SURAgrid site.
When these cross-certificates are appropriately pre-positioned in participating
sites’ Globus installations, relying parties can trust the credentials issued by
other participants.
Tier 1
Tier 2
Campuses initiate the crosscertification process by following predefined steps. (See
https://www.pki.virginia.edu/suraThe participating site officially
bridge) Once appropriate
designates their AA operator.
communication is established, the
SURAgrid identifies this individual
participant places a signing request on
and establishes a secure out-of-band
a web server protected by a
mechanism for the exchange
commercial CA certificate. Certificate
cryptographic materials and operation
requests are moved to the BCA using
of the SURAgrid trust infrastructure.
a flash memory card, which is also
used to transfer signed certificates
from the BCA back to a networked
computer.
These IDs enable coordination between participating sites at the operating
system level, facilitate job accounting, enable mapfile and other Globus
automation.
Tier 1
Tier 2
Each SURAgrid member’s User
Admin creates ids for their users
Same as in Tier 1.
using a SURAgrid provided tool (see
https://www.pki.virginia.edu/suragrid)
An LDAP-based directory and support software automates the installation of
cross-certificates in order to work around some problems with the lack of
direct BCA support in Globus. The SURAgrid directory also includes the
SURAgrid user functionality to delegate user management to participating
sites, coordinate SURAgrid User IDs and Unix UIDs, and implement other
related functions.
Tier 1
Tier 2
Participating sites can leverage the
directory infrastructure to automate
AA functions, as a source of data, or
Same as in Tier 1.
to manage access using existing
campus mechanisms.
2
SURAgrid Two-Tiered PKI AA System
Figure 2 below shows a vision where, with some enhancements to Globus, SURAgrid and other grids could leverage the PKI trust
infrastructure that is being built within the higher education, federal government, and commercial sectors.
3