ABFAB R. Smith
Internet-Draft Cardiff University
Intended status: Informational M. Tysom
Expires: September 6, 2011 S. Cooper
JANET(UK)
March 5, 2011
Application Bridging for Federated Access Beyond web (ABFAB) Use Cases
draft-ietf-abfab-usecases-00
Abstract
Federated authentication is most commonly associated with Web-based
services, but there is growing interest in the application of
federated authentication for non-Web services. The goal of this
document is to drive the development of requirements.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 6, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
Smith, et al. Expires September 6, 2011 [Page 1]
Internet-Draft ABFAB Use Cases March 2011
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Context of Use Cases . . . . . . . . . . . . . . . . . . . . . 3
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.1. Cloud Services . . . . . . . . . . . . . . . . . . . . . . 3
4.2. High Performance Computing . . . . . . . . . . . . . . . . 4
4.3. Grid Infrastructure . . . . . . . . . . . . . . . . . . . . 5
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 6
Smith, et al. Expires September 6, 2011 [Page 2]
Internet-Draft ABFAB Use Cases March 2011
1. Introduction
Federated identity facilitates the controlled sharing of information
about principals, commonly across organisational boundaries. This
avoids redundant registration of principals who operate in multiple
domains, reducing administrative overheads and improving usability
while addressing privacy-related concerns and regulatory and
statutory requirements of some jurisdictions.
This information may include authentication state that a consumer can
use, for example, to make access management decisions. A number of
mechanisms support the transmission of this information for Web-based
scenarios (see, for example [OASIS.saml-profiles-2.0-os]), but there
is interest in the application of federated identity in non-Web use
cases. This document describes some of these.
2. Terminology
TODO
3. Context of Use Cases
The use cases described in the present document are a result of work
led by JANET(UK), the operator of the United Kingdom's education and
research network, responding to requirements from that particular
community.
In the interest of promoting the development of technology of broad
applicability, the present authors welcome use cases and requirements
from other sectors and communities.
4. Use Cases
4.1. Cloud Services
Many organisations are seeking to deliver services to their users
using 'Cloud'-based providers. This is typically motivated by a
desire to avoid management and operation of commodity services which,
through economies of scale and so forth, can often be delivered more
efficiently by such providers.
Many providers already provide web-based access using conventional
federated authentication mechanisms; for example, to 'web-mail'
applications. The use of federated authentication enables
organisations that consume cloud services to more efficiently
orchestrate the delivery of these services to their users.
Frequently, however, users will prefer to use desktop applications
Smith, et al. Expires September 6, 2011 [Page 3]
Internet-Draft ABFAB Use Cases March 2011
that do not use Web protocols. For example, a desktop email client
may use a variety of non-Web protocols including SMTP, IMAP and POP.
Some cloud providers support access to their services using non-Web
protocols. However, the authentication mechanisms used by these
protocols will typically require that the provider has access to the
user's credentials. Consequently, the provider will require that
users' credentials are regularly synchronised from the user
organisation to the provider, which may have obvious implications for
security and privacy, or else be provisioned directly by the
provider.
The latter approach may be acceptable in the case where an
organisation has relationships with only a small number of providers,
but may become untenable if an organisation obtains services from
many providers. Consequently organisation with a requirement to use
non-Web protocols would prefer to make use of the credentials that
they have already provisioned their users with, and to utilise
federated authentication with non-Web protocols to obtain access to
Cloud providers.
4.2. High Performance Computing
High-performance computing (HPC) uses supercomputers and computer
clusters to solve complex computation problems most commonly
associated with scientific research or computational science.
Access to HPC resources is typicaly managed through the use of user
digital certificates. This requires HPC operators to issue
certificates to users using a registration process that often
duplicates identity management processes that already exist within
most user organisations. The HPC community would like to utilise
federated identity to perform both the user registration and
authentication functions required to use HPC resources, and so reduce
costs by avoiding this duplication of effort.
The HPC community also have following additional requirements:
o Improved Business Continuity: In the event of operational issues
at an HPC system at one organisation (for example, a power
failure), users and jobs could be transparently moved to other HPC
systems.
o Establish HPC-as-a-service: Many organisations who have invested
in HPC systems want to make their systems easily available to
external customers. Federated authentication facilitates this by
enabling these customers to use their existing identity
management, user credentialing and support processes.
Smith, et al. Expires September 6, 2011 [Page 4]
Internet-Draft ABFAB Use Cases March 2011
o Improve the user experience: Authentication to HPC systems is
normally performed using user digital certificates, which some
users find difficult to use. Federated authentication can provide
a better user experience by allowing the use of other types of
credentials, without requiring technical modifications to the HPC
system to support these.
4.3. Grid Infrastructure
Grids are large-scale distributed infrastructures, consisting of many
loosely coupled, independently managed, and geographically
distributed resources managed by organizationally independent
providers. Users of grids utilize these resources using grid
middleware that allows them to submit and control computing jobs,
manipulate datasets, communicate with other users, etc. These users
are organized into Virtual Organizations (VOs); each VO represents a
group of people working collaboratively on a common project. VOs
facilitate both the management of its users and the meditation of
agreements between its users and resource providers.
Authentication and authorisation within most grids is performed using
a Public Key Infrastructure, requiring each user to have an X.509
public-key certificate. Authentication is performed through
ownership of a particular certificate, while authorization decisions
are made based on the user's identity (derived from their X.509
certificate), membership of a particular VO, or additional
information assigned to a user by a VO. While efficient and
scalable, this approach has been found wanting in terms of usability
- many users find certificates difficult to manage, for various
reasons.
One approach to ameliorating this issue, adopted to some extent by
some grid communities already, is to abstract away direct access to
certificates from users, instead using alternative authentication
mechanisms and then converting the credential provided by these into
standard grid certificates. Some implementations of this idea use
existing federated authentication techniques. However, current
implementations of this approach suffer from a number of problems,
not the least of which is the inability to use the federated
credentials used to authenticate to a credential-conversion portal to
also directly authenticate to non-web resources such as secure shell
daemons.
The ability to use federated authentication directly, without the use
of a credential conversion service, would allow users to authenticate
to a grid and its associated services, allowing them to directly
launch and control computing jobs, all without having to manage, or
even see, an X.509 public-key certificate at any point in the
Smith, et al. Expires September 6, 2011 [Page 5]
Internet-Draft ABFAB Use Cases March 2011
process. Authorization within the grid would still be performed
using VO membership asserted issued by the user's identity provider
through the federated transport.
5. Acknowledgements
These use-cases have been developed and documented using significant
input from Jens Jensen (STFC Rutherford Appleton Laboratory), Daniel
Kouril (CESNET), Michal Prochazka (CESNET), Ian Stewart (University
of Edinburgh), Stephen Booth (Edinburgh Parallel Computing Centre),
Eefje van der Harst (SURFnet), Joost van Dijk (SURFnet), and Robin
Breathe (Oxford Brookes University).
6. Security Considerations
TODO
7. IANA Considerations
This document does not require actions by IANA.
8. References
8.1. Normative References
[OASIS.saml-profiles-2.0-os] Hughes, J., Cantor, S., Hodges, J.,
Hirsch, F., Mishra, P., Philpott, R.,
and E. Maler, "Profiles for the OASIS
Security Assertion Markup Language
(SAML) V2.0", OASIS
Standard OASIS.saml-profiles-2.0-os,
March 2005.
8.2. Informative References
Authors' Addresses
Dr. Rhys Smith
Cardiff University
39-41 Park Place
Cardiff CF10 3BB
United Kingdom
Phone: +44 29 2087 0126
EMail: smith@cardiff.ac.uk
Smith, et al. Expires September 6, 2011 [Page 6]
Internet-Draft ABFAB Use Cases March 2011
Mark Tysom
JANET(UK)
Lumen House, Library Avenue, Harwell
Didcot
United Kingdom
Phone: +44 1235 822223
EMail: mark.tysom@ja.net
Simon Cooper
JANET(UK)
Lumen House, Library Avenue, Harwell
Didcot
United Kingdom
Phone: +44 1235 822217
EMail: simon.cooper@ja.net
Smith, et al. Expires September 6, 2011 [Page 7]
