ShibVomGSite: A Framework for Providing Username and
Password Support to GridSite with Attribute based
Authorization using Shibboleth and VOMS Joseph Olufemi Dada & Andrew McNab School of Physics and Astronomy, University of Manchester, Manchester UK
Abstract
The GridSite relies on the Grid credentials for user authentication and authorization. It does not
support username/password pair and attribute­based authorization. Since Public Key Infrastructure
(PKI) certificate cannot be installed on all the devices a user will use, access to GridSite protected
resources by users while attending conferences, at airport kiosk, working in Internet Café, on
holidays etc. is not possible without exposing the certificate's private key on multiple locations.
Exposing the private key on multiple locations poses a security risk. This paper describes our work
in progress, called ShibVomGSite: a framework that integrates Shibboleth, VOMS and GridSite to
solve this problem. ShibVomGSite issues to users a username and Time Limited Password bind to
their Distinguished Name (DN) and Certificate Authority’s DN in a database, which the users can
later use to gain access to their attributes that are used for authorization. 1
Introduction
GridSite [1­3] is a certificate­based website
management system that allows members of an
organization to collaborate in maintaining web
pages etc. It was originally developed for the
management of GridPP project's web site [4].
Authentication is based on Grid credentials, but
with unmodified web browsers such as
Netscape and Internet Explorer. To access the
GridSite protected resources, users must apply
and obtain certificate from the Certificate
Authority (CA). The certificate and private key
protected by a pass phrase must be installed on
every devices that users will use to access the
GridSite protected resources. Installing
certificate and its private key on multiple
locations poses a security risk. This limitation
prevents users having access to GridSite
protected resources while attending
conferences, at airport kiosk, working in
Internet Café, on holidays etc. This paper
describes a framework called ShibVomGSite;
we developed to overcome this limitation. Our framework provides a shibbolized
access to GridSite resources. Users use a Time
Limited Password associated with their Public
Key Infrastructure (PKI) certificates [5] to gain
access to the their attributes that are used for
authorization. We developed the MyIdentity
service to handle the issuing of username and
Time Limited Password to users at their home
institution. MyIdentity service also allows users
to manage their identities in the database. The GridPP collaboration involves a
community of many particle physicists,
computer scientists and site administrators with
members located at UK universities and
international laboratories. These various
affiliations make it imperative to link
Shibboleth Attribute Authority at the origin site
with Virtual Organization Membership Service
(VOMS) [6, 7] in order to get relevant member's
VOMS­Attributes necessary for authorization.
To achieve this, we developed the Voms
Attribute Service for GridSite and Shibboleth
(VASGS) that integrates VOMS with
Shibboleth. Shibboleth uses VASGS to retrieve
users attributes from VOMS, which it then
passes together with other attributes to GridSite
for authorization purposes. For the authorization, we introduce the
concept of GridSite Authorization Module for
Shibboleth and Apache Server (GAMAS).
GAMAS integrates with Shibboleth at the
resource provider or target site. The rest of this
paper is organised as follows: Section 2 briefly
describes the GridSite authentication and
authorization process, VOMS and Shibboleth.
ShibVomGSite system is described in section 3
along with a description of how its components
work together to achieve the objective of our
work. A brief description of the prototype of
MyIdentity service, VASGS service and
GAMAS is presented in section 4, and section 5
gives the conclusion and further work. 2
Background
In this section we present a brief description of
authentication and authorization in GridSite and
provide an overview of the two technologies
that are relevant to our work: Shibboleth and
VOMS. A detailed description of Shibboleth,
VOMS and GridSite can be found on the
individual websites [1, 6­8].
2.1 GridSite Authentication
Authorization and
Mutual authentication in GridSite is established
based on Grid credentials that require the use of
X.509 identity certificates [5]. A user needs to
have a valid X.509 certificate together with the
corresponding private key in order to proof
his/her identity to the GridSite resources. After the proof of identity, the user needs to
be authorized to gain access to the GridSite
resources based on the resource provider access
policy. The GridSite Apache module
(mod_gridsite) implements authorization based
on X.509, Grid Security Infrastructure (GSI) [9]
and VOMS credentials. It uses GACL, the “Grid
Access Control Language” [3] provided by the
GridSite/GACL library. This allows access
control to be specified in terms of attributes
found in Grid Credentials. The Access Control
Lists (ACLs) consist of a list of one or more
Entry blocks. When a user's credentials are
compared to the ACL, the permissions given to
the user by Allow blocks are recorded, along
with those forbidden by Deny blocks. When all
entries have been evaluated, any forbidden
permissions are removed from those granted. 2.2 Shibboleth
Shibboleth is standards­based, open source
middleware software, which provides Web
Single Sign On (SSO) across or within
organizational boundaries. It allows sites to
make informed authorization decisions for
individual access of protected online resources
in a privacy­preserving manner [4]. Shibboleth
consists of two major software components: the
Identity Provider (IdP) and Service Provider
(SP). The two components are deployed
separately but work together to provide secure
access to Web­based resources. The operation
of Shibboleth is based on the Security Assertion
Markup Language (SAML) standard [10],
published by the OASIS [11]. The principle
behind SAML’s design and Shibboleth’s is
federated identity. Federated identity
technology permits organization with disparate
authentication and authorization methods to
interoperate thereby extending the capability of
each organization’s existing services rather than
replacing them.
Shibboleth exchanges attributes across
domains for authorization purposes. Its
architecture is dependent on PKI, which it uses
to build trust relationship between the several
Shibboleth components of the Federation
members. Figure 1 shows the authentication and
authorization process in Shibboleth. As shown
in the figure, an IdP normally located at the
origin site identifies the users while SP at the
target site protects the resources. When a user
accesses a shibbolized resource at the target site
for the first time, the Shibboleth Indexical
Reference Establisher (SHIRE) directs the user
to go to Where Are You From (WAYF) to pick
his/her domain (origin site). The user's browser
is then redirected to the authentication server at
the origin site for user authentication. After the
user is authenticated, the browser is redirected
back to the target site along with the user's
handle and authentication assertion. The
authentication assertion is a proof to the target
site that the user has been successfully
authenticated. The Shibboleth Attribute
Requester (SHAR) at the target site uses the
user's handle to request for attributes of the user
from the Attribute Authority (AA) at the origin
site. The attributes are then passed to the
Shibboleth Authorization (ShibAuthZ) module,
which will make an access control decision
based on these attributes. GAMAS takes over
the function of ShibAuthZ in ShibVomGSite
system. 1. User’s request
User
Authentication
Server
4b. User’s handle & Authentication Assertion
3. User’s authentication
5. User’s handle & user’s AA info
WAYF
Handle Service
4a. User’s handle registration
2. User’s domain?
SHIRE
SHAR
6. User’s handle & attributes request
Attribute Authority
8. AuthZ request + user’s attributes
7. User’s attributes
IdP/Origin Site
ShibAuthZ
SP/Target Site
Figure 1: Architecture of Shibboleth 2.3 Virtual Organization Membership
Service (VOMS)
passed to the Service Provider for authorization
purposes. Virtual Organization Membership Service
provides information on the user's relationship
with her Virtual Organization: her groups, roles
and capabilities. The service is basically a
simple account database, which serves the
information in a special format (VOMS
credential). The VO manager can administrate it
remotely using command line tools or a web
interface. An authenticated user (or any
principal) can request membership of a VO, and
request group membership, role, and capability
entitlements [6]. Once the user has been granted the
appropriate VO membership and attributes
within a VO, he may request a short­lived
credential. The user runs voms­proxy­init with
optional arguments relating to which VOs,
groups, roles, and capabilities he wishes for his
current credential. VOMS issues a short­lived
Attribute Certificate [12] to the authenticated
user, which the user may then present to
resources on the Grid. However, its present implementation doesn't
support issuing of user's attributes or
authorization data to a third party on behalf of
the user. We have developed a web service that
can be plugged into VOMS to enable a trusted
third party (e.g. Shibboleth IdP) requests user's
attributes on behalf of the user, which are then
3
ShibVomGSite System
In this section, we present the ShibVomGSite
system that addresses the problems enumerated
in the introduction. ShibVomGSite consists of
three major components that integrate
Shibboleth, VOMS and GridSite to enable
GridSite supports username/password and
attribute­based authorization: MyIdentity
Service, VASGS service, and GAMAS. We
describe these components in the sub sections
that follow. Figure 2 shows these components,
their interactions and how they interact with
Shibboleth to achieve the objective of this work.
The steps shown in the figure are explained
below:
1. The user contacts Shibboleth/GridSite
protected resource site with a browser,
requesting to access a Shibboleth­GAMAS
protected target service.
2. The user is redirected to the IdP for
authentication.
3. IdP calls the MyIdentity service for user
authentication.
VASGS
Service
MyIdentity
Service
3. User authentication 5. Retrieves user's DN & Insurer's DN GAMAS
6. Request for user's attributes
8. User’s attributes & authorization decision request
9. Authorization decision
7. User's attributes
SP
IdP
4. Request for attributes using Handle
Origin site
2. Redirect user for authentication
user
1. Resource access request 10. Access to resources
Target Resource
Target site
Figure 2: ShibVomGSite Architecture
4. After successful authentication, the browser
is redirected to the SP together with handle.
The SP at the target site gets the handle and
sends the handle to the IdP of the origin site
for attributes query. 5. The IdP retrieves the user DN and CA's DN
from MyIdentityDB. 6. The IdP authenticates to the VASGS­Service
using host PKI certificate, and uses user's
DN and CA’s DN as parameters to request
for user's attributes from VOMS through the
VASGS service. The VASGS service returns
the user's attributes to the IdP. 7. The IdP sends the attributes together with
the user's DN if required back to the SP. 8. The SP uses the user's attributes to request
for authorization decision from GAMAS.
9. GAMAS carries out authorization process
and passes its decision back to SP.
10. SP grants or denies access to the Target
Resource depending on the authorization
decision from GAMAS.
3.1 MyIdentity Service MyIdentity service carries out authentication of
users using certificate and enables them to
manage their username and password bind to
their DN. It is simply a database with an
interface developed in C. Unlike MyProxy [13]
that stores proxy credentials, MyIdentity only
stores users' DN and CA’s DN bind to the
username/password, which are later used by
Shibboleth to retrieve user's attributes from
VOMS server. The components of the
MyIdentity service are shown in Figure 3. The first operation a user must perform in
order to get access to GridSite resources without
using certificate is to request for a username and
Time Limited Password from the MyIdentity
Service. The steps involve are described below:
1. The user and the MyIdentity Service
authenticate each other with their certificates
using HTTPS protocol.
2. MyIdentity service extracts the user's DN
and CA's DN from his/her certificate and
issues a username and time limited password
to the user through the same web browser
the user used for the authentication. User
can change his/her password immediately or
within 6 days.
3. MyIdentity service saves the username and
password in encryption form together with
the DN and CA's DN in database.
MyIdentity
CertAuthT
User
MyIdentity Service
MyIdentity
DBInterface
MyIdentity
DB
MyIdentity
Password
MyIdentity
AuthTModule
Figure 3: User interaction with MyIdentity Service
The user has the opportunity of managing
his/her information in the MyIdentityDB using
the MyIdentityPassword module. Shibboleth IdP uses MyIdentityAuthT
Apache module for the authentication of users
anytime users attempt to access GridSite
protected resources on the target site.
MyIdentityAuthT Apache module is based on
Apache module (mod_auth_mysql) [14]. The
module is integrated into the MyIdentityDB that
contains the username/password and other user's
information. A full paper on MyIdentity service
is in preparation.
3.2 Voms Attribute Service for GridSite and
Shibboleth (VASGS)
VASGS service is made up of two components:
VASGS­VOMAttribute Web Service and
VASGS­ConnectorPlugIn for IdP. Figure 4
shows the interaction between Shibboleth IdP
and VASGS service. IdP connects VASGS­
VOMAttribute Web Service to get user's
attributes (groups, roles, capabilities etc.) from
VOMS server using VASGS­ConnectorPlugIn.
The attributes are combined with the others,
which are then pass to the SP for authorization.
The advantage of VASGS Service is that, users
don't need to apply for Attribute Certificate to
access GridSite resources; attributes are pull
directly from the VOMS. Our VASGS service
therefore allows IdP to use VOMS as an
Attribute Repository.
VASGS
ConnectorPlugIn
IdP
VASGS
VomsAttribute Web Service
VOMS
API
VOMS
DB
Web Container (Tomcat)
Figure 4: Structure of VASGS Service
user
IdP/Origin Site
MyIdentity
AuthT Module
SHIRE
SP/Target Site
SHAR
VASGS­
VOMAttribute Service
(2)
Handle
Service
GAMAS
(1)
VASGS
Connector
PlugIn
Attribute Authority
mod_shib
_gridsite
(3)
(4)
GridSite
Library
ShibAuthZ
Figure 5: Integration of GAMAS with Service Provider 3.3 GridSite Authorization Module for
Shibboleth and Apache Server (GAMAS)
Figure 5 shows the structure of GAMAS and
how it integrates with SP to carry out the
authorization process. The mod_shib_gridsite is
the core module of GAMAS. It interfaces with
Shibboleth and Apache server to collect all the
attributes necessary for making authorization
decision and passing these attributes to the
GridSite/GACL/XACML library. Authorization
decision is passed back to the
mod_shib_gridsite, which translates it to “OK”
or “HTTP_UNAUTHORIZED” error codes.
Apache will either send the requested resource
or a page with the error information back to the
user web browser depending on the result. Since
GAMAS returns a definite result when
mod_shib_gridsite is active, Shibboleth
authorization module (ShibAuthZ) is not
invoked. The mod_shib_gridsite must appear before
the Shibboleth Apache module (mod_shib) in
the Apache 2.0 configuration file. Since each
location in Apache configuration file may use a
different form of authorization, GAMAS is only
active if the “GridSiteAuth” directive is present
for the location. If it's not present,
mod_shib_gridsite will return DECLINED, so
that Shibboleth or any configured authorization
module will be invoked.
To explain how GAMAS integrates with SP
at the target site, the interactions between SP
and GAMAS during the authorization phase
(shown with numbers in Figure 5) are explained
as follows:
1. The authorization phase begins after SHAR
component of the SP successfully received
user's attributes from Attribute Authority
component of the IdP as earlier explained in
section 3. In this phase, mod_shib_gridsite is
invoked first by the Apache server.
2. If requested location is not being protected
by GAMAS, the mod_shib_gridsite will
return DECLINED and the Shibboleth
authorization function ShibAuthZ or any
other authorization function for the location
will be invoked, otherwise the user's
attributes and DN are acquired by the
mod_shib_gridsite from the HTTP headers.
3. Mod_shib_gridsite calls the gridsite/GACL/
XACML library to make an authorization
decision, which is based on user's attributes
and DN.
4. After the decision, the granted/denied
decision is returned back to
mod_shib_gridsite.
5. Mod_shib_gridsite returns the decision to
Apache server. The user is then granted or
denied access to the target resource
according to the result of the decision.
4
Prototype Implementation
We have implemented the prototype of
MyIdentity service, VASGS service and
GAMAS. In this section, we briefly describe
our implementation. MyIdentity service prototype is
implemented in C. The database server used is
MySQL. Users can login with their certificates
and obtain username and password.
MyIdentityCertAuthT module is a Common
Gateway Interface (CGI) script that connects to
the
MyIdentityDB
using
MyIdentityDBInterface. MyIdentityPassword,
which allows users to manage their records, is
also a CGI script that uses
MyIdentityDBInterface to interact with the
MyIdentityDB. MyIdentityAuthT module is the
authentication server for the Shibboleth, which
is based on the Apache module:
mod_auth_mysql [14].
VASGS service is implemented in JAVA. It
is based on Web Service technology. It has two
sub components as earlier described: VASGS­
VOMAttributeService that resides with VOMS
server and the VASGS­ConnectorPlugIn that
Shibboleth uses to invoke the VASGS­
VOMAttributeService on the VOMS server.
VOMAttributeService runs inside a Tomcat
web container just like the others services
provided by the VOMS server while
ConnectorPlugIn is a JAVA class that
Shibboleth invokes to connect to the
VOMAttributeService.
GAMAS (mod_shib_gridsite and gridsite
library) is implemented in C as Apache module.
It is an extension of the mod_gridsite. As earlier
described, it receives users' attributes from
Shibboleth to make authorization decision. 5
Conclusion and Further Work
We have presented a ShibVomGSite framework
that provides username/password support and
attribute­based authorization to GridSite. This
framework allows users access to GridSite
protected resources anywhere and anytime
using time limited password. MyIdentity service binds user’s DN and
CA's DN with the username and Time Limited
Password in a database (MyIdentityDB). It also
serves as an attribute repository for the IdP, and
provides DN and CA’s DN used as parameter to
obtain VOMS attributes for users with the help
of the VASGS service. We also described
GAMAS that uses the VOMS attributes
received from Shibboleth for authorization.
GAMAS receives the attributes through the
Shibboleth SP (mod_shib), carries out
authorization process and returns decision result
to the Apache Server, which grants or denies
user’s request depending on the result of the
authorization decision. The work presented in this paper is a work in
progress. Efforts are continue to further develop
the existing prototype to a full working system
suitable for deployment. We are also working
on integrating ShibVomGSite system with
Flexible Access Middleware Extension (FAME)
[15].
6
Acknowledgements
This work was funded by the Particle and
Astronomy Research Council through their
GridPP programme. Our thanks also go to other members of the
various EDG and EGEE security working
groups for providing much of the wider
environments for this work. 7
References
[1] Grid Security for the Grid, Web Platform for
Gird, http://www.gridsite.org/ .
[2] McNab, A., The GridSite Web/Grid
Security System, Software Practice. Exper.,
http://www.interscience
.wiley.com,
35:827­
834, 2005.
[3] McNab, A., “Grid­Based Access Control
and User Management for Unix
Environments, File systems, Web Sites and
Virtual Organizations”, in Proceedings of
CHEP 2003, La Jolla, CA, 2003.
[4] UK Computing for Particle Physics,
http://www.gridpp.ac.uk/
. [5] Houseley, R., Polk, W., Ford, W. and Solo,
D., Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List
(CRL) Profile. RFC 3280, IETF, 2002.
[6] Alfieri, R., Cechini, R., Ciaschini, V.,
Spataro, F., dell' Agnello, L., Frohner, A.
and Lörentey, K., From gridmap­file to
VOMS: managing authorization in a Grid
environment,
http://www.cnaf.infn.it/ ~ferrari/
seminari/gri
glie05/lezione02/voms­FGCS.pdf, 2004.
[7] EDG­VOM­ADMIN Developer Guide,
http://edgwp2.web.cern.ch/edgwp2/
security/
voms/edg­voms­admin­dev­guide.pdf.
[8]
Shibboleth Project, http://shibboleth .internet2.edu/.
Internet2,
[9] Welch, V., Siebenlist, F., Foster, I.,
Bresnahan, J., Czajkowski, K., Gawor, J.,
Kesselman, C., Meder, S., Pearlman, L. and
Tuecke, S. Security for Grid Services. In
International Symposium High Performance
Distributed Computing, 2003.
[10] Assertions and Protocol for the OASIS
Security Assertion Markup Language
(SAML)V1.1,
http://www.oasis­
open.org/committees/download.php/3406/oa
sis­sstc­saml­core­1.1.pdf.
[11] OASIS, http://www.oasis­open.org/.
[12] Ciaschini, V., A VOMS Attribute
Certificate Profile for authorization,
http://infnforge.cnaf.infn.it/docman/view.ph
p/7/58/AC­RFC.pdf, 2004
[13] Novotny, J., Tuecke, J. and Welch, V., “An
Online Credential Repository for the Grid:
MyProxy”,
http://www.globus.org/alliance/publications/
papers/myproxy.pdf
[14] Mod_auth_mysql:
http://modauthmysql.sourceforge.net/.
[15] FAME­PERMIS ­ Flexible Access
Middleware Extension to PERMIS,
http://www
.fame­permis.org/.