GridCertLib: a Single Sign-on Solution for Grid Web Applications and Portals
Riccardo Murri, Peter Z. Kunszt, Sergio Maffioletti, Valery Tschopp
aa r X i v : . [ c s . D C ] S e p GridCertLib: a Single Sign-on Solution for GridWeb Applications and Portals
R. Murri , P. Kunszt , S. Maffioletti , and V. Tschopp Grid Computing Competence Centre, Organisch-Chemisches Institut,University of Z¨urich, Winterthurerstr. 190, CH-8057 Z¨urich,Switzerland SystemsX, ETH Z¨urich, Clausiusstr. 45, CH-8092 Z¨urich, Switzerland SWITCH, Werdstrasse 2, CH-8004 Z¨urich, SwitzerlandSep. 9, 2011
Abstract
This paper describes the design and implementation of
GridCertLib , a Java libraryleveraging a Shibboleth-based authentication infrastructure and the SLCS online cer-tificate signing service, to provide short-lived X.509 certificates and Grid proxies.The main use case envisioned for
GridCertLib , is to provide seamless and secureaccess to Grid X.509 certificates and proxies in web applications and portals: when auser logs in to the portal using SAML-based Shibboleth authentication,
GridCertLib uses the SAML assertion to obtain a Grid X.509 certificate from the SLCS service andgenerate a VOMS proxy from it.We give an overview of the architecture of
GridCertLib and briefly describe its pro-gramming model. Its application to some deployment scenarios is outlined, as well asa report on practical experience integrating
GridCertLib into portals for Bioinformat-ics and Computational Chemistry applications, based on the popular P-GRADE andDjango softwares.
Most Grid computing middleware in production use today relies on X.509 certificateproxies [44] for user authentication. This has been an issue when implementing web-based interfaces to Grid computing facilities: in order to generate a proxy, a copy of theX.509 private key is needed together with the passphrase used to encrypt it. However,uploading the public/private key pair to a web portal is undesirable on security grounds.Several solutions and workarounds have been implemented (see Section 2 below), butnone of them can be considered entirely satisfactory: either because they do not fullyaddress the security concerns, or because they require end users to take multiple steps,possibly through different and unrelated user interfaces (e.g. a web portal and UNIXshell commands). 1he solution we developed leverages two features offered by SWITCH: the feder-ated authentication and authorization infrastructure SWITCHaai and the Short-LivedCredential Service (
SLCS ). SWITCHaai is a federated authentication and authoriza-tion infrastructure [40], based on Shibboleth2 [18]; SWITCHaai federates all Univer-sities in Switzerland, plus major research centers and educational institutions. Similarnationwide Authentication and Authorization Infrastructures (
AAIs ) exist in Germany,Denmark, Belgium, the Netherlands and other countries [7]. A web service provider(e.g., a portal) requiring SWITCHaai authentication will delegate the authenticationstep to the user’s home institution Identity Provider (
IdP ). Users will be promptedwith the familiar login page of the home institution; after successful logon, the serviceprovider will receive a set of parameters and additional metadata (about the user) toproceed with authorization [39].SWITCH also provides the Short-Lived Credential Service (
SLCS ) and makes itavailable to all SWITCHaai users [37].
SLCS is a web-service that can sign an X.509certificate online; authentication and authorization to the
SLCS service are based onthe SWITCHaai Shibboleth system. The online Certification Authority ( CA ) that signs SLCS certificates is included in the International Grid Trust Federation (
IGTF ) bundle[17], so
SLCS certificates can be used for any legitimate Grid purpose. This enables anyuser from a Swiss institution participating in the SWITCHaai Federation to requesta Grid-enabled X.509 certificate. It is valid up to 1’000’000 seconds (correspondingto almost 11 days) which is short-lived in comparison to regular one-year certificatesissued by other CAs. A
SLCS command-line client is also part of the gLite middlewaredistribution [43].The last key enabler for our project is the Shibboleth delegation feature, devel-oped in the Shibboleth uPortal project [5]. The delegation is based on the Liberty
ID-WSF ECP
Single Sign-On (
SSO ) profile [16], and allows SAML-based authenticationfor Shibboleth-protected web service providers. Based on the assertion resulting fromthe web authentication through Shibboleth on the user portal, we are able to call the
SLCS service on the user’s behalf using the Enhanced Client or Proxy (
ECP ) profile.Delegation, however, is still an experimental feature in Shibboleth, and is expected tobecome standard in the next Shibboleth version 3.0. For our project, SWITCH hasupgraded their Shibboleth Virtual Home Organization identity provider and the
SLCS service provider with
ECP delegation features.
GridCertLib is a Java library providing programming interfaces to create a
SLCS certificate and Grid proxy (optionally
VOMS -enabled), given the Security AssertionMarkup Language (
SAML ) assertion resulting from a successful previous Shibbolethauthentication. The main use case envisioned for
GridCertLib , is to provide seam-less and secure access to Grid X.509 certificates and proxies in web portals: whena user logs in to the portal using the regular SWITCHaai Shibboleth authentication,
GridCertLib uses the
SAML assertion to obtain a Grid X.509 certificate from the
SLCS service and generate a Virtual Organisation Membership Service (
VOMS ) proxy fromit. None of these steps requires user interaction (after the initial Shibboleth authentica-tion), making Grid resources as easy to use as any single-sign-on enabled web servicewhile retaining the full security stack.The outline of the paper is as follows: first we provide an overview of similar solu-tions already implemented in production-grade Grid web portals. In the next Section,we review the requirements that were set for
GridCertLib , its actual design and discusssome implementation details. Finally, we report on some deployment scenarios and The interested reader can find readable introductions to Shibboleth and
SAML in [19, 15].
GridCertLib within a Bionformatics portal (based onP-GRADE, [10]) and within a Computational Chemistry portal (based on Django, [8]).
Distributed authentication and authorization is a difficult problem to solve in a stan-dard and integrated manner. In past Grid projects, proprietary services have often beendeveloped to address this issue (e.g. CAS[34], PRIMA[27], ROAM[6]) but none ofthem established itself as a widely accepted community standard as they were tootightly coupled with the middleware and the local resources. A standardization on
SAML / XACML profiles to be used by all middlewares is available [11] but has not beenwidely adopted yet.However, we can see two technologies that are widely accepted also outside of theGrid community:
SAML -based authentication using Shibboleth and X.509 certificatesto authenticate local resources, using short-lived proxy certificates. In most Grids, alsothe
VOMS cervice is used to enrich the proxy certificate with usage attributes for fine-grained authorization. We are using the
SLCS service as developed by SWITCH forthe Enabling Grids for E-sciencE (
EGEE ) consortium to generate certificates from theusers’ Shibboleth login. A similar but now defunct project was the U.S. GridShib effort[4] to create a certificate based on a Shibboleth login also as a Certificate Authority.In order to generate a certificate proxy, a copy of the X.509 private key is neededtogether with the passphrase used to encrypt it. This poses a basic problem in webportals: having direct access to the public/private certificate key pair of a user, althoughtechnically feasible, is undesirable on security grounds: intruders getting access to theportal machine would gain unrestricted access to all of the portal users’ credentials.Some projects have worked around this issue by submitting to the Grid as a singleportal superuser, using credentials of a single entity for all Grid jobs issued through theportal or through special-purpose certificates for automation, called “robot” certificates.Robot certificates are X.509 certificates granted to a portal service or application,rather than a human; users interested in running a certain application on the Grid canlog in to the portal, and the portal will operate on the Grid using the robot certificate.This approach a few drawbacks:1. The certificate private key is available on the portal machine, although thiscan be prevented by using hardware-based protection (e.g. smartcards), asdone in the GILDA/GENIUS portal [3]. Indeed, guidelines [9] have beenissued by the
IGTF on the generation and storage of private keys, and per-missible key usage of automated clients (robots) that can hold credentialsissued by
IGTF -accredited Certification Authorities, so this specific issue islikely to become less relevant in the future.2. The use of robot certificates moves the responsibility of user authentica-tion and logging from the CA to the portal, thus implicitly introducing anadditional trust step in the Grid authentication infrastructure. Not all Gridsites and resource providers might be happy with delegating trust this way.3. It is difficult to provide per-user accounting of computational resource us-age: jobs submitted through different interfaces (e.g., portal and command-line) by the same user will be accounted to different end-entities, since allpopular Grid middlewares group usage records by certificate subject Dis-tinguished Name ( DN ). 3he solution adopted in the P-GRADE portal [10, 23] is to have users upload along-lived proxy to a MyProxy server [32, 33, 25] and authorize the portal softwarefor automated retrieval of short-lived proxies for job submission and data movement.However, this still requires users to deal with many of the complexities of manag-ing X.509-based certificates and command-line tools, which has been found to be areal barrier to Grid adoption in less tech-savvy user communities. In the newer WS-PGRADE portal [24] the interaction with the MyProxy service has been streamlinedso no command-line interaction is necessary, user certificate can be directly uploaded.However, the user still needs to apply for and manage a certificate that expires everyyear. For the end-user it is a complication to use an authentication infrastructure thatdoes not blend with the native web portal authentication system. It interrupts the natu-ral flow of operations in the web user interface, requiring either an additional password(the certificate password to generate the proxy) or additional command-line operationsin order to proceed with Grid job submission and control.An extension to this mechanism that blends more seamlessly with P-GRADE’sweb-based interface has been developed by the UK project SARoNGS in [14]. Click-ing a button on the MyProxy web details page redirects the user to a web service(Shibboleth-protected), which in turn loads a long-lived proxy into a specific MyProxyserver, and fills in the details in the P-GRADE configuration page.The approach taken in GridCertLib , instead, requires no user interaction: oncethe web-based Shibboleth login is successfully completed, the
GridCertLib code cangenerate an X.509 certificate through the
SLCS service using the web service based
ECP delegation, and an accompanying Grid proxy. Details of this process are given in thefollowing sections.The source code of
GridCertLib is publicly available from http://gridcertlib.googlecode.com/ under the Apache License 2.0 [2].
GridCertLib was designed to bridge Shibboleth-based and Grid X.509-based authenti-cation services for web applications and portals. Its design goals were to allow easyintegration into any Java portal, and to minimize interaction with the user while retain-ing the full security stack for Grid authentication and authorization.The flow of interaction with the Java portal code and the SWITCHaai services il-lustrated in Figure 1 was devised in order to accomplish the design objectives (numbersin parentheses correspond to arrows in Figure 1): (1)
Users initiates log in to the web portal using Shibboleth single sign-on (i.e., requesta Shibboleth-protected URL). (2)
They are authenticated by their home organization’s identity provider
IdP ; this ishandled transparently by the Shibboleth software. Henceforth, we shall briefly write “portal” to mean any web-based interactive application or service. A detailed understanding of the Shibboleth authentication process is not needed for working with
Grid-CertLib : it suffices to know that the outcome of a successful Shibboleth logon is a Security Assertion MarkupLanguage version 2 (
SAML2 ) assertion stored in the web server on the Portal machine. The interested readeris referred to [19, 39, 15] for an introduction to Shibboleth and
SAML2 . GridCertLib with the other involved services. Componentsin the center column are all part of the same web application (but they could be partof different processes: for instance, the Shibboleth web login is usually handled by anApache module rather than by Java servlet code). Round boxes on the sides representservices running on remote hosts, that
GridCertLib interacts with over
HTTP . A detaileddescription of interactions is given in Section 3.1.5
3) GridCertLib queries Apache’s mod shib to get the
SAML2 assertion. The assertionis exported, together with other authentication parameters, to any proxied web ser-vice; portals may make use of these Shibboleth attributes to restrict certain servicesor map users into user groups. (4)
The portal application code calls GridCertLib to obtain a short-lived Grid X.509certificate signed by the
SLCS CA . This step requires delegation of the Shibbolethcredentials (
SAML2 assertion) to the
SLCS login service, which is done through thegeneric Identity Domain - Web Service Framework (
ID-WSF ) ECP
Web ServiceClient, developed by SWITCH [42]. (5)
After logging in to the
SLCS service,
GridCertLib proceeds to generate an X.509certificate and have it signed by the
SLCS online CA , using code similar to the oneused by gLite’s slcs-init command-line client [43]. (6) The portal calls GridCertLib to create a grid proxy (with or without
VOMS exten-sions). Here
GridCertLib is just a thin wrapper around the regular
VOMS libraries,mainly providing simpler fac¸ade calls for commonly-used cases. (7)
The certificate, private key and proxies are stored. Currently,
GridCertLib providesmethods for persisting certificates and proxies to the filesystem; it is up to the portalto move the files to different storage back-ends (e.g., databases), although it shouldbe noted that most Grid middlewares require the proxy to be in a known locationon the filesystem.As soon as the
GridCertLib code completes successfully, a valid certificate andproxy are available on the filesystem and Grid operations can proceed.The foreseen usage of
GridCertLib in web portals (see Section Deployment Experiences)called for implementation of additional features in
GridCertLib : a. The
SLCS and the Grid/VOMS proxy generation functions can be calledindependently. In particular, proxy generation does not rely on the
SLCS generation feature being called first. As a consequence, Grid proxy codedoes not need Shibboleth authentication to run, it only expects a valid usercertificate to be available.This is a portal user interface requirement: all that is necessary for gener-ating an X.509 certificate is known after
SLCS login, but proxy generationrequires additional data; namely, names of the VOs a user belongs to. Por-tals might need to gather this additional data after a user has logged in. b. The
SLCS generation function can be called at any time, as long as the
SAML2 assertion resulting from the Shibboleth login process is available.This is another portal user interface requirement:
SLCS login and genera-tion of X.509 certificates can take long times (from a user interface per-spective), so they can be delayed at a later stage or started in an asyn-chronous thread, in order not to delay the login process. c. GridCertLib has a generic interface that can be used with any web appli-cation or portal. In particular,
GridCertLib does not make any assumptionon how user data (like the certificates) are represented and/or stored withinthe portal, except that they can be stored on the filesystem.6eature a. led us to provide GridCertLib with two main independent entry points,
SLCSFactory and
GridProxyFactory . An instance of each class is responsible for gen-erating
SLCS certificate and Grid proxies, respectively. To achieve portal independence,each class constructor takes an explicit list of all the parameters needed for instan-tiation, although they can also be conveniently provided by a single Java
Properties object.Similarly, for the same goal c. of portal technology independence, GridCertLib certificate and proxy generation functions accept an explicit list of all the requiredparameters, but provide shortened forms that have common defaults.Feature b. implies that the SLCS -generation methods in
GridCertLib only requirethe Shibboleth
SAML assertion as input. However, the
SAML2 assertion can expire longbefore the Shibboleth session itself does (see Section 3.2.1). To solve this problem,
GridCertLib provides a re-usable servlet RenewAssertion, which can also be used as amodel for implementing assertion renewal in the portal code.
GridCertLib core functions reside in the single Java package ch.swing.gridcertlib ;an additional package ch.swing.gridcertlib.servlet provides example servlets(with fully-commented code) that show how the library can be used.The main package ch.swing.gridcertlib has two public entry points: • The
SLCSFactory class provides the
SLCS certificate generation functionality andcan store the certificate and its associated private key on the filesystem. • The
GridProxyFactory class creates Globus Toolkit proxy certificates with orwithout
VOMS extensions from available user certificates and stores them to atemporary location on the filesystem.A single instance of each of these classes can generate multiple
SLCS certificatesor proxies, possibly for different Portal users, via repeated invocation of the certificatecreation methods.Since the parameters used to configure the factory objects are portal-wide globalvariables and their values are fixed while the portal application is running, each factoryclass can be configured (at construction time) through a java.util.Properties object,which can be conveniently loaded from a file with standard Java
API calls. Alternatively,a constructor that allows to specify all instance parameters explicitly is also provided.However,
GridCertLib does not enforce that only a single instance of these factoryobjects exists. Different factory objects can be created to cater for different classes ofusers (e.g., users coming from different Shibboleth federations). It is up to the webapplication/portal code to route requests to the correct factory.
Upon calling the newSLCS method of the
SLCSFactory class, a
SLCSRequestor objectis created to carry out generation of the certificate and actual interaction with the
SLCS server. The reason for this split is twofold: • SLCSFactory handles system-wide defaults, and thus a single instance is neededto serve the whole portal, whereas a new
SLCSRequestor object is created forevery certificate request. 7
The
SLCSRequestor corresponds to the slcs-init command-line tool providedin the gLite middleware distribution [43]; this eases porting of fixes from theofficial
SLCS client on to
GridCertLib . SLCS certificates are created following these steps:1. Login to the
SLCS server using
ECP delegation: if successful, this returnsthe subject DN to use in the X.509 certificate to be generated, and an autho-rization token to validate the final certificate signing request to the same SLCS server.2. Locally generate an X.509 public/private key pair.3. Locally generate an X.509 Certificate Signing Request (
CSR ), using thesubject DN and other X.509 constraints returned by step 1.4. Submit the CSR to the
SLCS server and get the signed certificate back.All of the above steps keep data (like the password), which is necessary for theprivate key, in memory. Only after a certificate has been successfully generated by the
SLCSRequestor will
SLCSFactory save the result in a file and return the certificate filepath, private key path and private key password to the caller. Any of these three can bedefined by the client code by passing an optional argument to the newSLCS method;by default,
SLCSFactory uses a random password and stores the certificate and privatekey files in a configurable directory (using a random file name, which is also returnedas a result of the call).The
SLCS service is a properly authorized Shibboleth Service Provider ( SP ). Since GridCertLib is contacting
SLCS on behalf of the user, and with no user interventionat all, delegation of
SAML credentials is needed. Shibboleth delegation is an experi-mental feature available in Shibboleth2, by which the
SAML2 assertion that initiates aShibboleth session on an SP , may be re-used to authenticate towards other web ser-vice based SPs. Shibboleth delegation must be supported both on the IdP granting the
SAML2 assertion and the target SP receiving the delegated assertion (the SLCS server inthis case).The requirement that
SLCS generation may happen at any time after login to the por-tal creates an additional complication:
SAML2 assertions have a short time validity (5minutes in the default configuration) but SP and IdP sessions last much longer (8 hoursby default), i.e., users are authenticated with the Shibboleth SP even after the SAML2 assertion is long expired. Therefore, by the time
SLCSFactory.newSLCS is called, the
SAML2 assertion might be unusable for delegated authentication with the
SLCS server.There is no support in the Shibboleth
API to get a fresh assertion in the
IdP and storeit in the SP session, but this can be worked around by forcing an SP session logout,followed by a redirection to a Shibboleth-protected URL : the SP will start a new ses-sion and request a fresh assertion from the IdP . This can be implemented by a chainof
HTTP redirections, so that the whole procedure does not require any user interven-tion. We implemented this workaround in the
RenewAssertion servlet, described inSection 3.2.3.
The
GridProxyFactory class is a interface wrapper on top of the
VOMS
Java
API . Grid-ProxyFactory implements a simplified interface to create a Grid proxy in the use case8ost frequently needed in web applications and portals: its newProxy method creates aproxy (with optional
VOMS extensions) given an X.509 certificate and private key, anda (possibly empty) list of VOs to contact for
VOMS
ACs.A single instance of the class can generate multiple proxies (possibly for differentusers) via repeated invocation of the newProxy method. Since the org.glite.voms.con-tact.VOMSProxyInit class uses system properties to determine part of its configuration,it is not possible to create different instances of this class, each using its own config-uration. This is not a limit in practice, as the org.glite.voms library has native supportfor multiple servers and Virtual Organisation ( VO ) endpoints. The provided sample servlets can run in any Java servlet container. They have beensuccessfully tested with the Jetty and Tomcat Java application servers (with an Apacheproxy front-end for managing the Shibboleth session).Three servlets are distributed with the GridCertLib source code: • SlcsInit:
This servlet generates an X.509 certificate and private key and uses the
SLCS service to sign it. Upon successful completion, the certificate and privatekey are stored in the filesystem. • VomsProxyInit:
This servlet creates a
VOMS proxy and stores it in the filesystem. • RenewAssertion:
This servlet ensures that a fresh
SAML assertion is stored in the SP Shibboleth session cache.A detailed description of each of these servlets follows.
SlcsInit.
The ch.swing.gridcertlib.servlet.SlcsInit servlet extracts the
SAML2 assertion
URL from the Shibboleth
HTTP headers, downloads the assertion into memory, and usesit to authenticate to a remote
SLCS service and get a new certificate/private key pair. Thekey is encrypted with a random password, and the certificate and private key locations(on the filesystem) are printed in the response text.If
SLCSFactory detects an expired assertion in the SP session, it will raise an ex-ception. The SlcsInit code catches the error and redirects the user’s browser to theRenewAssertion servlet, setting the return address to the current page: when the userbrowser is sent back to the return
URL , a new
SAML2 assertion will be in the SP cache. VomsProxyInit.
The ch.swing.gridcertlib.servlet.VomsProxyInit servlet creates a
VOMS proxy and stores it on the filesystem, in the default store directory.
HTTP query parame-ters can set arguments that are passed to the
GridProxyFactory.newProxy method, thusmaking this servlet a generic front-end to the
GridProxyFactory class functionality.This servlet does not require any interaction with the Shibboleth subsystem, andcan be deployed unprotected. It requires, however, that the certificate and private keyare available on the filesystem.
RenewAssertion.
The ch.swing.gridcertlib.servlet.RenewAssertion servlet ensures thata fresh assertion is stored in the SP Shibboleth session cache. It implements the workarounddescribed in a previous section for the “expired assertion” problem:1. The user’s browser is redirected to the SP session logout URL .9. The logout function allows setting a “return address” via a
URL query pa-rameter, to which the browser will be redirected after the logout is done;this “return address” is set to the
RenewAssertion
URL plus a trailing com-ponent (
URL “path information” part) that encodes the referring page
URL .3. The Shibboleth SP logs the user out of the session and destroys the cacheddata, then redirects the user browser to the RenewAssertion
URL .4. The
RenewAssertion page is Shibboleth-protected, so a new Shibbolethauthentication procedure begins. As long as the user session in the
IdP isstill valid, this will not require user interaction, and the
IdP will just send anew
SAML2 assertion to the requesting SP .5. The RenewAssertion servlet detects that the browser is returning after theinitial visit (from the trailing portion of the
URL ), and redirects the userto the initial requesting page (by decoding the
URL embedded in the “pathinformation” component).Note that none of the above steps requires any user interaction (unless the Shibbo-leth session on the
IdP is expired).A request
URL to RenewAssertion must be properly formatted; the conveniencemethod
RenewAssertion.getRenewalUrl is provided to this purpose. However, the
URL encoding system in the
RenewAssertion servlet imposes a limit on the length of returnURLs; more importantly, it cannot be used with
HTTP
POST requests, as there is noway of encoding the POST data into a single
URL . This is a technical issue whichwe have not been able to work around so far: due to the large number of
HTTP redi-rects taking place, session cookies, query parameters, and other commonly-used waysof associating state data with
HTTP requests, may be lost before the final visit to the
RenewAssertion servlet.
The following points need to be taken into consideration by the portal providers: • Since certificate generation can be time-consuming (relative to user interfacereaction times), it could be delayed to a later stage or executed asynchronouslyin a separate thread. However, this delay was not a problem on the P-GRADEBioinformatics portal. • The validity of the Shibboleth assertion is usually limited to a few minutes, sothe
SLCS certificate request should not be delayed for too long. Of course if avalid
SLCS certificate for the user is already available from a previous login ofthe user, the request can simply be omitted. • When a
VOMS -enabled proxy is needed, it is the portal’s responsibility to promptthe user for the relevant information, e.g., VO name or Fully-Qualified AttributeName ( FQAN ) list. In the P-GRADE implementation, the users can set theirVOs in their settings page. There is a global default configuration option for theadministrator if every user is expected to be always member of the same VO .10 .1 Integration into the P-GRADE portal The P-GRADE portal comes with full Grid X.509 proxy support, which in this case isa mixed blessing as many of the certificate management features need to be modified invarious places of the portal code. Out of the box, P-GRADE supports proxy certificateupload or the usage of a MyProxy server to which the user has to upload the certificateoutside of P-GRADE.In its standard form, P-GRADE provides no facilities for the creation of the certifi-cates; this is a new feature we add using
GridCertLib . We extended the Shibboleth-enabled login [29] for the Gridsphere portal [13] (provided by the Australian MAMSproject [28]) by storing all Shibboleth attributes including the assertion and other at-tributes that were not previously requested into a singleton object.In the MAMS implementation, on first-time login using Shibboleth, the user ispresented with a registration request portlet which simply displays the attributes of theuser as received through the Shibboleth login by the server. Users can then simply pressa button “Send registration request”, which triggers an email to the portal administrator,who can decide whether to enable the user account, and optionally assign it certain rolesin Gridsphere.Users can simply reload the page or re-login once the admin has enabled them. Atthe same time it is checked whether an
SLCS certificate still exists for the given user andwhether it is valid for longer than 24 hours. If not,
GridCertLib is used to create a new
SLCS certificate. The certificate location and other related information is stored togetherwith all other user attributes in the user table, which has been extended accordingly.The
VOMS configuration is the same for all users of the portal in our current imple-mentation, which is set to the “life” VO of the national grid computing infrastructureSwiss Multi-Science Computing Grid ( SMSCG ) [36], using a portal-wide configurationof
GridCertLib .An issue remains: the delegation feature used by
GridCertLib is not yet deployed asa standard feature in the Swiss SWITCHaai federation, therefore we currently can onlymake use of this whole mechanism through a special home organization, the VirtualHome Organisation (
VHO ), provided by SWITCH for collaboration purposes. We havea dedicated group in the
VHO where we can administer our own users. This shouldnot be necessary anymore after the SWITCHaai federation has upgraded to a versionof Shibboleth that supports delegation, which should happen sometime in late 2011 or2012.For now, in the optimal case a user can log in through
AAI by selecting the
VHO asthe “home organization”, and is ready to submit Grid jobs to the Swiss Multi-ScienceComputing Grid. Clicking on the “Certificates” tab will show the details of the currentcertificates and their validity.Expiration of the certificate is not an issue, as P-GRADE requests the downloadof the results only when the user asks for it through the portal. The portal makes surethat a new proxy is generated automatically in the background from the
SLCS certificate(if the existing proxy is not valid anymore). Should the
SLCS certificate expire, a newone is requested automatically at the next login, so unless the user is actively using theportal browser window for 10 days with no interruption, this will not happen.
Django [8] is a high-level Python Web framework, providing reusable componentsto build any sort of web application. We have used it to build a simple portal for11sers of the computational chemistry application GAMESS-US [35, 12]. The por-tal uses the django-shibboleth application [31] to enable users to log in using theirSWITCHaai/Shibboleth credentials; new users will have their account created auto-matically when they log in for the first time.Django support in GridCertLib thus comprises two (inter-dependent) parts: • A Python package, containing the access-control decorators certificate required and gridproxy required . By using these decorators, a Django programmer caneasily mark some URLs as requiring the use of a valid SLCS certificate and/orproxy. • A set of Java servlets, which should be deployed alongside the Django site, thatinterface with
GridCertLib to provide the SLCS- and proxy-generation function-ality.All communication between the Django decorators and the corresponding servlets hap-pens by means of
HTTP redirects through the users’ web browser.The
GridCertLib
Django decorators will first ensure that the
HTTP request is authen-ticated with the standard Django login system; when the django-shibboleth applicationis installed, this automatically ensures that the
HTTP request is part of a valid Shibbolethsession.Next,
GridCertLib
Django decorators check that the certificate (resp. proxy certifi-cate) exists and is valid. For the sake of processing speed (no response can be sent to theweb browser until the decorator has passed control to the view function), the decoratorsassume that no other actor can modify the certificate/proxy files they have created: thusa simple “modification time” check suffices to prove that a certificate/proxy is still inits validity period. Note that, in contrast to what happens in the P-GRADE portal, thecertificate/proxy check happens each time the Django view function is invoked, and itis thus essential to keep it performant.If the certificate/proxy exists and is valid, environment variables are set to thefilesystem path of the relevant files to communicate the location to the Grid middle-ware, and control is passed to the view function.Otherwise, an
HTTP redirect response is issued, channeling the web browser to the
URL corresponding to a Django-specific version
SlcsInit or VomsProxyInit servlets. Asmentioned for the Example Servlets (see Section 3.2.3), only the
SlcsInit
URL needsto be Shibboleth-protected.
HTTP session cookies are used to tell the servlets to store the certificate/proxy in acertain filesystem location; however this poses a mild security threat: since the servletsURLs must be public (so that the users’ web browsers can visit them), then an HTTP request could be crafted to make the servlets read/write the certificate/proxy file in anarbitrary location on the filesystem. Security is enforced with the following procedure: Django structures a web site as an set of web applications, each of which is attached to specific URLsin the web site
URL space. Applications can be packaged and deployed separately, and can be thus re-usedin different combinations to build a site. Django routes
HTTP requests to Python functions (“view” functions), that are responsible for returningcontent to the user. Access control is most easily done through Python function decorators: if a view functionis marked with the login required decorator, then Django ensures that
HTTP requests to that
URL come fromlogged-in users, and will redirect any unauthorized request to the site login page. Since the
SlcsInit and
VomsProxyInit servlets run in a Java server, completely separated by the serverrunning Django, an issue arises as how to communicate certificate/proxy location and passphrases back andforth from the Django decorator to the Java servlets. Before starting the redirect to the a servlet, the Django access decorator createsan empty directory L , creates a “marker” file in it, and writes a random string K into this “marker” file. • The decorator redirects the web browser to the servlet
URL , passing along L and K (as HTTP cookies). • The servlet verifies that the “marker” file exists in L and that it has the expectedcontent K , then it deletes the “marker” file and proceeds. For added security, itcan optionally verify that L is a filesystem path starting with a configured prefix(e.g., ), so that possible damage is confined to a portion of thefilesystem.It is clear that the above procedure guarantees that hypothetical attackers can only trickthe GridCertLib servlets into writing into a location L if and only if they can alreadywrite to L .The added security layer is basically the only difference between the Django-support servlets and the GridCertLib example servlets (see Section 3.2.3). After suc-cessful creation of the certificate or proxy, the servlet redirects the web browser backto the initial requesting page with no output.As in the P-GRADE integration, two issues remain that might need special attentionin the future: • The
VOMS configuration is the same for all users: while it is possible to extendthe Django user object model to include individual
VOMS information, this isnot necessary at present since all users of the
GAMESS portal belong to the sameVirtual Organization. • Until the delegation feature becomes a standard feature of SWITCHaai, usershave to select the special home organization
VHO in order to use the portal.Django support for
GridCertLib provides an example of how
GridCertLib can beintegrated into an existing web framework with little coding and only small edits to tunethe example servlet behavior to the interface expected by other portal components.
GridCertLib is an easy to use Java library that enables automatic creation of
SLCS cer-tificates and/or Grid proxies from
SAML2 assertions obtained from successful Shib-boleth authentication. It can be integrated into real-world Grid portals, hiding thecomplexities of X.509 certificate usage from the portal user. This considerably low-ers the barrier to Grid usage, potentially allowing much larger communities to profitfrom Grid resources securely. Source code for
GridCertLib is publicly available from http://gridcertlib.googlecode.com/ under the Apache License version 2.0 [2].The current implementation of
GridCertLib relies on three key features of theSWITCHaai infrastructure: Shibboleth authentication,
ID-WSF ECP delegation, and the
SLCS online CA service. The integration of these three components together with a validaccess to a VOMS server, allow the creation of any community-specific web portal thatcan leverage the national grid computing infrastructure
SMSCG [36] thus enabling Griduse by virtually any Swiss scientific community.An interesting future development could be to adapt GridCertLib to draw certifi-cates from the (recently created)
TERENA on-line CA ; this would lift the dependency on13he Swiss infrastructure and potentially allow usage of GridCertLib on any EuropeanGrid infrastructure.More generally, one could investigate whether GridCertLib could be ported to pro-vide its functionality on top of equivalent base technologies (e.g., substitute Shibbolethwith a different
SAML -based federated authentication infrastructure). Developments inthis area could turn
GridCertLib into a modular system capable of providing its func-tionality for almost all Grid users today. No investigation has been carried out by usin this area: the project that funded
GridCertLib development had a practical scopeof producing a simple single sign-on solution for the selected portals; we are anywayopen to collaborations in this respect.
GridCertLib has already been successfully deployed and integrated into a Bioinfor-matics portal based on P-GRADE, and into a Django-based Computational Chemistryportal, proving the flexibility and re-usability of the library and its design.We will assist in the integration of
GridCertLib into portals that are in use inSwitzerland, like JOpera [21] and the new WS-PGRADE [22]. We will consider re-quests for extensions in functionality of the
GridCertLib based on the experience withthese new portals.Looking further into the future,
GridCertLib will greatly profit from the upgradeof the SWITCHaai federation to the next version of Shibboleth: this will enable truesingle-sign on and Grid usage in one portal, without the need to use a special
VHO ac-count. The SystemsX project SyBIT [41] also plans to upgrade its P-GRADE portalfrom the current Gridsphere-based implementation to the more modern WS-PGRADE,which makes use of the Liferay portal [26] technology: besides many portal-related im-provements, this will allow the users to freely choose the
VOMS attributes they wish toassociate with their proxy. However, due to the entirely new portal code base, a newprogramming effort will be needed to integrate
GridCertLib into the Liferay frame-work.
Acknowledgements
This work was carried out in the context of the “Swiss Grid Portal” project, fundedthrough the SWITCH-AAA track and through the SyBIT project of SystemsX.ch. Wewould like to thank all our collaborators in the Swiss Grid Portal project —CesarePautasso, Fr´ed´erique Lisacek, Heinz Stockinger— and also all the help we receivedfrom the Hungarian Academy of Sciences SZTAKI for the integration with P-GRADE,especially ´Akos Balasko.
List of acronyms
AAI
Authentication and Authorization Infrastructure AC Attribute Certificate (VOMS, X.509)
API
Application Programming Interface CA Certification Authority
CSR
Certificate Signing Request DN Distinguished Name 14 CP Enhanced Client or Proxy
EGEE
Enabling Grids for E-sciencE
FQAN
Fully-Qualified Attribute Name (VOMS)
GAMESS
General Atomic and Molecular Electronic Structure System, aComputational Chemistry application (see [35, 12])
GC3
Grid Computing Competence Center, University of Zurich
HTTP
HyperText Transfer Protocol
ID-WSF
Identity Domain - Web Service Framework (Shibboleth)
IGTF
International Grid Trust Federation
IdP
Identity Provider (Shibboleth)
MAMS
Meta Access Management System, an Australian development project(see [28])
PKI
Private Key Infrastructure
SAML
Security Assertion Markup Language
SAML2
Security Assertion Markup Language version 2
SARoNGS
UK development project (see [20])
SLCS
Short-Lived Credential Service
SMSCG
Swiss Multi-Science Computing Grid SP Service Provider (Shibboleth)
SSO
Single Sign-On
SWITCH
Swiss Academic Network Provider
TERENA
Trans-European Research and Education Networking Association
URL
Uniform Resource Locator
VHO
Virtual Home Organisation
VOMS
Virtual Organisation Membership Service VO Virtual Organisation
XACML eXtensible Access Control Markup Language15 eferences [1] Alfieri, R., Cecchini, R., Ciaschini, V., dell’Agnello, L., Frohner, ´A., L˝orentey, K.,Spataro, F.:
From gridmap-file to VOMS: managing authorization in a Grid envi-ronment , Future Generation Comp. Syst., Vol. 21, no. 4, 2005, pp. 549–558.[2] The Apache Software Foundation:
Apache License, Version 2.0 , . Cited April 17, 2011.[3] Barbera, R., Donvito, G., Falzone, A., La Rocca, G., Milanesi, L.,Maggi, G. P., and Vicario, S.: The GENIUS Grid Portal and robot certifi-cates: a new tool for e-Science , BMC Bioinformatics 2009, 10(Suppl 6):S21, .[4] Barton, T., Basney, J., Freeman, T., Scavo, T., Siebenlist, F., Welch, V., Anan-thakrishnan, R., Baker, B., Goode, M., and Keahey, K.:
Identity Federation andAttribute-based Authorization through the Globus Toolkit, Shibboleth, Gridshib,and MyProxy . 5th Annual PKI R&D Workshop, April 2006.[5] Barton, T., Cantor, S., Olshansky, S.:
Shib-uPortal Home , https://wiki.shibboleth.net/confluence/display/ShibuPortal/Home .Cited April 17, 2011.[6] Burruss, J. R., Fredian, T. W. and Thompson. M. R. “ROAM: An AuthorizationManager for Grids”, Journal of Grid Computing 2006, Volume 4, Number 4,Pages 413-423[7] Cantor, S., et al.: Shibboleth Federations , https://wiki.shibboleth.net/confluence/display/SHIB/ShibbolethFederations .Cited April 17, 2011.[8] Django , .[9] The European Grid Authentication Policy Management Authorityin e-Science: Guideline on IGTF Approved Robots, version 1.0 . . Cited Apr. 17, 2011.[10] Farkas, Z. and Kacsuk, P.: P-GRADE Portal: A generic workflow system to sup-port user communities , Future Generation Computer Systems, Vol. 27, Issue 5,May 2011, pp. 454–465, ScienceDirect.[11] Garzoglio, G., et. al.
Definition and Implementation of a SAML-XACML Pro-file for Authorization Interoperability Across Grid Middleware in OSG andEGEE , Journal of Grid Computing 2009, Volume 7, Number 3, Pages 297–307),doi:10.1007/s10723-009-9117-4[12] Gordon, M. S. and Schmidt, M. W.:
Advances in electronic structure theory:GAMESS a decade later , pp. 1167–1189, in
Theory and Applications of Compu-tational Chemistry: the first forty years , Dykstra, C. E., Frenking, G., Kim, K. S.,Scuseria, G. E. (eds), Elsevier, Amsterdam, 2005.[13]
Grisphere Portal , .Cited December 30, 2010. 1614] Hewitt, M., Kaushal, S.: Experiences of P-GRADE at the White Rose Grid e-Science Centre , http://portal.p-grade.hu/pucowo/download/slides/WRG-Mark-Shiv.ppt .Presentation held at the 2010 P-GRADE User Communities Workshop (PU-CoWo), ETH Z¨urich, June 10, 2010.[15] Hodges, J.: How to Study and Learn SAML http://identitymeme.org/doc/draft-hodges-learning-saml-00.html
Cited September 9, 2011.[16] Hodges, J., Aarts, R., Madsen, P., Cantor, S., Cahill, C., Champagne, D.,Ellison, G., Lockhart, R., Whitehead, G.:
Liberty ID-WSF Authenti-cation, Single Sign-On, and Identity Mapping Services Specification .[17] IGTF:
The International Grid Trust Federation Charter , . Cited April 17, 2011.[18] Internet2 Middleware Initiative: Shibboleth , . Cited April 17, 2011.[19] Internet2 Middleware Initiative: High Level Introduction to Shibboleth http://shibboleth.internet2.edu/HighLevelIntro.html . Cited Septem-ber 9, 2011.[20] JISC:
Shibboleth Access to Resources on the National Grid Service , .Cited April 17, 2011.[21] JOpera , .[22] Kacsuk, P.: P-GRADE portal family for Grid infrastructures , Concurrency andComputation: Practice and Experience, Vol. 23, Issue 3, 2011, pp. 235–245[23] Kacsuk, P., and Sipos, G.:
Multi-Grid, Multi-User Workflows in the P-GRADEPortal , Journal of Grid Computing, Vol. 3, No. 3-4, pp. 221–238, Springer Pub-lishers, 2005[24] Kacsuk, P. et al.:
WS-PGRADE: supporting parameter sweep applications inworkflows , 3rd Workshop on Workflows in Support of Large-Scale Science,In conjunction with SC 2008, pp. 1–10, IEEE, Austin, TX, USA (2008).doi:10.1109/WORKS.2008.4723955[25] Kouril, D., and Basney, J.:
A Credential Renewal Service for Long-Running Jobs .6th IEEE/ACM International Workshop on Grid Computing (Grid 2005), Seattle,WA, November 13-14, 2005.[26]
Liferay portal , .[27] Lorch, M. and Kafura, D.: The PRIMA Grid Authorization System , Journal ofGrid Computing, Vol. 2, No. 3, pp. 279–298, Springer Publishers, 2005.[28] MAMS project:
Meta Access Management System , https://mams.melcoe.mq.edu.au/zope/mams . Cited April 17, 2011.1729] MAMS project: Shibbolizing GridSphere demo , https://mams.melcoe.mq.edu.au/zope/mams/kb/all/GridSphere%20Wink%20demo.zip/view .Cited April 17, 2011.[30] MTA/SZTAKI: Grid User Support Environment , . Cited April 17, 2011.[31] Morrison, S.: django-shibboleth: Shibboleth login/registration integration , http://code.arcs.org.au/gitorious/django/django-shibboleth . CitedApril 17, 2011.[32] NCSA, MyProxy Credential Management Service , http://grid.ncsa.illinois.edu/myproxy/ . Cited December 30, 2010.[33] Novotny, J., Tuecke, S., and Welch, V.: An Online Credential Repository for theGrid: MyProxy . Proceedings of the Tenth International Symposium on High Per-formance Distributed Computing (HPDC-10), IEEE Press, August 2001, pages104-111.[34] Pearlman, L., Welch, V., Foster, I. Kesselman, C. and Tuecke, S. “ Commu-nity Authorization Service for Group Collaboration”, Proceedings of the 3rd In-ternational Workshop on Policies for Distributed Systems and Networks, 2002,pp.50–59.[35] Schmidt, M. W., Baldridge, K. K., Boatz, J. A., Elbert, S. T., Gordon, M. S.,Jensen, J. H., Koseki, S., Matsunaga, N., Nguyen, K. A., Su, S., Windus, T. L.,Dupuis, M., and Montgomery, J. A.:
General Atomic and Molecular ElectronicStructure System , J. Comput. Chem., 14, 1347–1363(1993).[36] SMSCG project:
Swiss Multi-Science Computing Grid , . Cited April 17, 2011.[37] SWITCH: Description of the SLCS , .Cited April 17, 2011.[38] SWITCH: Expert Session Add-On , .Cited April 17, 2011.[39] SWITCH: Simple Demo , .Cited April 17, 2011.[40] SWITCH: SWITCHaai – the key that connects students and the university , . Cited April 17, 2011.[41] SystemsX.ch: SyBIT: Systems Biology IT , .Cited April 17, 2011.[42] Tschopp, V.: ID-WSF ECP Web Service Client , https://forge.switch.ch/redmine/projects/idwsfecp . Cited December30, 2010.[43] Tschopp, V., and Witzig, Ch.: “Short-lived Credential Service - User Guide”,EGEE-II project, 2006, https://edms.cern.ch/document/788604/1 .1844] Tuecke, S., Welch, V., Engert, D., Pearlman, L., and Thompson, M.: InternetX.509 Public Key Infrastructure (PKI) Proxy Certificate Profile , RFC3820, TheInternet Society, June 2004,