GRID Authorization Framework for CCLRC Data Portal
Ananta Manandhar, Glen Drinkwater, Richard Tyer, Kerstin Kleese
CCLRC – Daresbury Laboratory, Daresbury, Warrington, Cheshire, WA44AD, UK
Email: a.s.manandhar@dl.ac.uk
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.
<attributeCertificate>
<acInfo>
<version>1.0 </version>
<holder> user DN </holder>
<issuer> issuer DN </issuer>
<issuerName> issuerName </issuerName>
<issuerSerialNumber> </issuerSerialNumber>
<signatureAlgorithm>MD5withRSA</signatureAlgorithm>
<validity>
<notBefore></notBefore>
<notAfter></notAfter>
</validity>
<attributes>
<DPGroup>value</DPGroup>
<wrapperGroup>value</wrapperGroup>
<dataAccessGroup>value</dataAccessGroup>
</attributes>
</acInfo>
<signature>
</signature>
</attributeCertificate>
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