Single Sign-on to the Grid

Document Sample
Single Sign-on to the Grid Powered By Docstoc
					                          Single Sign-on to the Grid
                           D Byard and J Jensen, CCLRC
                              All Hands Meeting, Sep 2005

    This paper describes work done to provide single sign-on (SSO) access to Grid resources
for scientists across different disciplines. Building on existing technologies, such as portals
and the Globus MyProxy server, we describe how we integrated these with CCLRC’s site
authentication system, Microsoft Active Directory®2000, to obtain SSO access to the Grid.
We discuss in detail experiences with providing access to the NGS clusters and CCLRC’s
SCARF cluster for scientists in the Diamond synchrotron and CCLRC’s pulsed neutron muon
source, ISIS. The work described above was done initially with a simple portal written in
Python. We also describe our experience with integrating single sign-on with existing portal
frameworks such as CHEF, SAKAI, and uPortal. We also describe some approaches taken
towards single sign-on which do not involve portals. Such approaches are useful for “thick
clients”, i.e., clients that require more than a web browser on the user’s machine to access the
Grid or other resources.

1     Introduction                                  related to a particular workflow. In this paper
                                                    we show how portals can ease the perceived
CCLRC’s e-Science centre provides several           burden of managing the security without sig-
Grid resources: parts of the National Grid          nificantly impacting security.
Service [10], and other computing resources             For users who do not use portals, but have
such as the SCARF [13] cluster; storage             the workflow encoded in software running on
resources such as terabytes of disk arrays          the client side, we need to be able to simplify
and a petabyte scale tapestore, and meta-           the security process as well, in a way that is
data databases. These resources are provided        compatible with the SSO infrastructure pro-
for scientists working in the facilities within     vided for the portals.
CCLRC such as ISIS [6] and the laser facility           The challenge is further that scientists ex-
CLF [2], and for Diamond [3], and for exter-        ternal to the site must be able to collaborate
nal scientists. The resources are accessed both     with those who use the site SSO. And finally,
by permanent staff and by visiting scientists,       scientists who normally use the SSO must be
who in turn may be either on-site or back at        able to access their own Grid accounts also
their home institution.                             off-site, i.e. outside the site’s SSO framework.
    Scientists working locally typically log into       In doing this, because of time/effort con-
the site’s authentication system, in our case       straints, we needed to reuse existing compo-
Microsoft Active Directory[8] using username        nents and “glue” them together, rather than
and password. Normally this is not sufficient         spend a long time implementing new things.
to do work on the Grid; users also need to          While this methodology has allowed us to de-
remember passwords or passphrases to access         liver a product fairly quickly and with rela-
machines from which they submit jobs to the         tively little effort, it has the disadvantage that
Grid (i.e. User Interfaces, or UIs), or to access   not all components could be easily glued to-
portals. They also need to remember user-           gether and we had to abandon a direction rel-
names and password for their MyProxy [11]           atively quickly if we could not immediately
credential, and the passphrase that protects        make it work. For example, we could make
the private key that corresponds to their cer-      the SSO infrastructure work only with some
tificates.                                           of the portal frameworks, and in the end chose
    One of the promises of portals is that they     to implement our own demonstration portal
can simplify the users’ work by encoding the        in python, because it is easier to “glue” things
workflow: the portal can make the usual steps        together in python than in Java. Nevertheless,
required to process data easier to do and to        we will discuss how to implement our security
remember. We do not consider this in this           frameworks also with existing portal frame-
paper, since the work here is generic and not       works.
    This paper will be of interest to anyone       sense that once a proxy is generated, and as
working with Grid authentication, single sign-     long as it is valid and accessible to client appli-
on, and credential conversion. While we have       cations, the applications can use the proxy to
built on our site’s Active Directory, this work    act on behalf of the user. However, in the con-
will also apply to sites with a Kerberos 5 in-     text of this paper, SSO is seen in a wider con-
frastructure. More generally, the concepts of      text. Indeed, for the facilities within CCLRC,
credential conversions and “glue” will be ap-      the first concern is to integrate and maintain
plicable in wider authentication contexts.         the users identities in a database. When the
                                                   user registers with the facility’s user office,
                                                   (s)he is also registered in a database which
2     Single Sign-on to the                        is shared by the facilities. The challenge here
                                                   is to ensure that this personal data is kept up
      Grid                                         to date, and to ensure that no user appears
User authentication is a cornerstone of mod-       more than once in the database (e.g. with
ern IT infrastructures, whether it’s a site’s      different forms of the name, or with differ-
internal infrastructure, an inter-institutional    ent addresses). The facilities themselves have
collaboration framework, e-Commerce, or a          worked with the database provider, CCLRC’s
multinational Grid. The challenge is to make       Business and IT Department (BITD), to agree
the authentication tokens interoperate, and        common metadata formats and tools for this
make the interoperability as seamless as pos-      purpose. We are working with them to enable
sible for the user. Working with multiple re-      our SSO infrastructure to automatically reg-
sources quickly becomes tedious if the user        ister users and create Grid accounts for them
needs a separate authentication token for each     when they are approved by the facility’s user
resource, and must type a password to active       office.
each token. Indeed, this can weaken security
because some users are unable to remember          2.1     Grid single sign-on
several passwords, and they will either reuse
a password, or use a birthday or their name,       Authentication on the Grid uses X.509 cer-
or write the less common ones on a piece of        tificates. Each user and each host has its own
paper and tape it to their monitor.                Grid identity, unique worldwide, encoded in
    There is always a tradeoff between usabil-      a certificate issued by a trusted certification
ity and security. High security often requires     authority.
that the user proves his or her identity fre-          To facilitate SSO, Globus created a proxy
quently or via multiple independent methods.       certificate, now standardised by IETF as
Cash machines have a pretty good security          RFC 3820 [14]. A proxy is, in this context,
record because access to the user’s account        a certificate with an unprotected private key,
requires two independent tokens, something         readable only by the user, and signed by the
held (the card), and something known (the          user’s personal certificate (or by another of
PIN). Only by using both at the same time          the same user’s proxies, to form a chain of
can the user gain access to the account. But,      proxies). Applications run by the user can
as we saw above, high security requirements        authenticate themselves on behalf of the user
that lessen usability of the system can weaken     using the proxy, and thus there is no need for
the security, because users will find ways to       the user to type a passphrase every time the
circumvent the security. Had the PIN con-          application is run.
sisted of 12 digits rather than 4, most people         A proxy cannot be revoked, so for security
would write the PIN on a piece of paper and        reasons, it has a relatively short lifetime —
store it with the card.                            typically 12 hours. This is a not acceptable,
    The challenge is thus to enhance inter-        because jobs sometimes run for more than 12
operability between security solutions, with-      hours. To overcome this problem, it is nec-
out significantly compromising the security         essary to renew the proxy, i.e. to generate a
aspects of the infrastructure.                     new proxy signed by the proxy’s issuer (as-
    It is not the purpose of this paper to pro-    suming the issuer itself has a sufficiently long
vide a general discussion of security issues for   lifetime). But renewing from the user’s certifi-
authentication. In this paper we focus on our      cate requires that the user is present to type
work with credential conversion and the inte-      a passphrase.
gration between the components and the in-             To overcome this problem, NCSA’s
frastructure.                                      MyProxy server [11] stores a longer lived
    Many middleware components already             proxy (lifetime typically one week) which can
claim to support SSO. Indeed, most compo-          be used to renew the proxies that run the jobs.
nents that use Globus Security Infrastructure      A job wrapper can monitor the job’s 12 hour
(GSI, [4], [5]) already support SSO in the         proxy and use it to get a renewed proxy from
the MyProxy service just before it expires, un-     reasons. First of all, it was easier to inte-
til the job terminates (or the MyProxy proxy        grate with the existing MyProxy service pro-
expires) and its output files have been safely       vided by the Grid Support Centre, and with
copied to some Grid storage service.                other workflow paths of ours that require ac-
     The user has to renew the proxy in the         cess to the MyProxy server. Secondly, since
MyProxy server, but that only has to be done        we had time constraints, we had to give prior-
once every week.                                    ity to the easiest solution. Finally, username
                                                    and password are simple and ubiquitous that
                                                    the methods we have developed to authenti-
2.2     Kerberos                                    cate with username/password to the MyProxy
Another approach to SSO was taken by Ker-           server can also be used to access other related
beros. Briefly, Kerberos provides a central          services that do not support more advanced
key distribution service, the KDC, which dis-       authentication mechanisms.
tributes symmetric keys, tickets to the users           We used Sakai to develop a proof of con-
to access services. The user holds a ticket         cept where, if Apache successfully authenti-
granting ticket (TGT) which allows him/her          cated users via the Kerberos token, the portal
to obtain specialised tickets to access services.   logged them in automatically. In fact, it was
Tickets have a lifetime, and may or may not         impossible for users to log out because the lo-
be renewable.                                       gout screen would log the users back in!
                                                        However, Sakai was not standards compli-
                                                    ant. Standards compliance is a big factor as
2.3     Microsoft Active Direc-                     it means that in the future you won’t be stuck
        tory                                        with archaic technologies that are hard to find
                                                    support for or maintain. JSR-168 is the estab-
Our site’s authentication system is built on        lished API for portlets (portal components),
Microsoft Active Directory (AD), which is it-       and, at least ideally, a JSR-168 compliant
self an extension of Kerberos 5. AD is also in      portlet can be deployed within any compliant
wide use in industry. The user has an iden-         portal framework.
tity consisting of a local federal id within a          Therefore we expanded our work to also
specific Kerberos realm. When the user logs          work with uPortal. This turned out to be
in, the system obtains a TGT, plus, usually         a more elegant solution as uPortal has in-
a few tickets for essential services, such as       built (albeit poorly documented) support for
LDAP. Those tickets are all renewed by Win-         overriding its authentication systems when
dows without the user’s intervention.               Apache has successfully authenticated a user.
                                                        However, with uPortal we had configura-
2.4     Portals                                     tion problems that had nothing to do with
                                                    SSO, and we were unable to do a reasonable
One way of addressing the varying problems          demonstration.
of software and hardware incompatibility as             Thus, to be able to demonstrate portal ap-
well as workflow is to use a Portal. Briefly, a       plications, we used mod python under Apache
Portal is a dynamic web-site that provides a        to develop our own simple Portal framework
user interface for tasks, using server-side ap-     with enough functionality to provide a com-
plications, commonly known as Portlets. Ev-         plete demonstration of a portal which submits
erything runs on the server and all the client      and tracks jobs running on the Grid services.
requires is a web-browser to view the site.
    The most common standard for Portlets is
                                                    2.4.2    Running jobs for the user
JSR168 [7], which defines a standard for writ-
ing Java-based Portlets. There are Portlets         We saw above that the portal can run jobs as
available for many tasks, including a open-         the user by delegating the user’s authentica-
source Portlet suite for managing Grid Cre-         tion token to the portal. Another possibility
dentials and running jobs, OGCE [12].               is to let the portal run the job for the user,
                                                    i.e., the computing cluster sees only a generic
2.4.1    Running jobs as the user                   portal user. The advantage of this approach
                                                    is that it greatly simplifies the SSO infrastruc-
Our portal obtains a delegated proxy for the        ture, because the user only has to authenticate
user from a MyProxy server, and the portal          to the portal, not to the computing cluster.
runs and tracks the job on behalf of the user.           The disadvantage of this approach is the
    The MyProxy server does in fact provide         lack of authentication on the computing clus-
a Kerberos authentication mechanism, as well        ter. If the user violates an acceptable use pol-
as one time passwords, and others. We chose         icy, then it is necessary to consult the portal’s
to keep using username and password for three       logs to find out who it was. This is unaccept-
able to most computing resource providers.             We have accommodated this need for
    The other disadvantage is that the account     thick clients by providing a small applica-
information on the cluster is not the same         tion which contacts an intermediatory Apache
as when the user accesses the cluster directly     server that then contacts the MyProxy server
(not via the portal).                              after mapping the user’s Active Directory to-
    And a final disadvantage is that the job        ken to a MyProxy login and password. It
does not have delegated credentials from the       would be useful to place this application in
user, or at least it cannot get it from the por-   the user’s login scripts, so that it runs auto-
tal. It may need this to transfer files for the     matically whenever the user logs in.
user.                                                  It is not quite as simple as using the AD
                                                   token directly to access the MyProxy server,
2.5     Client    platform                and      because we need to supply the same username
                                                   and password to the MyProxy server that the
        “thin” clients                             server would have seen, had the same request
The typical scientist using the SSO system         come from the portal. In other words, we need
will be using a Microsoft Windows operating        to ensure that portal access and access via
system, either Windows 2000 or Windows XP,         thick clients are compatible within our SSO
and they usually access portals via Internet       framework.
Explorer. Thus, the primary goal is to sup-
port SSO on these two operating systems, and
using IE as the “thin client”.                     3     Technical Details
    As a secondary goal, we have tried us-
ing other browsers, both on Windows and            In this section we provide further technical de-
Linux. We have found that SSO works on             tails about the implementation that we have
Windows with Firefox if a “trusted negoti-         deployed.
ate” parameter is set in the configuration.
Users must open the URI about:config, and          3.1     Thin clients and Portals
set network.negotiate-auth.trusted-uris
to the fully qualified domain name of the re-       There are two different basic authentication
mote server, with https prepended. Firefox         models for running Grid jobs via portals. Ei-
considers SSO a security risk, so the feature      ther the portal runs the jobs on behalf of the
has to be enabled explicitly.                      user, with credentials delegated from the user
    The same procedure works for Firefox on        to the portal, or the portal runs the jobs us-
Linux, but users must have a valid TGT be-         ing its own identity. The latter is simpler to
fore launching Firefox (i.e., must run kinit).     implement, but may not be accepteable to the
Konqueror also works and doesn’t need any          resource administrator who will not immedi-
extra setup, but again requires a valid TGT.       ately see the user’s identity. We shall look at
                                                   the two cases in the sections below.

2.6     Client    platform                and
        “thick” clients                            3.2     Binding Apache Kerberos
                                                   Apache doesn’t support Kerberos Authen-
Grid software is available on Windows in
                                                   tication out of the box, but there is an
varying forms such as the CoGKits [15] or
                                                   open-source module available named “modau-
WinGlobus. However, these versions are more
                                                   thkerb.” [9].
limited than the UNIX offerings and are more
                                                       We compiled modauthkerb ourselves.
geared towards developers of “thick” clients
                                                   modauthkerb depends on a valid Kerberos 5
than users who want to submit jobs to the
                                                   client development environment being avail-
Grid. They only offer basic job submission
                                                   able, as well on a valid /etc/krb5.conf file.
and monitoring, and do not mesh into the
                                                   This is site specific, but for reference, our ver-
workflow of a typical Windows environemnt
                                                   sion of this file contains the following (with
                                                   some linebreaks inserted):
2.7     Thick Clients                                default =
A thick client is, loosely speaking, an appli-             FILE:/var/log/krb5libs.log
cation running on the user’s personal com-           kdc = FILE:/var/log/krb5kdc.log
puter which is more “complicated” than a web         admin_server =
browser. In practical terms, in the context                FILE:/var/log/kadmind.log
of this paper, a thick client is an application
which requires access to a proxy to act on be-     [libdefaults]
half of the user.                                    ticket_lifetime = 24000
Turns on                                                                                                                                                      or
                                                                                                       Goes                        Website                    Invalid     Website
  PC at                                                                  Logged
                                                                                                     to portal                     checks                                  rejects
 start of                      Types Windows                               on
                                                                                                       in IE                        token                                connection
   day                           password

                               Active Directory
                                and provides
                                 a Kerberos
                                    token                                                                                         Portal maps
                                                                                          Portal looks up                          username
                                                                                         MyProxy password                         embedded in
                                                                                                                                 token to a DN

                                                                                             Portal gets                          User gives
                                                                                              credential                         portal correct
                                                                                           from MyProxy                           password

                                    User on Grid
                                     via portal!

                                                           Figure 1: Workflow for daily login

      Turns on
                                                                                                           Opens                     Types Grid
        PC at                                                                  Logged                                                                                    Updator
                                                                                                            Proxy                     certificate
       start of                     Types Windows                                on                                                                                     terminates
                                                                                                           Updator                   passphrase
        week                          password

                                                                                                         Updator stores
                                    Active Directory                                                     credentials on
                                     authenticates                                                       MyProxy server                       Updator loads
                                     and provides                                                   using DN as username                        certifcate
                                      a Kerberos                                                    and triple-SHA1 hash of
                                         token                                                      Grid password clamped
                                                                                                to printable ASCII as password

                                                        Portal maps
         Portal stores up                                username
     MyProxy password for DN                            embedded in
                                                       token to a DN
                                                                                                  Updator connects to proxy
                                                                                Valid                webpage providing
                                                                                                MyProxy username, password
                                                                                                and server as POST elements

                                    Mapped DN                                   token
                                    does not                 Missing
                                    equal                    or
                                    passed DN                Invalid

            User ready for
            daily operation

                                                                  Website                   Updator terminates
                                                                   rejects                     telling user to
                                                                 connection                  contact helpdesk

                                                         Figure 2: Workflow for weekly login
  default_realm = FED.CCLRC.AC.UK                3.4     Existing portal configura-
[domain_realm] = FED.CCLRC.AC.UK          We have had varying success with getting dif-
                                                 ferent Java-based portal frameworks to under-
[realms]                                         stand this system for authentication.
  FED.CCLRC.AC.UK = {                               ˆ Chef: We decided that with Chef it was
    kdc = FED.CCLRC.AC.UK                             not possible within a decent timeframe.
    admin_server = FED.CCLRC.AC.UK
                                                    ˆ Sakai: Sakai version 2.0 is relatively easy
    default_domain = RL.AC.UK
                                                      to allow container authentication.
                                                        1. You      will    need      to     edit
[pam]                                             to contain the
  debug = false                                            following:      top.login = false
  ticket_lifetime = 36000                                  container.auth = true
  renew_lifetime = 36000                                2. You will also need to edit the Lo-
  forwardable = true                                       gin UI, found in webapps/sakai-
  krb4_convert = false                                     chef-tool/vm/sitenav/login.vm
                                                           to access this system: <input
    Apache needs to be configured to use                    type="button" class="button"
modauthkerb, and the easiest way we discov-                value="Login through SSO"
ered was to set Apache to only accept HTTPS                onclick=
requests, and to allow all overrides under the             "parent.location=$login url"
Apache document root. Then under particu-                  />
lar directories in the document directory that
                                                    ˆ uPortal:     uPortal will require you
you wish to protect via Kerberos authentica-
                                                      to use the RemoteUserSecurityContext
tion, you can create a .htaccess file. The
                                                      and RemoteUserPersonManager classes
particular file used on our system is:
                                                      within your authentication chain. These
AuthName "Kerberos Login"                             are distributed with uPortal.
AuthType Kerberos                                   ˆ StringBeans: We haven’t had time to ex-
KrbSaveCredentials On                                 plore StringBeans, but it has potential
KrbMethodK5Passwd Off                                 for further development.
KrbMethodK4Passwd Off
KrbMethodNegotiate On
                                                 3.5     Integrating Portals into
"/etc/Keytabs/apache.krb.keytab"                         SSO workflow
require valid-user                               Further improvements to the SSO system has
   With this configuration you will require a     been made by integrated certificate requesting
Kerberos service credential for your machine     and MyProxy password management into the
in /etc/Keytabs/apache.krb.keytab. This          workflow.
can be acquired from the Kerberos Domain             We have created a simple program that
Controller (this will be the Primary Domain      uploads a certificate to the MyProxy server,
Controller in an Active Directory setup) and     using a username automatically gained from
must be a service credential in the format       the user’s Kerberos credentials. The password
HTTP/, even though we          is generated from a triple SHA1 hash of the
are using HTTPS.                                 user’s Grid passphrase so that it’s secure and
                                                 recoverable and requires less passwords to be
                                                 remembered by the user. This also has the
3.3    Running Tomcat under                      benefit of being recoverable.
       Apache                                        This program also communicates with the
                                                 Portal using the user’s Kerberos credentials
We use a standard version of Tomcat              and notifies it of the MyProxy username and
running under Apache using the AJP13             password to use, keeping it in sync. The ef-
protocol [1] combined with the Apache            fect of this is that the user merely types their
mod jk module, available in most server          Grid passphrase once at the beginning of a
Linux distributions, such as Debian sta-         week and the system handles all of the rest,
ble.    Tomcat must have an extra term,          making significant gains to workflow.
tomcatAuthentication="false" appended                The system is set to be extended to bind
to the AJP13 connector in server.xml for it      in with certificate requesting and renewal as
to pick up the authentication provided by the    well, further reducing confusion and password
modauthkerb Apache module.                       reliance for most Grid operations!
3.6     Experiences                                want to do, and on early feedback from the
                                                   users. This includes:
3.6.1    Did we achieve single sign-on?
We have achieved a simple single sign-on, re-         ˆ Making the official NGS portal work
quiring users to:                                       with SSO, which means integrating our
    ˆ Every year, obtain or renew a certificate.         SSO infrastructure with stringbeans.
    ˆ Every week, renew the MyProxy creden-           ˆ Review potential vulnerabilities in the
      tials.                                            system and fix them.
    ˆ Every day, log in to workstation.
    With the aid of simple tools to help the          ˆ Improve the workflow.
user through the process, all of these steps can
                                                      ˆ Integrate with other SSO systems.
be improved, but the essential aim is to im-
prove the daily workflow (schematically seen
                                                      ˆ Further integration with the facilities’
in Figure 1), so that users normally only have
                                                        user database, including authorisation
to type a passphrase once each day.
                                                        via attribute certificates.

3.6.2    Certificates                                  ˆ Integrate with Grid resource sign-up.
As can be seen from the above discussion, ev-
ery single person who accesses the Grid will
need to have certificates. In theory, changing
the Grid infrastructure to accept Kerberos or
                                                   4.2     Shibboleth
AD tokens should be possible; at least this is
                                                   Shibboleth is an infrastructre developed as
the promise of the GSSAPI. However, things
                                                   part of the Internet2, designed to feder-
are rarely that simple, and there is more to
                                                   ate bewteen authentication systems. Briefly,
Grid middleware security than Globus GSI.
                                                   when a user tries to access a resource, the
For example, EGEE provide their own con-
                                                   resource is able to base authentication on a
nectors to Tomcat.
                                                   token issued by the user’s home institution.
    Since we did not have the time or effort
                                                   Thus, the users need only authenticate them-
to hack GSI, we chose to require that every
                                                   selves to their own home institutions. The
person who will access the Grid will need cer-
                                                   corollary is that some “glue” is required to
tificates. The advantage of this approach is
                                                   interface the trust Shibboleth authentication
that scientists can also use certificates when
                                                   service at the institution to the institution’s
they’re off site.
                                                   own authentication service. The easiest step
                                                   is to issue This “glue” interface is essentially
3.7     Security                                   the same as the work we’ve described in this
In the portal solution, the portal is the single   paper.
point of failure, and the portal has essentially       A Shibboleth infrastructure will enable
unrestricted access to the MyProxy server by       single sign-on not just for scientists within one
storing passwords for each of the users that       institution, but for all institutions within the
will access the Grid via the portal.               authentication services federated by the Shib-
    If the portal is down, users can at least      boleth infrastructure. This is obviously a bet-
submit jobs “manually” from a UI, because          ter solution than ours, but it does require that
they know the password that the user uses          all Grid middleware that requires authentica-
on their behalf. But if someone breaks into        tion be modified to work within a Shibboleth
the portal, they have access to the users’         infrastructure. Several such efforts are under
passwords and can get credentials from the         way.
MyProxy server for all portal users. This is          However, it is likely that there will remain
not substantially different from an attacker        a need for credential conversion in the future,
breaking into a UI (gaining root access), be-      beyond that required to glue Shibboleth and
cause an attacker can compromise the pass-         the site’s authentication service together.
word management software on the UI as well.
                                                       For example, one can imagine several dif-
                                                   ferent authentication tokens, say a SAML as-
4       Future work                                sertion and proof of possession of a smartcard
                                                   be combined to form a stronger token. The
                                                   requirement for combined tokens can be en-
4.1     Further work                               coded in a policy file, but there may be legacy
We have some further plans for work we in-         applications that cannot immediately be con-
tend to do with the system, based on what we       verted to use policies.
5     Conclusion                                  [6] Isis. (June
In this paper we have described how we with
                                                  [7] Jsr168 portlet specification.
relatively simple tools have glued together
components to achieve credential conversion
                                                      (June 2005).
and, through that, single sign-on, for scien-
tists within our institution.                     [8] Microsft. Active Directory. (June 2005).
    Using the tools, SSO is achieved both         [9] Kerberos Module for Apache.
using “thin” clients, browsers accessing the
Grid via SSO-enabled portals, and for “thick”         (June 2005).
clients, Grid-aware client applications.
                                                 [10] National Grid Service.
    The single sign-on infrastructure inte-
                                             (June 2005).
grates with the site’s database services, and
is compatible with other, non-portal, access     [11] J. Novotny, S. Tuecke, and V. Welch.
to the Grid resources.                                An online credential repository for the
    While there is still more work to be done,        grid: Myproxy. Proc. 10th Int’l Symp.
we have achieved our aim of putting together          on High Perf. Dist. Comp. (HPDC),
a usable service with relatively little effort,        pages 104–111, August 2001.
based on existing simple components.             [12] Open Grid Computing Environment.
                                                 [13] Scientific Computing Application
 [1] AJPv13. (June 2005).                             Resource for Facitilies.
                                             (June 2005).
 [2] Central Laser Facility. (June 2005).      [14] S. Tuecke, V. Welch, D. Engert,
                                                      L. Pearlman, and M. Thompson.
 [3] Diamond Light Source.
                                                      Internet x.509 public key infrastructure (June
                                                      (pki) proxy certificate profile, June 2004.
                                                 [15] G von Laszewski, I. Foster, J. Gawor,
 [4] Globus. Grid security infrastructure for         and P. Lane. A Java Commodity Grid
     globus toolkit 2.                                Kit. Concurrency and Computation:
 [5] Globus. Grid security infrastructure for         Practice and Experience, 13:643–662,
     globus toolkit 3.                                2001.

Shared By:
Description: Single Sign-on to the Grid