a aaaa model to support science gateways with community accounts

CONCURRENCY AND COMPUTATION: PRACTICE AND EXPERIENCEConcurrency Computat.: Pract. Exper. 2007; 19:893–904Published online 10 October 2006 in Wiley InterScience (www.interscience.wiley.com). DOI: 10.1002/cpe.1081

A AAAA model to supportscience gateways withcommunity accounts

Von Welch1,∗,†, Jim Barlow1, James Basney1,Doru Marcusiu1 and Nancy Wilkins-Diehr2

1National Center for Supercomputing Applications (NCSA), University of Illinois at Urbana-Champaign,1205 W. Clark Street, Room 1008, Urbana, IL 61801, U.S.A.2San Diego Supercomputer Center (SDSC), University of California at San Diego, MC 0505,9500 Gilman Drive, La Jolla, CA 92093-0505, U.S.A.

SUMMARY

Science gateways have emerged as a concept for allowing large numbers of users in communities to easilyaccess high-performance computing resources which previously required a steep learning curve to utilize.In order to reduce the complexity of managing access for these communities, which can often be large anddynamic, the concept of community accounts is being considered. This paper proposes a security modelfor community accounts, organized by the four As of security: Authentication, Authorization, Auditing andAccounting. Copyright c© 2006 John Wiley & Sons, Ltd.

Received 15 August 2005; Revised 19 January 2006; Accepted 8 March 2006

KEY WORDS: security; portals

1. INTRODUCTION

Science gateways have emerged as a concept for allowing large numbers of users in communities toeasily access high-performance computing resources that previously required a steep learning curve toutilize. In order to reduce the complexity of managing access for these communities, which can oftenbe large and dynamic, the concept of community accounts is being considered. Unlike group accounts,where a number of users log directly in to a single account, a community account is an account shared

∗Correspondence to: Von Welch, National Center for Supercomputing Applications (NCSA), University of Illinois at Urbana-Champaign, 1205 W. Clark Street, Room 1008, Urbana, IL 61801, U.S.A.†E-mail: [email protected]

Contract/grant sponsor: NSF (TeraGrid Project)

Copyright c© 2006 John Wiley & Sons, Ltd.

894 V. WELCH ET AL.

by a community of users who all access the account through a science gateway, which allows thecommunity itself to authorize individual users, removing the burden from the resource provider.

A community account has a number of differences in its security model from traditional single-useraccounts. In this paper we propose a security model for community accounts, organized by the fourAs of security: authentication, authorization, auditing, accounting (AAAA). We start with a detaileddiscussion of the motivation for community accounts, and then discuss our model in terms of each ofthe AAAA areas. We include a survey of current work and conclude with a discussion of open issuesand future plans.

2. MOTIVATION FOR COMMUNITY ACCOUNTS

Traditionally, users of high-performance computational resources have interacted with those resourcesat a very rudimentary level—they obtain authorization (i.e. an account) and some amount of allocation,then they log in and interact with the resource through a low-level interface (e.g. a command-line shellor ftp client). While this method of interaction provides these users with a great amount of control overhow they use the resource, e.g. they can compile their own applications and do fine-grain debugging,it has two drawbacks: (1) these low-level interfaces have a very steep learning curve, placing a largeburden on users to learn how to use the resources; and (2) it requires the resource provider to setup andmaintain state (typically an account) about each user utilizing the resource, which can be a burden foruser communities that are large and/or dynamic.

Web-based Portals have emerged as a mechanism to overcome the first drawback, by providing notonly a graphical means for allowing the user to express their desired actions, but typically an interfacethat is tailored to the user’s application domain. However, such portals typically do not overcome therequirement for users to obtain traditional accounts on the computational resources to which they grantaccess. Hence, while the portal has served as an interface between the users and the resources, it hasnot played a substantial role in the underlying security relationships between the user and the resourcesand so the second drawback mentioned previously remains.

Science gateways seek to take portals a step further and aid users in their relationships with thecomputational resources by obtaining a community account on the resources and allowing users toobtain access on resources by obtaining an account on the science gateway. There are a number ofbenefits to this approach.

(1) In many cases, a science gateway will allow access to resources at a number of organizations;this allows the user to avoid having to obtain multiple accounts to use the science gateway.

(2) There is an expectation that the science gateway, by virtue of allowing the user to perform verylimited actions (compared to them having a traditional account with shell access) can have alower bar for granting accounts than direct access to the resources.

(3) It abstracts the resources used, allowing resources to come and go without the involvement ofthe user.

(4) It distributes the burden of account management from the resource owner to the communityrunning the science gateway. This can allow the community to react more quickly to their ownchanges in membership, and can allow for scalability as it removes the resource owner as apotential bottleneck.

Copyright c© 2006 John Wiley & Sons, Ltd. Concurrency Computat.: Pract. Exper. 2007; 19:893–904DOI: 10.1002/cpe

A AAAA MODEL 895

Figure 1. Conceptual model for traditional user access to compute resource. All aspects of security (authentication,authorization, auditing and accounting) are handled by the compute resource.

3. OUR MODEL

Our model of having community accounts is based on a sharing of AAAA responsibilities andprivileges between the resources and the community operating the science gateway. In the standardaccount mode (Figure 1), a user’s authenticates directly to a target resource and all subsequentauthorization, auditing and accounting operations are performed by the resource. Even with the usergoing through a Web portal as an interface with the resource, this model is basically unchanged.

In our community account model (Figure 2), the science gateway plays a significant role in thesesecurity relationships, acting as an active agent in establishing trust between the resources and theusers. The community establishes with each resource an account with the resources along with anallocation and a set of authorization privileges for use by their science gateway. During day-to-dayuse, the science gateway authenticates and authorizes users, passing their requests on to the resources.The resources service the requests, using the community account, owing to their trust of the gateway.

In the following subsections we examine this model for each area of the four As. Authentication andauthorization are intertwined and we discuss them together. In either case the user’s authenticationto the science gateway could be accomplished through a number of existing portal authenticationmechanisms such as MyProxy, PubCookie or Shibboleth.

3.1. Authentication and authorization

Users are normally authenticated by a resource as a step that allows for establishing their authorizationprivileges, as well as for auditing and account. As a precursor, a user is usually registered by a site,during which time the site creates an account for the user (or equivalent state), and collects contactinformation regarding the user to allow the site to contact the user in the future (e.g. in the course


896 V. WELCH ET AL.

Figure 2. Our security for science gateway access to compute resources. Authentication is outsourced to thegateway. The gateway also participates in the authorization, auditing and accounting processes.

of investigating suspicious activity). Normally the site running a resource handles authentication,authorization and the preceding registration. In our science gateway model, the site out-sources thisprocess to the gateway. In this model the site decided the level of authorization for the community as awhole. The community then sets privileges for each of its members.

We discuss two possible modes by which authentication and authorization can take place: transitivelythrough the science gateway, and through the use of authorization credentials.

3.1.1. Transitive mode

In the transitive mode, the user authenticates to the science gateway and the science gatewayauthenticates to the resource using its own identity credentials (e.g. SSH RSA key, GSI certificate).The resource trusts the science gateway to have correctly authenticated and authorized the user and atruntime has no knowledge of the user’s identity.

Authorization is determined by resource policy on the community as a whole, i.e. on the privilegesgranted to the community account. The community enforces authorization on individual users by whichrequests it passes on to the resources. The resources have no concept regarding with which user agiven request is associated or what privileges the community grants to that user; they only can associaterequests with a community.


A AAAA MODEL 897

3.1.2. Authorization credentials mode

In the authorization credentials mode, the user has identity credentials of their own (issued by either thecommunity, the resource owner, or a third party) and the science gateway augments these by providingauthorization credentials that are supplied to the resource along with the user’s identity credentials.The presentation of these authorization credentials relieves the resource of having to maintain stateregarding the user.

In this mode the resource knows the identity of the user, but does not need an a priori state regardingthe user as the authorization policy regarding the user is contained in the authorization credentials.The community and the resource owners have an agreement in place that the resource will enforce thepolicy expressed in these credentials. Typically the resource owner will also set a maximum permissiblepolicy for any community member, meaning the policy enforced is the intersection of the resourceowner policy for the community and the policy expressed by the community for the given user.

Examples of services providing such credentials are CAS [1], VOMS [2] and the authorizationservice being developed by Indiana University as part of LEAD [3].

3.1.3. Comparison of authentication modes

The transitive mode is simpler to implement as the resource does not need to understand how to parseand enforce authorization credentials, which requires enhanced software not ubiquitously availablefor all services. However, because the resource has no knowledge of the user identity, auditing andaccounting are more difficult, as we discuss in the subsequent sections. The transitive mode, also,does not allow a site to deny access to individual users (due to suspect credentials abuse or the user’snon-conformance to an AUP or other policy in the past).

3.2. Auditing

In the event that the resource owner notices actions involving the science gateway that seem malicious,it is expected that the actions will be investigated to determine their cause so that appropriate action canbe taken in response. The resource owner typically will lead this investigation, as they are accustomedto and more able to perform this role today‡. Depending on whether the transitive or the authorizationcredential mode of operation, as described in the previous section, is in use, auditing will vary slightly.

In the transitive mode of operation, the site will only be able to audit at the community level and notbe able to distinguish which user caused a particular action to be initiated. This implies that site andthe science gateway need a method of identifying each action invoked by the science gateway in such away that the science gateway can map it back to a user it authenticated. The contact information neededby the site will influence the information gathered at registration by the science gateway (as describedin Section 3.1). There is no standard mode of identifying a request made by a science gateway to aresource today, indicating this is an area where further work is needed. Currently the best availablemethod is manually to correlate the timestamp of the request, full command and arguments in the logs

‡We could envision larger communities taking a lead role, but we believe that resource owners will continue to take the leadmost often and so concentrate on that scenario.


898 V. WELCH ET AL.

on the science gateway and resource (note that this implies accurate clocks on both). This scenario iscomplicated even more during simultaneous use of the gateway by multiple users

In the authorization credential mode of operation, the resource can log the identity of the user.However, the resource owner may still need to contact the community for the registration informationin order to contact the user, as the identity alone does not provide contact information and the resourceowner may not have the user in their user database (which would only be the case if the user had anaccount at the resource owner’s organization outside of the community science gateway).

3.3. Accounting

The community will typically have an agreement with the resource provider which grants thecommunity some allocation of consumables (cycles, disk, bandwidth, etc.) on the resources madeavailable to the community. The community may wish to divide up this allocation among its membersbased on some community policy.

To divide up the allocation among its members, the community needs to know how much eachmember has used. Because the resources used by the science gateways do not keep state regardingthe individual users (and even if they did, a user’s total usage would be distributed over a number ofresources) the science gateway is the natural place to keep track of each user’s total usage. This requiresthat the resource communicates the total consumption of each request on its completion back to thescience gateway. There is currently not a widely available means of performing this, however, the GGFUsage Records Working Group [4] has a specification for a message to carry such information.

A second issue is that if a user has a small amount of allocation left, the science gateway may wantto ensure that a request does not go beyond that allocation. This implies some means of communicatingthis restriction along with the request to a resource. This is currently an area that requires further work.

4. SURVEY OF CURRENT WORK

In this section we provide a survey of current work in instantiating distributed security models inthe high-performance computing community. The first section describes work between the NationalCenter for Supercomputing Applications (NCSA) and the San Diego Supercomputing Center (SDSC)to establish requirements for portal developers and administrators. The second section describescurrent efforts to establish a service level agreement between TeraGrid resource providers and sciencegateways. The remaining sections describe a variety of related technological efforts. Table I gives asummary of how these efforts map back to the four security areas.

4.1. CyberInfraStructure Partnership portal policy and standards

The CyberInfrastructure Partnership (CIP) is a collaboration between the NCSA and the SDSC toperform common cyberinfrastructure development. Security officers from both sites have developed apolicy and set of standards for portals that utilize CIP resources [5]. The intention of this policy is ‘toprovide assurance to Resource Providers and users that the portals will provide appropriate access to,and use of the resources provided, and maintain accountability for the access and use’.


A AAAA MODEL 899

Table I. Summary of technologies and their mapping to the four security areas.

Technology Authentication Authorization Auditing Accounting

GlobusWorkspaceManagementService

Allows forsandboxing ofmultiple users

PURSE Registers andauthenticatesusers

GAMA Registers andauthenticatesusers

Integrates CAS

CAS Fine-grainauthorization todata via GridFTP

XPOLA Fine-grainauthorization toWeb services

OGSA LoggerSystem

Interfaces forlogging

AMIE System forexchangingaccountinginformation

The policy spells out specific requirements on portals, including the following:

(1) the portal must provide contact information for personnel responsible for portal security as wellas predictable email addresses for portal services based on RFC 2142 [6];

(2) a regular (every two years) risk and vulnerability assessment on the portal system;(3) a list of information related to user requests that should be audited by the portal via the standard

Unix syslog mechanism and constraints on retention and storage of the information;(4) the requirement to work with resource administrators to ensure appropriate audit information

is available so that requests made to resource can be tracked back to the user that initiated therequest.

4.2. TeraGrid Science Gateways service level agreement

The draft TeraGrid Science Gateways Service Level Agreements (SLA) [7] defines a set of servicesprovided by TeraGrid resource providers to portals utilizing TeraGrid resources, and a set of


900 V. WELCH ET AL.

responsibilities for the Gateway staff. The SLA describes both TeraGrid services provided to thegateways as well as gateway responsibilities.

Services provided include:

(1) ability to access all TeraGrid resources and software including hardware, software, communitysoftware areas for staging gateway applications across TeraGrid, visualization resources and datacollections (including hosting capabilities);

(2) publicized interfaces for compute job submission and usage tracking;(3) listing of provided services and their network ports. Listing of available ports for gateway use;(4) advertised certificate acceptance policy, capability to have gateway certificates accepted by

TeraGrid;(5) support for portal personnel to report and receive resolution on any problems with TeraGrid they

encounter including discussions on biweekly calls and support from the Science Gateways areadirector. Ability to request additional resources and services;

(6) accounts that can be used by the gateway to run applications for all members of a givencommunity;

(7) auditing and accounting capabilities to allow processes spawned by the gateway to be associatedwith specific portal logins;

(8) still under investigation: Web services capabilities, workflow tools.

Work continues on the SLA draft. Currently gateway responsibilities mimic those outlined in the CIPportal requirements document described in Section 4.1. In order to compete successfully in the peerreview process, gateways will need to capture usage, success and perhaps publication information fromtheir users.

4.3. Globus toolkit workspace management service

When sharing a single common community account multiple users will not have sandboxing from eachother (in terms of processes interacting or protection of data). For many science gateways this will notbe an issue because what the users can do will be limited by the gateways such that these interactionswill not be meaningful. However from some gateways this may be an issue. A possible solution to thiswould be the exploration of a dynamic account mechanism that creates a new, temporary Unix accountfor each process invoked by the gateway.

Version 4.0 of the Globus Toolkit includes a Workspace Management Service [8] that allows fordynamic creation and management of workspaces, which are currently implemented as Unix accounts.This has the potential to allow community users to run concurrently on a single resource while stillbeing sandboxed from each other by the normal protections provided by the operating system toprocesses running in separate accounts.

4.4. PURSE and GAMA

Science gateways require a mechanism for managing community membership and granting access tocommunity resources. Two Web portal systems are now available to fulfill this need: Portal-BasedUser Registration Service (PURSE) [9] and Grid Account Management Architecture (GAMA) [10].The Earth System Grid (ESG) has been using PURSE successfully since 2004, serving a community


A AAAA MODEL 901

of hundreds of users. PURSE is now being adopted by other projects, such as LSST. The GAMA wasdeveloped for use by the Geon and TeleScience projects and is available for use by others.

Both systems allow users to fill out an online application form to register for access to communityresources. An administrator reviews the form and approves or rejects the request. For approvedrequests, the system then creates X.509 credentials for the user and stores them in a MyProxyrepository [11]. When users later log in to the portal, it obtains an X.509 proxy credential from theMyProxy repository for the user, allowing the user to authenticate to secure resources.

PURSE supports fine grain authorization for file access via Community Authorization Service (CAS)SAML assertions (CAS is described in a subsequent section). The PURSE administrator can associateusers with one or more groups, which are mapped to resource access policies in an authorizationdatabase. When users log in to the portal, PURSE embeds a CAS SAML assertion in the user’sproxy certificate indicating the user’s rights. The user can then access data resources via CAS-enabledGridFTP servers through the portal interface. The GAMA developers plan to add CAS support toGAMA in the future.

4.5. Community authorization service

CAS [12] is a component of the Globus Toolkit that allows for the issuance of fine-grain capabilitiesto community users in order to grant them the ability to access community resources. CAS works byissuing an SAML authorization assertion [13], signed by a trusted service, which grants to its bearerone or more privileges (typically the ability to access or create files). As described Section 4.4, CAS canbe integrated with portals or science gateways to allow the community to issue capabilities and performper-user access control on community resources. An example of such an approach can be found in theprototype infrastructure [14,15] being developed for the Large Synoptic Survey Telescope [16].

4.6. XPOLA

XPOLA [17] is an authorization service developed at Indiana University that is conceptually similarto the previously described community authorization service (it differs primarily in its administrationmodel, which is more peer-to-peer oriented, and its focus on providing access to Web services asopposed to data). XPOLA can be integrated into a portal and used to provide fine-grained authorizationto community members through the issuance of SAML assertions.

4.7. Distributed logging

Distributed logging mechanisms could allow science gateways to share log events with resourceproviders as the events occur. The Open Grid Services Architecture (OGSA) [18] working groupof the Global Grid Forum has identified the need for standardized logging services in Gridenvironments. Horn et al. propose an OGSA Logger System [19], based on the proposed WS-ResourceFramework (WSRF) [20], that provides a set of component interfaces for logging data in a distributed,heterogeneous computing environment. The Logger System serves as the intermediary between logartifact producers and consumers, addressing the fundamental requirements of support for legacylogger systems, persistency of log records and standard schema for log records.


902 V. WELCH ET AL.

4.8. TeraGrid AMIE work

The TeraGrid Account Management Information Exchange (AMIE) software system provides thecapability for resources to manage and track usage by individual users. AMIE is based on the GGFUsage Records specification [4] and is used by TeraGrid to provide a distributed accounting mechanismacross all of its resource-providing sites so that an individual users usage can be tracked across multipleresources.

With respect to AMIE, the science gateway’s community allocation would be represented as asingle user. In order to track usage by individual community users, the science gateway would need toimplement an interface to AMIE to exchange the appropriate information describing community usersand their usage.

One model for leveraging the AMIE software system would be for the science gateway to rely on theend resource to report community usage to AMIE on an individual basis by providing the appropriateuser information to the end resource for each science gateway/end resource request. This approachwould also require development on the end resource to accept and process this information and mapthe usage from the community account to the individual user that would then in turn be reported to theAMIE data base. Once the data exists in the AMIE database queries about the community account andcommunity users could be performed using existing query tools already in use.

Another approach for leveraging the AMIE software system would be for the science gateway torely on the end resource to report community usage back to the science gateway that in turn wouldbe responsible for reporting individual resource usage to the AMIE software system. This approachwould require the same development on the end resource to accept and process information aboutwhich community user is initiating a connection and map the usage from the community account tothe individual user. Additional development on the end resource in this model would require the usageinformation to be sent back to the science gateway instead of being reported directly to the AMIEsoftware system. Again, once the data exists in the AMIE database, queries about the communityaccount and community users could be performed using conventional, existing query tools already inuse.

5. OPEN ISSUES

We briefly describe a number of additional challenges regarding AAAA in science gateways andcommunity accounts.

(1) Standardization of community-resource owner agreements: the community and the resourceowners need to agree on a number of issues. A standard ‘template’ for such agreements wouldexpedite this process. Some issues that need to be agreed on include: what contact informationfrom users will be collected and how often will it be refreshed; how will users be routinelyauthenticated; what forms of usage by the community and its users will be acceptable; and how(and when) can the resource owner contact the community in the event of suspicious activity orincident involving the science gateway.

(2) Policies regarding group accounts: group accounts are often disallowed, often at high levels(e.g. funding agencies) and these policies will often be applied to community accounts.Such policies need to be clarified so as to allow community accounts on the bases that through


A AAAA MODEL 903

the cooperation of the community, they provide missing audit information that group accountslack.

(3) Restricted accounts: it is expected that often the gateway will be running a limited range ofapplications in the community account. The site may use technical means to restrict the accountand limit accidental or malicious abuse of the account. Standard mechanisms for doing so shouldbe determined and documented.

(4) Community administrators: the community needs to configure and maintain applications anddata deployed in the community account. This could be done via group membership, allowinga number of users (who have individual logins on the resources) to access data and programsaccessible by the community account. A process by which these community administrators canbe enabled needs to be experimentally determined and documented.

(5) Manageability: there are a number of challenges related to manageability, such as allowingaccess to the auditing and accounting information only to appropriate personnel (taking userprivacy into account), allowing for the monitoring of the gateways for reliability, delegating usermanagement to appropriate members of the community, etc. We only list these issues here, andplan on addressing them in future work.

(6) Risk analysis: while there have been risk analysis of portals and compute resources, the twoworking in combination as described in this paper should be taken on.

(7) Standardization and broad adoption of auditing and accounting messages and interfaces: to allowfor correlation and sharing of auditing and accounting messages, having standard interfaces forboth the gateway and computing resource to use for these functions would allow for sharing andcorrelation between the two. At a minimum methods for recording job submission, user loginand job completion and charged resources would be needed.

(8) Detection of malicious activity by a gateway: currently, no automated process exists to detectwhen a gateway is compromised and is attempting to compromise a computational resourceutilized by the gateway. Given what would seem to be rather constrained usage of the resourceby the gateway (at least compared to normal users with shell access), research into abnormalitydetection could be fruitful. Having a common methodology for sharing logs between the gatewayand the resource would benefit this activity as actions could be correlated between the twoand observed behavior that does not match the logs would be an obvious sign of inappropriateactivity.

(9) Adoption: administrators and those responsible for the security of computational resourceswill be understandably reluctant to accept the outsourcing of key security functionality.Some technical mechanisms such as restricted accounts mentioned previously in this section willallow administrators to mitigate their risk of adopting this model. Additionally, strong policieswill be needed laying out expectations for the operators of science gateways in the event ofsecurity incidents. These mechanisms, coupled with some history of successful operation andscience successes, will motivate broad adoption.

ACKNOWLEDGEMENTS

This work was funded by the NSF TeraGrid project, under both the Grid Integration Group and NCSA ResourceProvider efforts, as well as the NCSA NSF CORE proposal.


904 V. WELCH ET AL.

REFERENCES

1. Pearlman L, Welch V, Foster I, Kesselman C, Tuecke S. A community authorization service for group collaboration.Proceedings of the IEEE 3rd International Workshop on Policies for Distributed Systems and Networks, Monterey, CA,2002.

2. EU DataGrid, VOMS Architecture v1.1, 2003. http://grid-auth.infn.it/docs/VOMS-v1 1.pdf.3. Gannon D. Personal communication.4. GGF Usage Records Working Group. https://forge.gridforum.org/projects/ur-wg/.5. CIP/NCSA Portal Policy and Standards Draft (V1.0 and V1.2, respectively).

http://www.ncsa.uiuc.edu/UserInfo/Security/policy/portals/PortalPolicy.html [10 August 2005].6. Crocker D. Mailbox names for common services, roles and functions. RFC 2142, IETF, May 1997.7. Science Gateways Service Level Agreement.

http://users.sdsc.edu/∼wilkinsn/science-gateways/TeraGrid Science Gateways Primer.txt [10 August 2005]8. GT4.0 Contribution: Workspace Management Service.

http://www.globus.org/toolkit/docs/4.0/techpreview/wms/ [14 August 2005].9. Foster I, Nefedova V, Ahsant M, Ananthakrishnan R, Liming L, Madduri R, Mulmo O, Pearlman L, Siebenlist F.

Streamlining Grid operations: Definition and deployment of a portal-based user registration service. Journal of GridComputing 2006; 4(2):135–144. DOI: 10.1007/s10723-006-9047-3.

10. Bhatia K, Lin A, Link B, Mueller K, Chandra S. Geon/telescience security infrastructure. SDSC Technical ReportTR-2004-5, San Diego Supercomputing Center, August 2004. Available at:http://www.sdsc.edu/techreports/TR-2004-5-G-telsci.pdf.

11. Basney J, Humphrey M, Welch V. The MyProxy Online Credential Repository. Software—Practice and Experience 2005;35(9):801–816. Available at: http://www3.interscience.wiley.com/cgi-bin/fulltext/110541011/PDFSTART.

12. Foster I, Kesselman C, Pearlman L, Tuecke S, Welch V. The Community Authorization Service: Status and future.Proceedings of Computing in High Energy Physics (CHEP ’03), La Jolla, CA, 2003.

13. Security Assertion Markup Language (SAML) 1.1 Specification, OASIS, November 2003.14. Plante R, Loftis B. A VO-friendly, community-based authorization framework, part 1: Use cases, requirements, and

approach. http://us-vo.org/pubs/files/CommunityAuthorizationP1.pdf [September 2005].15. Plante R. A VO-friendly, community-based authorization framework, part 2: The single organization.

http://us-vo.org/pubs/files/CommunityAuthorizationP2.pdf [September 2005].16. Large Synoptic Survey Telescope. http://www.lsst.org/lsst home.shtml [January 2006].17. Fang L, Gannon D, Siebenlist F. XPOLA: An extensible capability-based authorization infrastructure for Grids.

Proceedings of the 4th Annual PKI R&D Workshop, Gaithersburg, MD, April 2005.18. Open Grid Services Architecture Working Group. Global Grid Forum. http://forge.gridforum.org/projects/ogsa-wg/

[July 2006].19. Horn B, Balakrishnan H, Maniampadavathu BT, Warnes J, Elko DA. A logger system based on web services. IBM Systems

Journal 2004; 43(4):723–733. Available at: http://www.research.ibm.com/journal/sj/434/horn.html.20. The WS-Resource Framework. http://www.globus.org/wsrf/ [July 2006].


a aaaa model to support science gateways with community accounts

Documents