Use of MyProxy for the FusionGrid

1
Use of MyProxy for the FusionGrid

• Mary Thompson
• Monte Goode
• GridWorld 2006

2
FusionGrid

• SciDAC Collaboratory to support experimental
  fusion scientists (2001-2006)
• Remote job execution -
• TRANSP, a large code written and maintained by
  Princeton Plasma Physics Lab (PPPL) scientists,
  run at several sites. Wanted to run it at just
  one site and allow remote access.
• Remote Data access
• Had a common data storage format and server
  software, MDSplus, written at MIT. Needed secure
  remote access.
• Remote participation in tokamak experiments
• Funded by DOE/MICS. Goal to advance both the
  fusion science and the computer science.
• Princeton Plasma Physics Lab, Princeton CS,
  General Atomics, MIT Plasma Fusion Science
  Center, ANL, LBNL, Univ. of Utah.

3
Motivation for MyProxy enhancements

• Started with GSI and self managed certificates
  issued by DOEGrids CA
• Web Interface to CA not optimal for GSI use
• export and reformat for use with GSI.
• renewals especially problematic
• Script interfaces exist but are brittle
• Fusion Scientists submit jobs from a variety of
  machines.
• need to login thru firewalls before they can
  submit a job

4
MyProxy for Long-term Credentials

• While MyProxy was originally designed to manage
  proxy certificates, it is happy to manage end
  entity certificates as well.
• DOEGrids CA policy prohibits third party
  possession of private keys.
• Needed new CA with a different policy
• FusionGrid could run its own CA software
• Could use an on-demand CA
• Implies another means to authenticate users
• ESnet agreed to run a separate CA with a policy
  that allowed private key storage on a secure
  server
• FusionGrid certificates are used within the
  FusionGrid for Globus job submission, MDSPlus
  data access, and access to secure web sites.

5
Credential Manager (CM)

• Web based interface for requesting, renewing or
  revoking certificates.
• Stores certificates and keys in collocated
  MyProxy server
• Server host is secured Linux server
• Few accounts, no unnecessary servers, patches
  up-to-date, located in machine room.
• Keys are arguably safer here than on users
  workstations

6
Credential Manager Use

• FusionGrid accepts new users via the request to
  the CM for a new certificate.
• Requires user name and password, contact
  information, purpose of joining the FusionGrid.
• Needs to be approved by a sponsor and issued by
  an RA.
• Once approved, the end entities credentials are
  stored in a MyProxy server. (the CredentialStore)
• User get proxy certificates authenticated by user
  name, password. (myproxy-logon)
• Note keys are encrypted by the password.
  Passwords are not stored on CM host.
• Dont need credential stored on the machine from
  which the Globus job is submitted.

7
Architecture and Basic Use Case
register
FusionGrid CA
Credential Manager (Apache/ CGI)
myproxy-logon
User information
FusionGrid service
End entity credentials
Done once
Once per 12 hrs
For each job submission
8
Proxy Renewals

• The most commonly used code in the FusionGrid
  (TRANSP) can have queue run times of up to
  several weeks.
• We set up a different MyProxy server to provide a
  proxy renewal service (proxyStore)
• The CM provides a CGI interface designed to be
  callable by a script to generate a medium lived
  proxy certificate, add it to the renewal
  proxyStore and specify which service may use it
  for renewal.
• Renewals by services are handled by the normal
  myProxy trusted renewers mechanism.

9
Architecture and Renewal Use Case
Credential Manager (Apache/ CGI )
1
5
User information
4
myproxy-logon
2
3
FusionGrid service
6
End entity credentials
Renewable Proxies
10
Why two MyProxy servers?

• The CredentialStore repository stores end-entity
  certificates with encrypted keys and provides a
  flexible user-oriented delegation policy.
• Anonymous delegation with password
• The ProxyStore repository stores proxies with
  unencrypted keys and allows for delegations by
  only a set of known services.
• The retriever must authenticate by certificate
  and be listed as an allowed retriever for the
  specific certificate.
• The proxy that the user gets has a maximum
  allowed lifetime of 2 weeks (could be shorter)
  and defaults to 12 hrs.

11
Servers are mirrored for robustness

• The three servers and their data bases are
  mirrored at LBNL and MIT to provide robustness in
  case of host or network failure at either site.
• The CM and end-entity is mirrored read-only, it
  can support proxy-logons but not new user
  registrations. The mirror is updated once every
  24 hours.
• The proxyStore is synchronized in both directions
  at 1 minute intervals, so that a renewable
  certificate can always be entered or delegated
  from.
• The client interfaces try the LBNL server first
  and then fail over to the MIT servers.
• Used twice in 2 years Security breach at LBL
  took all our machines off-line, network
  maintenance at MIT.

12
Portal Technology for FusionGrid

• FusionGrid has experimented with a Java portal,
  but having a single all purpose portal did not
  correspond to the realities of the VO.
• There already existed several web sites at
  different institutions, implemented in different
  technologies (not Java) each serving a single
  purpose.
• Monitoring
• Authorization
• Working documents
• Several potential job submission sites

13
Federated Portals

• What was needed was a common way to do
  authentication across all the Web sites.
• Must be simple for an existing Web site to
  implement
• PubCookie - an open source package using signed
  cookies can do this for web sites in the same
  domain, e.g. fusiongrid.org.
• We wanted to integrate PubCookie with the
  FusionGrid single-signon mechanism that used
  myproxy-logon.
• And enable Web sites to get proxy certificates
  for authenticated users.

14
Architecture and Portal Use Case
( 1 initial contact )
(5 with cookie)
login
(2)
Webapp Server (Apache)
PubCookie Login Server (Apache)
Authentication Plug-in
(6)
(3)
(4)
(7)
MyProxy ProxyStore
Delegate
Store
FusionGrid service
End entity credentials
Renewable Proxies pubCookie proxies
15
PubCookie - MyProxy integration

• Run PubCookie login server collocated with
  MyProxy server on cert.fusiongrid.org
• The first time a user goes to a Web application
  server, he is redirected to the PC login server
  to get a cookie.
• PC login server supports plugins for
  authentication.
• We added an authentication module that calls
  MyProxy with the username and password.

16
PubC-MyProxy authentication

• PubC login prompts the user for his FusionGrid
  username (GridId) and password.
• Calls MyProxy-logon which verifies the password
  and delegates a proxy
• Authentication module stores the proxy in the
  proxyStore named by the users GridId and enables
  it to be delegated by the list of known Webapp
  servers.
• PubC login server then creates, encrypts and
  signs the granting cookie and login cookie
  containing the GridId.

17
PubCookie single-signon process

• Normal pubCookie process is followed.
• The login cookie is stored in the users browser
• The granting cookie is passed to the requested
  appServer
• The appServer creates a site-specific signed
  cookie containing users GridId.
• All access to that server now have an
  authenticated GridId.
• The login cookie is used in subsequent access to
  other appServers
• This GridId can be used by the app server to get
  a delegated proxy to use for Globus job
  submission or to make authorization queries to
  the FusionGrid authorization server.

18
Summary

• Used a MyProxy repository to store long-term
  credentials
• Added some web interface and scripting frosting
  around the proxy renewal mechanism
• Integrated MyProxy and Pubcookie to enable
  single-purpose portals for job submission and
  other things.