Science Gateway Credential Management
From TeraGrid Wiki
Science Gateways enable communities of users sharing a scientific goal to use grid resources through a common interface. Gateways require X.509 credentials for accessing grid resources securely. This document describes the different credential management scenarios currently employed by TeraGrid science gateways and the options/limitations that a gateway developer has in working with credentials.
Types of Gateways
Science Gateways take three common forms:
- Gateway users access grid services via a web portal.
- The gateway provides a mechanism to share resources between a community grid and TeraGrid.
- Gateway users run applications on their desktop to access grid services.
Credential Management Scenarios
From the perspective of TeraGrid resource providers (RPs), users access TG resources via science gateways using either individual credentials (i.e., issued to a single user who is known to the TeraGrid Central Database) or community credentials (i.e., issued to the gateway which is responsible for per-user tracking). Individual credentials allow TG RPs to track per-person resource usage using standard account-based techniques, based on the TG allocations process. Community credentials provide a more scalable approach, allowing user registration to be outsourced to the gateway, but TG RPs still require the ability to track per-person resource usage for accounting and security reasons. Gateways can combine both approaches, allowing registered TG users to access resources with their individual credentials and others to access resources via a community credential.
TeraGrid accepts certificates from multiple certificate authorities (CAs), operated by TG sites and other International Grid Trust Federation identity providers. TeraGrid users can manage how their certificate distinguished names (DNs) are mapped to their accounts on TG resources (see: Distinguished Names and SSO with Non-Default Certificates). TG and CA policies specify that credentials and accounts must not be shared between multiple users.
For portal-based gateways that support individual credentials, the portal must obtain access to the user's credentials to act on the user's behalf. Portals often use MyProxy for this. All TeraGrid users can obtain credentials from the TeraGrid MyProxy CA using their TeraGrid-wide username and password and this capability can be integrated into portals (such as in the TeraGrid User Portal). For accomplishing this programmatically in Java, see the Java CoG Kit JGlobus module's MyProxy API as in this example)
Alternatively, portals can allow users to upload their credentials to a MyProxy server (either the TG MyProxy server or a different server) for use by the portal. Or, portals can issue credentials for their users via PURSE or GAMA.
For bridge gateways, it has been envisioned that community grid users could use their individual credentials to access TG resources directly or via a batch job gateway. The users could be authorized via access control lists at the RP sites, downloaded from a VO membership service (such as VOMS), or alternatively could be authorized based on VOMS or SAML attributes that indicate community membership. The Open Science Grid, with its use of VOMS, was identified as a candidate for a bridge gateway. However, currently there are no bridge gateways in operation.
Desktop gateways can use credentials from the user's desktop or allow them to be downloaded from MyProxy.
TG-10 documents the TeraGrid Community Account Policy.
While community credentials and community accounts provide scalability by outsourcing user management to the gateways, they also introduce security issues that must be addressed:
- Identifying Users:
- When a TeraGrid resource is accessed using a community credential, it is more difficult for the TG RP to identify the individual user making the access since the credential's DN contains "Community User" and the TGCDB's record for that DN will also only identify it with a "last name" of "Community User". For accounting and reporting reasons, TeraGrid RPs would like statistics about the individuals accessing their resources. Additionally, RP security personnel would like the ability to trace back accesses to individuals in the case of a security incident. Furthermore, RPs may want to deny access to individuals or classes of users. Gateways are required to log each use of the community credential with IP address, UTC timestamp, and gateway username. It's also required for gateways to embed this information into a proxy of the community credential. Science Gateway Credential with Attributes page describes how to include these gateway user attributes in community proxy credentials so that they can be automatically recorded by the RP sites upon each gateway job submission.
- Isolating Users:
- Community credentials map to one or more community accounts on TeraGrid resources. When multiple individual users access those accounts via the gateway, their activities in the shared account(s) may conflict. For example, if a community user delegates credentials to a community account, other community users who are also accessing the community account should not have access to those delegated credentials. Community users should not be able to attack each other via the community account (for example, by installing Trojan executables in the account). Finally, we must recognize that science is a competitive pursuit and community members will have a reasonable expectation that their pre-publication results will be protected from disclosure to other community members. Thus, we must protect access to community user data between users in the gateway and the RP community accounts.
- Restricting Access:
- Community credentials are intended for use by members of an identified scientific community for identified scientific goals. They should not provide unfettered access to TG resources to anyone on the Internet. In particular, we must limit the ability for community credentials to be used for malicious purposes, by both limiting who has access (i.e., only valid community members) and what they have access to (i.e., a controlled set of scientific applications).
This discussion shows that the security issues for community credentials and community accounts are closely related. Gateways and RPs must work together to provide appropriate access to TG resources. On the RP side, restricted community accounts are an essential security measure for restricting access.
Science gateway community user DNs can be viewed in the centralized TeraGrid Gateway Entity Map.
A portal that is offering access to a shared community credential have the following options for obtaining and managing it.
- Acquire short-lived certificates via the TeraGrid MyProxy service:
- Upon approval/generation, a gateway's "Community User" TeraGrid account is granted the ability to generate a cryptographic key pair locally and request that the public key be signed by the TeraGrid MyProxy CA. The TeraGrid MyProxy CA returns the signed public key in the form of a "certificate", and the combination of certificate + private key results in the client's "credential", which can be used to prove authenticity (identity) of the owner. The credential generation can be done via a command line interface (e.g. using the Globus Toolkit) or programmatically (e.g. using the Java CoG Kit JGlobus module's MyProxy API as in this example).
- The TeraGrid MyProxy CA server issues certificates with a lifetime of no more than 11 days (see here for exact time), so the portal will require a type of on-demand or regular regeneration of the credential in order to avoid lapses in gateway services. If the TeraGrid password for the community account is to be stored on the gateway' server's filesystem, permissions should be set appropriately to prevent access from all but the user that runs the portal software.
- For sample Java code that offers some basic ability for automatically detecting expiring certificates and renewing them from MyProxy, refer to the SimpleGrid API, specifically the SimpleCred class.
- Of other interest is that releases of JGlobus after June 1, 2010 include the GRAM protocol "renew" message (see GramJob API), allowing one to delegate new credentials to a job after submission.
- Acquire a long-lived certificate from a trusted TeraGrid CA:
- To avoid the lifetime limitations on certificates enforced by the TeraGrid MyProxy CA, one can acquire a long-lived (one year) certificate from a TeraGrid-trusted CA (see: SSO with Non-Default Certificates). When using a certificate from the NCSA CA (obtained from ncsa-cert-request), you can avoid the "Set up a DN entry in each site's grid-mapfile" step since TeraGrid users automatically get a grid-mapfile entry corresponding to their NCSA-provided DN (for use with the default TeraGrid credentials). The lifetime of a proxy certificate created from a long-lived certificate (e.g. with
grid-proxy-init) is limited only by the lifetime of the long-lived certificate itself. This can significantly lower the frequency at which the community credential needs to be regenerated or monitored -- a daily cron job may be enough to monitor for upcoming expiration and email the administrator (for an example see Monitoring Certificate Expiry).
In either case, note that gateways are required to decorate community credentials on a per-user basis as described in Science Gateway Credential with Attributes.
See also: MyProxy Documentation for more options regarding integration of MyProxy with other software and web applications.
Downloading a community credential to a user's desktop is not recommended as this would give them full access to the community account.
Portal gateways utilizing community credentials are the most common type. It's recommended that they use the long-lived certificate approach to community credential management. It's also good if they're able to offer the ability for TeraGrid user's to use their individual credentials.
See discussion page.
- Science Gateways TeraGrid Science Gateways Program
- TeraGrid Science Gateways Wiki
- TeraGrid User Portal: Science Gateways
- A AAAA model to support science gateways with community accounts
- TeraGrid's GRAM Auditing & Accounting, & Its Integration with the LEAD Science Gateway
- GRAM4 Audit
- TeraGrid Core Services: allocations, authorization and authentication, accounting and accountability
- TeraGrid Community User Accounts and Community Account Thoughts
- TeraGrid Authentication and Authorization
- TeraGrid Distinguished Names
- TeraGrid Security Working Group
- Restricted Community Accounts
- TeraGrid User Responsibility Form: documents community account management requirements, including logging of each requester's IP address, timestamp, and username by the gateway
- TeraGrid Allocations Policies
- TG-10: TeraGrid Community Account Policy
- Science Gateways Admin Application Requirements
- AAA Testbed
- Science Gateway Credential with Attributes