A AAAA Model to Support Science Gateways with Community Accounts Von Welch1, Jim Barlow, James Basney, Doru Marcusiu NCSA
1 Introduction Science gateways have emerged as a concept for allowing large numbers of users in communities to easily access 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 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 by community of users who all access the account through a science gateway, which allows the community 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-user accounts. In this paper we propose a security model for community accounts, organized by the 4 A’s of security, Authentication, Authorization, Auditing, Accounting. We start with a detailed discussion of the motivation for community accounts, and then discuss our model in terms of each of the AAAA areas. We conclude with a discussion of open issues and future plans.
2 Motivation for a Community Accounts Traditionally, users of high-performance computational resources have interacted with those resources at 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 lowlevel interface (e.g. a command-line shell or ftp client). While this method of interaction provides these users with a great amount of control over how 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 large burden on users to learn how to use the resources; and (2) it requires the resource provider to setup and maintain state (typically an account) about each user utilizing the resource, which can be a burden for user communities that are large and/or dynamic. Web-based Portals have emerged as a mechanism to overcome the first drawback, by providing not only a graphical means for allowing the user to express their desired actions, but typically an interface that is tailored to the user’s application domain. However such portals typically require users to obtain traditional accounts on the computational resources to which they grant access. So while the portal has served as an interface between the users and the resources, it has not played a substantial role in the
1
Contact author:
[email protected], 217-265-7139
underlying security relationships between the user and the resources and so the second drawback mentioned previously remains. Science gateways seek to take portals a step further and aid users in their relationships with the computational resources by obtaining a community account on the resources and allowing users to obtain access on resources by getting an account on the science gateway. There are a number of benefits of 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 very limited actions (compared to them having a traditional account with shell access) can have a lower 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 of the user. 4. It distributes the burden of account management from the resource owner to the community running the science gateway. This can allow the community to react more quickly to their own changes in membership, and can allow for scalability as it removes the resource owner as a potential bottleneck.
3 Our Model Our model of having community accounts is based on a sharing of AAAA responsibilities and privileges between the resources and the community operating the science gateway. In the standard account mode, a user’s authenticates directly to a target resource and all subsequent authorization, auditing and accounting operations are performed by the resource. Even with the user going through a web portal as an interface with the resource, this model is basically unchanged. In our community account model, the science gateway plays a significant role in these security relationships, acting as an active agent in establishing trust between the resources and the users. The community establishes with each resource an account with the resources along with an allocation and set of authorization privileges for use by their science gateway. During day-to-day use, the science gateway authenticates and authorizes users, passing their requests on to the resources. The resources service the requests, using the community account, due to their trust of the gateway. In the following subsections we examine this model for each area of AAAA (Authentication, Authorization, Auditing, Accounting). Authentication and authorization are intertwined and we discuss them together.
3.1
Authentication and Authorization
Users are normally authenticated by a resource as a step that allows for establishing their authorization privileges, 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 contact information regarding the user to allow the site to
contact the user in the future (e.g. in the course of investigate suspicious activity). Normally the site running a resource handles authentication, authorization and the preceding registration. In our science gateway model, the site out-sources this process to the gateway. In this model the site decided the level of authorization for the community as a whole. The community then sets privileges for each of its members. We discuss two possible modes by which authentication and authorization can take place: transitively through 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 gateway authenticates 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 at run-time has no knowledge of the user’s identity. Authorization is determined by resource policy on the community as a whole, i.e. on the privileges granted to the community account. The community enforces authorization on individual users by which requests it passes on to the resources. The resources have no concept regarding which user a given request is associated with or what privileges the community grants to that user; they only can associate requests with a community.
3.1.2 Authorization Credentials Mode In the authorization credentials mode, the user has identity credentials of their own (issued by either the community, the resource owner, or a third party) and the science gateway augments these by providing authorization 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 state regarding the user. In this mode the resource knows the identity of the user, but does not need a priori state regarding the user since 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 the policy expressed in these credentials. Typically the resource owner will also set a maximum permissible policy for any community member, meaning the policy enforced is the intersection of the resource owner 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 authorization service being developed by Indiana University as part of LEAD [3].
3.1.3 Comparison of Authentication Modes The transitive mode is simpler to implement since the resource does not need to understand how to parse and enforce authorization credentials, which requires enhanced software not ubiquitously available for all services. However since the resource has no knowledge of the user identity, auditing and accounting 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’s non-conformance to an AUP or other policy in the past).
3.2
Auditing
In the event that actions involving the science gateway look malicious, it is expected that the actions will be investigated to determine their cause so that appropriate action can be taken in response. The resource owner will typically lead this investigation since they are accustomed to and more able to perform this role today2. Depending on whether the transitive or the authorization credential 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 not be able to distinguish which user caused a particular action to be initiated. This implies that site and the science gateway need a method of identifying each action invoked by the science gateway in such a way that the science gateway can map it back to a user it authenticated. The contact information needed by the site will influence the information gathered at registration by the science gateway (as described in 3.1). There is no standard mode of identifying a request made by a science gateway to a resource today, indicating this is an area where further work is needed. Currently the best available method is to manually correlate the timestamp of the request, full command and arguments in the logs on the science gateway and resource (note that this implies accurate clocks on both). This scenario is complicated 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 information in order to contact the user since the identity alone does not provide contact information and the resource owner may not have the user in their user database (which would only be the case if the user had an account 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 provide which grants the community some allocation of consumables (cycles, disk, bandwidth, etc.) on the resources made available to the community. The community may wish to divide up this allocation among its members based on some community policy. To divide the allocation up among its members, the community needs to know how much each member has used. Since the resources used by the science gateways do not keep state regarding the individual users (and even if they did, a user’s total usage would be distributed over a number of resources) the science gateway is the natural place to keep track of each user’s total usage. This requires that the resource communicate the total consumption of each request on its completion back to the science gateway. There is currently not a widely available means of performing this, however the GGF Usage Records working group [4] has a specification for a message to carry such information.
2
We could envision larger communities taking a lead role, but we believe that resource owners will continue to take the lead most often and so concentrate on that scenario.
A second issue is that if a user has a small amount of allocation left, the science gateway may want to ensure that a request does not go beyond that allocation. This implies some means of communicating this restriction along with the request to a resource. This is currently an area that requires further work.
4 Other Challenges We briefly describe a number of open challenges regarding AAAA in Science Gateways and community accounts. •
Standardization of community-resource owner agreements: The community and the resource owners need to agree on a number of issues. A standard “template” for such agreements would expedite this process. Some issues that need to be agreed on include: what contact information from users will be collected and how often it will be refreshed; how will users be routinely authenticated; 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 or incident involving the science gateway.
•
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 polices need to be clarified as to allow community accounts on the bases that community accounts, through the cooperation of the community, provide missing audit information which group accounts lack.
•
Restricted accounts: It is expected that often the gateway will be running a limited range of applications in the community account. The site may use technical means to restrict the account and limit accidental or malicious abuse of the account. Standard mechanisms for doing so should be determined and documented.
•
Sandboxing of multiple users: One downside to community accounts is that multiple users will not have sandboxing from each other (it terms of processes interacting or protection of data). For many science gateways we expect this will not be an issue because what the users can do will be limited such that these interactions will not be meaningful. However from some gateways this may be an issue. A possible solution to this would be the exploration of a dynamic account mechanism that creates a new, temporary Unix account for each process invoked by the gateway.
•
Community Administrators: The community needs to configuration and maintain applications and data deployed in the community account. This could be done via group membership, allowing a number of users (who have individual logins on the resources) to access data and programs accessible by the community account. A process by which these community administrators can be enabled needs to be experimentally determined and documented.
5 Bibliography [1] Pearlman, L., Welch, V., Foster, I., Kesselman, C. and Tuecke, S., A Community Authorization Service for Group Collaboration. IEEE 3rd International Workshop on Policies for Distributed Systems and Networks, 2002.
[2] EU DataGrid, VOMS Architecture v1.1. 2003. http://grid-auth.infn.it/docs/VOMSv1_1.pdf. [3] Personal communication with Dennis Gannon. [4] GGF Usage Records Working Group. https://forge.gridforum.org/projects/ur-wg/
