GRID Authorization Framework for CCLRC Data Portal Ananta Manandhar, Glen Drinkwater, Richard Tyer, Kerstin Kleese CCLRC – Daresbury Laboratory, Daresbury, Warrington, Cheshire, WA44AD, UK Email:
[email protected] As more resources are being made available over the Grid, authorization framework is increasingly becoming vital. The level of information returned needs to be based upon the privileges provided to the user. A few probable authorization frameworks that could be used over the Grid exist; however, have not been standardized yet in the e-science community. The authorization framework in the Data Portal is built similar to the VOMS approach. The issue of authorization is addressed by creating an authorization infrastructure at the resource provider’s end that is managed and controlled by the resource provider’s organization. This article discusses the probable authorization frameworks and defines the authorization framework that is being implemented for the Data Portal based upon the requirements from the various ongoing projects.
Introduction The CCLRC Data Portal [9] provides an infrastructure for discovering and accessing data resources over Grid environments. It utilizes web services in conjunction with Grid technologies and acts as a broker between scientists, facilities, data and other services by providing a transparent access to the various kinds of data kept in a multitude of systems and sites. One of the main issues that is being addressed in the Data Portal framework is in the area of security. Users accessing resources via the Data Portal need to be authenticated and authorized. For the authentication of users, the GSI architecture [8] is being used as in many other e-science projects. The GSI architecture provides a reasonably trusted mechanism for authenticating users and delegating authentication rights. Users wishing to access resources via the Data Portal maintain a proxy certificate in the My Proxy Server repository [7]. When the user logs into the Data Portal, a delegate proxy certificate is created via the proxy certificate stored in My Proxy Server. This delegate proxy certificate is then used by the data portal on behalf of the user in retrieving the requested data. The proxy certificate of the user helps in authenticating the request and verifying that request has been made by the user himself. However it does not specify what the user is allowed to retrieve. A direct mapping between the user’s distinguished name (DN) with the resource at the resource end, such as the use of a grid map file, aids in providing the capabilities of the user but is not scalable and becomes less
manageable as more resource servers are added coupled with the increase in users. It is seen that the resource providers are interested in making their resources available via applications such as Data Portal but would need a more manageable system to control and manage their resources that enables them to cope with the increase in users when they are plugged into the grid. Currently a few probable authorization framework that could be used over the Grid exist. The coming section briefly describes the three primary authorization frameworks that have been reviewed - Community Authorization Service (CAS) from the Globus project, Virtual Organization Management System (VOMS) from the EU Data grid project and EC funded PERMIS Role Based Privilege Management Infrastructure developed at Salford University. The next section discusses about the requirements that were deemed necessary for the Data portal and subsequently describes how the Data portal’s Authorization framework has been addressed.
CAS The Community Authorization Service [2], developed by the Globus Project, approaches the problem by allowing resource providers to delegate some of the authority for maintaining fine-grained access control policies to a trusted third party authorization server. This authorization server maintains a community policy database that contains the policies and privileges of the users. When a user requires to access a resource, it requests the CAS server with the capabilities (access privileges) that it requires. If the requested capability is consistent
with the community’s policies, the CAS server issues a restricted proxy certificate that contains the capabilities. The user then utilizes this restricted proxy certificate to authenticate with the resource provider for accessing the resource. The user’s request is then executed by the resource provider if the resource provider maintains a trust with the certifying CAS service and if the request has been authorized by the CAS server.
VOMS Another framework currently being developed by the European Data Grid to solve this issue is the VOMS authorization architecture [1]. The VOMS architecture tackles the issue by classifying authorization information into two categories. o General information regarding the relationship between the user and the Virtual Organization o Information regarding what the user is allowed to do at the Resource Provider.
pulls the User’s attribute certificate, and if necessary the policy Attribute certificate, from the public LDAP directories. It then verifies if the Attribute certificate has been signed by its trusted privilege allocated and provides the resource to the user based upon the permission granted by the Attribute certificate.
Requirements Analysing the structure of the resource providers and the future directions it is heading, it is seen that the important requirement to the Authorization infrastructure are that it has to be: Scalable It is quite inevitable that as organizations start collaborating more there would be an increase in users accessing their resources. The organizations need be able to scale up the number of users or resources without much additional administration overhead for them to be able to enjoy collaboration.
o
Manageable Adding or removing users or resources to the system or modifying user privileges to the resources need to be kept simple and intuitive for the organizations so that the overhead for collaboration does not increase. Also keeping users privileges manageable keeps the system more consistent and up to date, making them reliable.
o The VOMS server maintains the relationship between the user and the Virtual Organization as a set of roles that the user can present to the resource provider. When a user needs to access a resource, it requests the VOMS server for a pseudocertificate. The VOMS server provides the user with a pseudo-certificate that specifies the role of the user and time validity. At the user end, the user then creates a new proxy certificate containing the pseudo-certificate in a non critical extension of the proxy certificate. This proxy certificate is then used by the user to request a resource provider within that VO. Based upon the roles that have been assigned to the user by the VOMS server, the Resource Provider decides what level of access privileges is granted to the user.
PERMIS The Role based Privilege Management Infrastructure [3] developed at University of Salford also provides certain features in solving this issue. It provides an elaborate method of describing policies. These authorization policies are stored in X.509 attribute certificate which are placed in one or more LDAP directories. Attribute certificates storing user’s roles are created by the Virtual organization’s Privilege Allocators and are places on public LDAP directories. When a user accesses a resource, the Access Decision Module located at the resource
Preferably under the control of the resource end When it comes to the issue of security, organizations are wary of external parties accessing their resources. Organizations would prefer to have control over who have access over their data and up to what degree. They are not yet ready to trust third party organizations in authorizing their resources and prefer to keep control over their resources to keep them reliable.
o
Minimum intervention at the Data Portal layer As the Data Portal is a broker application between users and resource, it is best to pull authentication and authorization information from the resource provider’s trusted bodies and have Data Portal forward it to the resource provider along with the request. This keeps Data Portal away from being an addition point of security consideration.
o
such as the HPC portal [10,11] in conjunction. For example a user may retrieve a certain data set via the data portal and may then submit a job on the HPC portal. It would be easy for the user to do such operations if different Grid applications use the similar authentication and authorization strategies.
Ability to utilize existing Access Control Models Much of the data are stored in file systems, databases or other system which already have an elaborate access control features and many resources present already utilize these existing access control features in managing the level of information that need to be returned. It seems best to integrate the authorization information along with these access control mechanism in providing the level of information to be returned. o
Implementation While building the authorization framework, the issue of authorization has been addressed by creating an authorization infrastructure at the resource provider’s end that is managed and controlled by the resource provider’s organization. This relieves the Data Portal from having to take responsibility of authorization and also improves the resource provider’s trust in the request from the Data Portal as the authorization information is from its own Organizational Authorization server.
Ability to integrate with GSI The GSI is the standard means of authenticating users in the e-science community. It provides a trusted mechanism in authenticating users and delegating authentication rights. It would be useful for the authorization system to use GSI as the authentication mechanism. o
Future integration capabilities with other Grid related applications Users accessing data resources via the Data Portal may like to use other Grid applications o
It takes in many ideas from the EU Data Grid’s VOMS project as this architecture seems the most suitable for the situation. A few differences here is that the authorization
User Browser
Authentication Module
My-proxy-init
Data Portal Save Certificate
Session Manager
Save AC Token
Proxy Certificat e+ DP AC+ DP cert
AC Token
Query (query string, Proxy Cert + AC Token)
Authorizati on Server
Access Adapter
Admin
Access Adapter
Resource 1
Query (query string, Proxy Cert + AC Token)
Authorizat ion Server Admin
Access Adapter
Resource 1
Access Adapter
Resource 2
Resource 2 Organization 1
Organization n
Figure 1 : Data Portal Interaction with Authentication and Authorization
MyProxy
information is not embedded into the proxy certificate, as the authorization token (Attribute Certificate) generated by the organization’s authorization server itself contains the DN of the user and hence can be related to the proxy certificate. Central to the authorization framework is an Authorization Server that is hosted in every Organization which is participating with the Data Portal. This Authorization Server is administered and maintained by the local organization. The basic authentication and authorization interactions between the modules within the Data Portal framework are as shown in Figure 1. The Data Portal’s Authentication Module handles the user’s login and creates a delegate proxy certificate via the MyProxy certificate server. It then uses the delegate proxy certificate for interacting on behalf of the user. The authentication module contacts the participating organizations Authorization Servers and requests for Authorization Tokens for the user by presenting the user’s proxy certificate. The returned Authorization Tokens are stored in the Session Manager against the user’s current session ID along with the user’s Delegate Proxy certificate. When the user makes a request to for a specific resource, the Data Portal retrieves the user’s proxy certificate and the respective Authorization Token, which has been generated by the organization in which the resource needs to be queried, from the Session Manager. The Data Portal then authenticates with the resource using the user’s proxy certificate and transfers the request query along with the Authorization Token. The resource’s Access Adapter receives the request query and validates the Authorization Token. If the user has adequate privileges to access the resource, the resource executes the request query and returns the result back to the Data Portal which then forwards it back to the user or to the next application. In the subsequent section, the different segments of the authorization infrastructure are discussed in more detail.
Authorization Server Every organization participating with the Data Portal hosts an authorization server. The basic structure of the authorization server is as shown in Figure 2. It consists of an Attribute
Certificate Token generator which generates an Authorization Token, a User Privilege Database which stores the user’s privileges and a management interface for managing user’s privileges. The Data Portal requests for an Authorization Token from the Organization’s Authorization Server by sending the user’s proxy certificate along with the request. Currently the request is performed via the web service interface. The Authorization Server verifies the validity of the proxy certificate and queries the User privilege Database for the privileges of the user with the DN of the user via the User Privilege Interface. After receiving the user’s privileges the AC Token generator then creates an Authorization Token containing the user’s DN, access Get AC Token (Proxy Cert, Request Parameters)
Return (AC Token)
Web Service Interface
AC Token Generator
User Privilege Interface
User Privilege DB
Management Interface
Figure 2: Authorization Server
privileges and time constraints and signs it with its private key. This Authorization Token is then returned back to the Data Portal. The user’s privilege is stored in the form of groups in the User privilege Database. He or she is a member of one or more groups where each group is assigned a certain set of access privileges at the resource end. The group membership to the user is assigned via the management interface. The management interface is used to add and remove user’s to the groups or to modify the user’s group.
Authorization Token Format Currently the AC Token Generator creates an Authorization Token in XML format.
This is because XML parsers are widely available for a variety of platforms. The Authorization Token is currently of the format as shown in Figure 3.
receives the request. This resource Access Adapter acts as an interface for external users to access the resource. The basic structure of the Resource access adapter is as shown in Figure 4.
1.0 user DN issuer DN issuerName MD5withRSA value value value
When the Resource Access Adapter receives a request query, it authenticates with the Data Portal using the user’s proxy delegate. The request is currently received via the web service interface. Once authenticated the Resource Access Adapter receives the request query along with the Authorization Token.
Figure 3: Attribute Certificate
The Attribute certificate contains the DN of the user for whom it is intended for. It also contains the time validity of the attribute certificate as to when the user is authorized to use and a list of groups that that the user is a member of. This is then signed by the AC Token Generator using the Authorization Server’s private key to validate the source of the contents.
Resource Access Adapter Every resource present within the organization has a Resource Access Adapter which
The AC Token Decoder in the Resource Access Adapter then verifies to see if the user’s DN in the Authorization Token is the same as in the proxy certificate and also checks to see if the Authorization Token has been generated by its organization’s Authorization server. On succeeding, the AC Token generator retrieves the group that the user belongs to from the Authorization Token and forwards it to the Access Enforcement Module along with the request query. The Access Enforcement Module then adds the user’s DN and its request to a new entry in the Access Log table and maps the relevant user’s group to the resource’s local Access Control Mechanism, such as to a Unix Access Control Mechanism or to a Relational Database’s Access Control Mechanism. The request query is then executed with the privileges provided by the resource’s local access control mechanism.
Conclusion Request result (Proxy Cert, AC Token, query)
Web Service Interface
AC Token Deconder
Access Log Access Enforcement
Resource
Figure 4: Access Adapter
With this strategy the resource provider would trust the request put forward by the user as the user’s authenticity is guaranteed by the resource’s trusted Certification Authority and user’s level of privilege is defined by its own organization’s Authorization Server. The organization is also able to manage a larger number of users as it categorizes the users into various groups at organization level and the actual access privilege to the group is maintained at the local resource level. The overhead at the resource level would reduce as it now has to maintain the access privileges to only a set of groups rather than users and increase in users access the system does not necessarily increase the administrative overhead at each resource proportionally.
Also in this strategy the resource providers would continue to use the existing access control mechanism with the Authorization Token complimenting it in order to handle the increase in users. This would be important as many applications already have mature access control mechanisms that have already been deployed. The GSI proxy delegation would also be unaffected by the Authorization Token and would continue to function normally as these tokens are not a part of the proxy certificate but rather piggybacked with every request and hence would not be necessary to generate a new proxy certificate embedded with the authorization token each time before a request to a resource. The Authorization Token’s size would remain small as it basically stores only the information regarding to the group memberships, with the rest of privileges parameters being held at the local resource level. Revocation mechanisms would also not be necessary as the Authorization Tokens have a short life.
Future Work The next stages of development in the Authorization Framework are to formalize the format and the structure of the Authorization Token with the possibility of complying to the Attribute Certificate [5] format. As organizations keep increasing the resources it opens to the Grid, it would also be interesting to look into the ways of managing how the resource servers would handle Authorization Token within the organization. A change in Authorization Token format could trigger modification to the resource Access Adapters. Especially for larger organizations, it may be interesting to have a mechanism where resources could pull in modification if necessary from certain repositories within organization. Another interesting option would be to replace the web service interface of the modules with Grid service interfaces or other communication protocols to make it operate in other protocols as well. Finally, uses of Authorization Tokens in other applications such as for the HPC portal are being investigated.
References: 1.
R. Alfieri, R. Cecchini, et.al., VOMS, an Authorization System for Virtual Organizations, http://gridauth.infn.it/docs/VOMS-Santiago.pdf 2. Laura Pearlman, Von Welch et. al., A Community Authorization Service for Group Collaboration, http://www.globus.org/Security/CAS/CAS_ 2002_Revised.pdf 3. D.W.Chadwick,O.Otenko, The PERMIS X.509 Role Based Privilege Management Infrastructure, http://sec.isi.salford.ac.uk/ download/SACMATfinal.pdf 4. Mary R. Thompson, Abdelilah Essiari et. al., Certificate-based Authorization Policy in a PKI Environment, http://wwwitg.lbl.gov/security/Akenti/Papers/ACMTIS SEC.pdf 5. S. Farrell, R.Housley, An Internet Attribute Certificate Profile for Authorization, RFC 3281, April 2002, http://www.ietf.org/rfc /rfc3281.txt?number=3281 6. David F. Feccaiolo et al, Role-Based Access Control : Features and Motivations, http://csrc.nist.gov/rbac/ferraiolo-cuginikuhn-95.pdf 7. J. Novotny, S. Tuecke, and V. Welch. An Online Credential Repository for the Grid: MyProxy. Proceedings of the Tenth International Symposium on High Performance Distributed Computing (HPDC-10), IEEE Press, August 2001, http://www.globus.org/research/papers/myp roxy.pdf 8. Globus Project, Overview of Grid Security Infrastructure, http://www.globus.org/ security/overview.html 9. Glen Drinkwater, Kerstin Kleese et. al., The CCLRC Data Portal, http://www.escience.clrc.ac.uk/documents/projects/datap ortal/DataPortalwebServices0603_Glen.doc 10. The CCLRC HPC Portal, http://wkpc1.dl.ac.uk/HPCPortal/ 11. Kerstin Kleese, Lisa Blanshard, Richard Tyer, The E-Minerals Mini Grid, http://ws1.esc.rl.ac.uk/documents/staff/kers tin_kleese/e-min_intro.doc 12. EU DataGRID Security Design, Deliverables 7.6, March 2003, http://hepproject-grid-scg.web.cern.ch/hepproject-grid-scg/DataGrid-07-D7.60112-2-0-SecurityDesign.pdf
