Science Gateway Credential with Attributes Experience
From TeraGrid Wiki
This page records the experiences of gateway developers that have deployed the Science Gateway Credential with Attributes.
Asteroseismic Modeling Portal
GridAMP uses a single community account to perform all remote simulations, so the implementation is very straightforward.
When a user logs in to the website, the authentication instant is recorded in an append-only database table. Any submissions performed by the user during that session are then associated with that authentication record. The community credential is stored on a separate server that runs the back-end job management software. When the job manager performs any processing for the job, the SAML command-line tools are used to generate a new job-specific proxy certificate with the appropriate assertions.
Authentication instants and SAML assertion generations are also logged using other mechanisms (daemon text file logs and local + remote syslog) so that the database need not be trusted in the event of an incident investigation.
Biology and Biomedicine Science
The RENCI Bioportal has had attributes integrated with WS-GRAM Condor Glide-in job submissions since 2008.
Community Climate System Model TeraGrid Gateway
(experiences here)
Computational Infrastructure for Geodynamics
CIG submits their jobs to Lonestar using ssh. They need the gateway-submit-attributes command installed on Lonestar. Progress is blocked, waiting for that to be installed.
Computational Chemistry Grid
Attribute support for use with GRAM is integrated into new portal code scheduled for roll-out Apr 15 2010. Need to test with http://gstest.ncsa.uiuc.edu/.
Also need SSH-support and Gateway-Submit-Attributes for existing portal code.
Computational Science and Engineering Online
Deferred. Not an active TG gateway at this time.
DES
I'm working with Greg Daues (NCSA) on this. --Jbasney 21:07, 22 March 2010 (UTC)
TeraDRE
Deferred. Mainly serves Purdue students. Not using TeraGrid allocation.
Cyberinfrastructure for End-to-End Environmental Exploration Portal
(experiences here)
GEOsciences Network
(experiences here)
Linked Environments for Atmospheric Discovery
Attribute support is integrated, but TeraGrid allocation expired.
National Biomedical Computation Resource
Deferred. Not using TeraGrid allocation at this time.
National Virtual Observatory
(experiences here)
Network for Computational Nanotechnology and nanoHUB
nanoHUB uses the SAML tools package to inject user information into short term VOMS proxies. To protect nanoHUB users a hashed form of the user identifier is used.
Network for Earthquake Engineering Simulation
(experiences here)
Neutron Science TeraGrid Gateway
The test portal is generating attribute-based authenication for its jobs that run on the TeraGrid. On the week of Aug 24-28, this software will be released as the production portal. We have tested with gstest.ncsa and our attributes appear in the database.
Open Life Sciences
(experiences here)
Robetta
Robetta is actively running in their community account on the Purdue Condor resource. Robetta jobs are Condor glide-ins submitted through GRAM. Currently each glide-in potentially serves multiple gateway users, which makes gateway user counting tricky, because one "TeraGrid job" could be associated with multiple gateway users. The plan is to modify Robetta to link glide-ins to a single gateway user, either via Condor policy or by having each glide-in exit after running one job. Then Robetta can use the standard Science Gateway Credential with Attributes approach to adding gateway user attributes to the community credentials. --Jbasney 21:00, 22 March 2010 (UTC)
QuakeSim
(experiences here)
Science Gateway for Diffraction Facilities
Deferred. On hiatus. Mostly data management (GridFTP). Not job submission.
Social Informatics Data Grid
Using Swift workflow engine. Patched the Swift package to support gateway attributes, but the patch isn't included in the main Swift releases, which makes it difficult to maintain. Need to support jobs submitted from the command line.
TeraGrid Geographic Information Science
Implementation
GISolve uses MyProxy to manage its community credential. All user access is through GISolve portal. Therefore, portal server is responsible for issuing community credential for each user data transfer and job submission. GISolve portal's proxy management is implemented as a Java class org.gisolve.grid.security.SimpleGred. Whenever there is a Grid data tansfer or job submission, SimpleCred.get() method is called to fetch a valid Grid proxy. If there is no valid proxy or current proxy is expired, SimpleCred.logon() is called within SimpleCred.get() to contact TeraGrid MyProxy for a community proxy with one week lifetime. Otherwise, SimpleCred.get() returns current valid proxy. With this mechanism, a Grid proxy is shared for all gateway Grid activities.
To enable attribute-based authentication on GISolve, we first followed TeraGrid gateway credential wiki page to define the set of attributes to be associated with a Grid proxy. Gateway identity (https://saml.teragrid.org/gateway/gisolve), user name, email address, login client IP address, and login time are chosen as basic gateway user attributes. These attributes are obtainable in our portal programming model (currently, GridSphere is our portal server). Then we extended SimpleCred to include GatewayCredential as a class member. At time of user login, these attributes are recorded with the instantiation of a GatewayCredential instance within SimpleCred initialization. Each time SimpleCred.get() is called, GatewayCredential is used to attach gateway user attributes to the proxy.
Testing has been conducted between GISolve portal server and GridShib's test server gstest.ncsa.uiuc.edu.
Experience
Attribute-based authentication transition on GISolve is straightforward because we have a simple credential management mechanism: GISolve does not allow the use of personal credentials on gateway; all Grid activities are invoked via gateway portal; GISolve relies on MyProxy to store community credentials , instead of maintaining them locally. It took only two hours to finish the coding and another hour for testing on our development machine.
To minimize code change, we extended existing credential management code to include gateway crendential capabilities, instead of replacing current code with GatewayCredential-based implementations. User attributes are set once at the time of user login, and then are read each time a proxy is issued. We also use gateway user attributes to carry customized attributes specifically defined by our gateway, e.g., application job ID, workflow progress information, etc. Since we made minimum code change, future change of gateway user attributes will introduce little overhead on programming and operation.
Discussion
There are cases that might complicate the transition for a gateway: 1. Multiple credentials are managed on a gateway. In this case, ignoring non-community credentials might be sufficient 2. Multiple methods to fetch Grid proxies, e.g., MyProxy, local credentials, third-party credential management libraries. To minimize development overhead, we should not extend each method with gateway credentials. Since the proxy that is submitted with Grid jobs is eventually either GSSCredential or GlobusCredential (for TeraGrid only), a wrapper can be developed around the proxy to attach gateway user attributes. The wrapper can be implemented as either a static class (in Java or C++) or a shared object in web portal. If Grid proxies are created using command line, script commands can be developed as the wrapper.
TeraGrid Visualization
Using dynamic accounts on a non-TG-allocatable resource. No usage going to TGCDB.
