An Approach for Shibboleth and Grid Integration
Francisco Pinto and Christian Fernau
Research Technologies Service, Oxford University
Abstract
Grid environments involve complex scenarios where PKI-based authentication and authorization
might have to be delegated across n-tier security domains. Shibboleth is an identity management
system designed to exchange attributes across domains for the primary purpose of authorization
and its architecture is highly dependent on PKI. Supported by a Registry Service, we propose a
non-intrusive approach where users access Grid resources protected by Shibboleth, using their
traditional proxy certificate carrying the users' DN. This service can also be used for VO
management, multi-identity support and possibly for ensuring anonymity. This document aims to
show a feasible approach for Shibboleth and Grid integration, and also for exploring other possible
directions of work.
1. Introduction
Standardisation bodies and working groups [1,
2] in the Grid arena have been doing studies and
producing reports identifying: authentication;
delegation; single logon; credential lifespan and
renewal; authorization; privacy; confidentiality;
message integrity; policy exchange; secure
logging; assurance and manageability, as the
most important components for the Grid
Security Infrastructure (GSI) [3, 4].
The Grid [5, 6, 7, 8, 9, 10, 11] is supported
by frameworks such as Globus Toolkit [12, 13],
which implement the GSI. Authentication is
based on X.509 identity certificates and X.509
proxy certificates. Proxy certificates are created
on-the-fly for accessing Grid protected
resources. They are signed by the users' identity
certificate and have a short life. MyProxy
provides a credential management service with
similar functionality via a portal environment
[14]. Authorisation is based on Access Control
Lists (ACL) associated with each resource.
Each entry specifies X.509 Distinguished
Names (DN) of the users allowed to access it.
Shibboleth is an identity management
system designed to provide federated security
[15]. It exchanges attributes across domains for
the primary purpose of authorization and its
architecture is highly dependent on Public Key
Infrastructure (PKI) [16]. It uses PKI to build
the trust between the several Shibboleth
components of the Federation members.
Shibboleth is agnostic in terms of the front-end
authentication and authorisation used. It just
specifies how the authentication and
authorisation flows should be exchanged
securely. End-user authentication based on PKI
is suitable, but not a requirement.
Figure 1 – Shibboleth Architecture.
As shown in Figure 1, users are identified by
an Identity Provider (IdP), typically located at
their own institutions (e.g. Universities in the
case of HE users). Resources (and Services) are
protected (shibbolized) by Service Providers
(SP), which can not only be placed locally, but
also at other institutions or even externally to
HE institutions (e.g. Publishers). SPs need to
identify the user (normally indirectly via an
opaque authentication handler, ensuring
anonymity), and obtain attributes about her/him.
When a user accesses a shibbolized resource
for the first time, the SP needs to identify the
institution where s/he is known, which is then
used to authenticate the user via Shibboleth's
AuthN Authority (aka Handle Service or HS)
and later on, during the authorisation phase, to
obtain attributes from Shibboleth's AuthZ
Authority (aka Attribute Authority or AA).
Shibboleth uses a Where Are You From
(WAYF) service, which although not mandatory
is normally used to ask the users' about the
institution they belong or are known.
Driven by the GSI functional requirements
and taking into account relevant literature in
this field [17, 18, 19, 20, 21, 22, 23, 24, 25, 26,
27, 28], this document concentrates on
authentication and authorisation with the aim to
provide security for Grid environments using
Shibboleth. This approach aims to ensure the
same level of assurance and minimal disruption,
in a more dynamic fashion.
2. Grid and Shibboleth
Shibboleth is a good candidate to match with
the Grid existing authentication mechanism and
provide an improved dynamic authorization
model. However, Shibboleth was initially
designed for 2-tier interactive environments
involving
Browsers
and
Web-based
applications, and not all Grid applications are
Web-based. In the absence of the interactive
environment provided by the Web infrastructure
in most of the Grid applications, there is the
need to pass the required information
Shibboleth does/needs via alternative methods.
2.1 GridShib Project Approaches
Substantial work has been done by the NSF
funded project, GridShib [29, 30]. Other
projects such as ESP-Grid [31] are also looking
at this problem space. The project has identified
two possible approaches to combine Grid and
Shibboleth. The Pull approach uses a proxy
certificate to pass additional information about
the location where the users' attributes live. In
this way, the SP obtains the users' DN and the
AA access point. This information is sufficient
to fetch the required attributes about the user.
The Push approach requires the user to contact
her/his AA before accessing the protected
resource. Proxy certificate and attributes are
then passed together during the authentication
process against the Grid resource. The project
also anticipates a combination of the two
approaches as a realistic possibility.
A major disadvantage about these two
approaches are that they require changes at the
existing Grid authentication and authorisation
mechanisms. They propose changes in the
authentication process (e.g. proxy certificate
extensions with additional information), in
order to obtain improved authorisation via
Shibboleth.
Figure 2 – ESP-Grid Simple Architecture.
The major advantage about this approach is
that it is not so intrusive as GridShib and
provides the same or better gains. It doesn't
require any changes to the current Grid
authentication mechanism and provides the
flexibility of Shibboleth for exchanging
authorisation data dynamically. This approach
works well with the traditional Grid
authentication mechanisms based on PKI,
ensuring the levels of assurance required.
Additionally, it is also suitable for Grid
applications not requiring high levels of
assurance (e.g. username/password credentials),
just requiring the Registry Service to provide
alternative mappings between the users'
identifier and the AA (e.g. based on username).
2.2.1. Other Directions
A possible scenario where our approach could
be very advantageous, is for Virtual
Organization (VO) Management [32]. The
Registry Service is a suitable place to manage
the VO required dynamic information within a
Grid/Federation in a scalable way. As shown in
Figure 3, a user with a special role of VO
administrator can setup a VO (e.g. VO-X)
within the Registry Service by inserting the
users, resources, metadata and policies required
for an inter-institutional collaboration.
2.2 An Alternative Approach
Following initial investigations with Shibboleth
and Grid computing, we propose an approach
where users access a Grid resource protected by
a Shibboleth SP, using their traditional proxy
certificate carrying the users' DN. Having the
DN, SPs have the authoritative information
about the users' IdP. Using a DN -> AA
mapping provided by a Registry Service (at the
Grid/Federation level), the SP can obtain the
required information about the AA to fetch the
necessary attributes about the user, as can be
seeen in Figure 2.
Figure 3 – ESP-Grid Complex Architecture.
A WAYF-like feature during the proxy
certificate generation would benefit immensely
any of the approaches, as it may address the
problem of multi-identities (e.g. users with
affiliation to more than one institution; users
with multiple roles in one institution), very
common in Grid environments. During this
process, the users might be asked about which
identity they are willing to use for a given Grid
session.
Identity has been a requirement of Grid
environments. This requirement doesn't have to
(and probably will not) be maintained in the
future. Although it might be possible to create a
layer of indirection at the Registry Service in
order to provide anonymity, this will make the
architecture much more complex, since the
Registry Service has to be in sync with all AAs
in the Federation. This possible direction of
work deserves further thought.
3. N-Tier Authentication Problem
Figure 5 – Grid Use Case.
SAML 2.0 is coming with a specification of
the Enhanced Client or Proxy (ECP) Profile,
missing in the current version 1.3 of Shibboleth.
Shibboleth 2.0 will come with an
implementation of ECP Profile, which will
addresses this requirement for
n-tier
authentication environments.
Portals and Grid environments normally require
the identity of the user to be travelling
(delegated) across multiple tiers in a machine to
machine interaction. These advanced scenarios
create the need to have entities in the middle of
the architecture acting as a proxy, posing a
security challenge, also know as the n-tier
authentication problem [33, 34].
Figure 4 – The N-Tier AuthZ Problem (Portal
Use Case).
As shown in Figure 4, this use case has a
user behind a Browser identifying her/him self
against a Portal. Beyond that point all access to
protected Resources/Services are proxied on
behalf of the user. User credentials are
delegated to the n-tier and all the entities
involved (including the user) have to trust that
no one is misbehaving somewhere in the chain.
Grid environments are not much different of
Portal environments, if we take out the first 2
tiers (since a Grid session does not normally
require a Web Browser, as shown in Figure 5).
Shibboleth does not presently have an
answer for these environments requiring n-tier
authentication. Shibboleth uses SAML [35] to
exchange authentication and authorization
assertions. These assertions can be used to
delegate user identity (or even credentials) to
the n-tier in a trusted and secure way.
Figure 6 – Advanced Grid Use Case.
Figure 6 shows an advanced Grid use case
taking advantage of the upcoming ECP Profile
to delegate credentials initially passed from the
Grid Application to the Job Manager, and next
to the Protected Resources/Services.
4. Discussion
Both our and GridShib approaches require
changes on Grid and/or Shibboleth software
components and, at some extent, on their
architectures. However, since Shibboleth was
designed for Web-based applications, these
changes were required anyway due to the
differences between the Web and the Grid
infrastructures.
GridShib approaches require changes at the
Shibboleth SP component and at the Shibboleth
architecture. They also require changes at the
Grid
client
components
during
the
authentication phase, with implications at the
Grid architecture.
Our approach requires changes at the
Shibboleth SP and an extra Registration Service
at the Federation level. This service could turn
to be an advantage, as there is a gap in the
Shibboleth architecture to manage the
Federation metadata, and a registry would be a
suitable candidate. Moreover, in terms of VO
management, the Registry Service could also be
shibbolized in order to ease access to the VO
administrators.
This document aims to show a feasible
approach for Shibboleth and Grid integration,
and also for exploring other possible directions
of work.
References
[1] Global Grid Forum, http://www.gridforum.
org/.
[2] Open Grid Services Infrastructure Working
Group, http://forge.gridforum.org/projects/ogsiwg/.
[3] Open Grid Services Infrastructure
Specification, http://forge.gridforum.org/
projects/ogsi-wg/doc-uments/Final_OGSI_
Specification_V1.0/en/1/Final_OGSI_
Specification_V1.0.pdf.
[4] The Globus Toolkit uses the Grid Security
Infrastructure (GSI), http://www-unix.globus.
org/toolkit/docs/3.2/security.html.
[5] The Grid: past, present, future, F. Berman,
G. C. Fox and A. J. G. Hey.
[6] The Grid: A new infrastructure for 21st
century science, I. Foster.
[7] The evolution of the Grid, D. De Roure, M.
A. Baker, N. R. Jennings and N. R. Shadbolt.
[8] The anatomy of the Grid, I. Foster, C.
Kesselman and S. Tuecke.
[9] The physiology of the Grid, I. Foster, C.
Kesselman, J. M. Nick and S. Tuecke.
[10] The data deluge: an e-Science perspective,
T. Hey and A. Trefethen.
[11] Grids in Context, L. Smarr.
[12] The Globus Alliance, http://www.globus.
org/.
[13] Grid Computing - On demand series, J.
Joseph and C. Fellenstein.
[14] An Online Credential Repository for the
Grid: MyProxy, J. Novotny, S. Tuecke and V.
Welch.
[15] Federated Security: The Shibboleth
Approach, R. L. "Bob" Morgan, S. Cantor, S.
Carmody, W. Hoehn and K. Klingenstein.
[16] Which PKI (public key infrastructure) is
the right one?, C. Adams, M. Burmester, Y.
Desmedt, M Reiter and P. Zimmermann.
[17] EU DataGrid and GridPP Authorization
and Access Control, L. Cornwall, J. Jensen, and
D. Kelsey.
[18] An Authorisation Interface for the GRID,
D. W. Chadwick.
[19] Bridges: Security Focused Integration of
Distributed Biomedical Data, R. Sinnott, D.
Gilbert, D. Berry, E. Hunt and M. Atkinson.
[20] GRID Authorization Framework for
CCLRC Data Portal, A. Manandhar, G.
Drinkwater, R. Tyer and K. Kleese.
[21] Security and confidentiality approach for
the Clinical E-Science Framework (CLEF), D.
Kalra, P. Singleton, D. Ingram, J. Milan, J.
MacKay and D. Detmer.
[22] Access Control for Dynamic Virtual
Organisations, D. Russell, P. Dew and K.
Djemame.
[23] Removing digital certificates from the enduser's experience of Grid environments, B.
Beckles.
[24] Policy Management Authority Model
Charter, R. Cowles.
[25] Grid Authentication Authorization and
Accounting Requirements Research Document,
S. Mullen, M. Crawford, M. Lorch and D.
Skow.
[26] Conceptual Grid Authorization Framework
and Classification, M. Lorch, B. Cowles, R.
Baker, L. Gommans, P. Madsen, A. McNab, L.
Ramakrishnan, K. Sankar, D. Skow and M.
Thompson.
[27] Security Implications of Typical Grid
Computing Usage Scenarios, M. Humphrey and
M. Thompson.
[28] An Analysis of the UNICORE Security
Model, T. Goss-Walter, R. Letz, T. Kentemich,
H.-C. Hoppe and P. Wieder.
[29] GridShib, A Policy Controlled Attribute
Framework, http://grid.ncsa.uiuc.edu/GridShib/.
[30] Attributes, Anonymity, and Access:
Shibboleth and Globus Integration to Facilitate
Grid Collaboration, V. Welsh, T. Barton, K.
Keahey and F. Siebenlist.
[31] ESP-Grid, Evaluation of Shibboleth and
PKI for Grids, http://e-science.ox.ac.uk/ oesc/
projects/ index.xml.ID=body.1_div.20.
[32] Using the VOM portal to manage policy
within Globus Toolkit, A. Saleem, M. Krznari,
J. Cohen, S. Newhouse and J. Darlington.
[33] Trusted Delegation of Privileges in an NTier Environment, Chad La Joie,
http://middleware.internet2.edu/webiso/docs/dra
ft-lajoie-trust_and_delegation-02.html
[34] Delegation/Intermediaries use case model,
RL “Bob” Morgan, http://staff.washington.edu/
rlmorgan/ misc/draft-morgan-sstc-delegationmodel-00.pdf.
[35] Profiles for the OASIS Security Assertion
Markup Language (SAML) V2.0, OASIS,
http://docs.oasis-open.org/security/saml/ v2.0/
saml-profiles-2.0-os.pdf.