One document matched: draft-ietf-abfab-usecases-01.txt
Differences from draft-ietf-abfab-usecases-00.txt
ABFAB R. Smith, Ed.
Internet-Draft Cardiff University
Intended status: Informational July 5, 2011
Expires: January 6, 2012
Application Bridging for Federated Access Beyond web (ABFAB) Use Cases
draft-ietf-abfab-usecases-01
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 document the wide variety of contexts where the user
experience could be improved through the use of technologies based on
the ABFAB architecture and specifications.
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 January 6, 2012.
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 Expires January 6, 2012 [Page 1]
Internet-Draft ABFAB Use Cases July 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 . . . . . . . . . . . . . . . . . . . . . . 4
4.2. High Performance Computing . . . . . . . . . . . . . . . . 5
4.3. Grid Infrastructure . . . . . . . . . . . . . . . . . . . 5
4.4. Databases and Directories . . . . . . . . . . . . . . . . 6
4.5. Media Streaming . . . . . . . . . . . . . . . . . . . . . 7
4.6. Printing . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.7. KNP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.8. PLASMA . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.9. SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 10
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 11
Smith Expires January 6, 2012 [Page 2]
Internet-Draft ABFAB Use Cases July 2011
1. Introduction
Federated identity facilitates the controlled sharing of information
about people (a.k.a. principals), commonly across organisational
boundaries. This avoids redundant registration of principals who
operate in and across multiple domains which both reduces
administrative overheads for the organisations and improves usability
for the principal. Simultaneously, it can also help address privacy-
related concerns, along with regulatory and statutory requirements of
some jurisdictions.
The information that is passed between organisations may include
authentication state and identity information that can be used for
many purposes, including making access management decisions. A
number of mechanisms support the transmission of this information for
Web-based scenarios (for example [OASIS.saml-profiles-2.0-os]), but
there is significant interest in the application of federated
identity in non-Web use cases. This document enumerates some of
these use-cases, describing how technologies based on the the ABFAB
architecture [I-D.lear-abfab-arch] and specifications could be used.
2. Terminology
TODO:
o Cloud:
o Federated Identity:
o Principal
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
This section describes a variety of use cases where technologies
based on the ABFAB architecture and specifications could help improve
the user experience; each includes a brief description of how current
technologies attempt to solve the use cases and how this could
Smith Expires January 6, 2012 [Page 3]
Internet-Draft ABFAB Use Cases July 2011
improved upon.
4.1. Cloud Services
Many organisations are seeking to deliver services to their users
through the use of providers based in the 'cloud'. 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, outsourced email
provision where federated access is enabled using 'web-mail'
applications where access is mediated through the use of SAML
[OASIS.saml-profiles-2.0-os]. This 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
that do not use web (i.e. HTTP [RFC2616] based) protocols. For
example, a desktop email client may use a variety of non-web
protocols including SMTP [RFC2821], IMAP [RFC2060] and POP [RFC1939].
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 - i.e. non federated. Consequently, the provider
will require that users' credentials are regularly synchronised from
the user organisation to the provider, with the obvious overhead this
imparts on the organisation along with the obvious implications for
security and privacy; or else be provisioned directly by the provider
to the user.
The latter approach of directly provisioning accounts 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 any
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-based providers.
ABFAB could help in this context as its specifications would enable
federated authentication for a variety of non-web protocols, thus
gaining the benefits of federated authentication without any of the
drawbacks that are currently experienced.
Smith Expires January 6, 2012 [Page 4]
Internet-Draft ABFAB Use Cases July 2011
4.2. High Performance Computing
High-performance computing (HPC) is a discipline that uses
supercomputers and computer clusters to solve complex computation
problems; it most commonly associated with scientific research or
computational science.
Access to HPC resources, often mediated through technologies such as
secure shell [RFC4251], is typically managed through the use of user
digital certificates [RFC5280]. 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 without the overhead of having to manage user credentials
for multiple organisations;
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;
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.
ABFAB could help in this context as it could enable federated
authentication for the many of the protocols and technologies
currently in use by HPC providers, such as secure shell.
4.3. Grid Infrastructure
Grids are large-scale distributed infrastructures, consisting of many
loosely coupled, independently managed, and geographically
distributed resources managed by organisationally independent
providers. Users of grids utilise these resources using grid
Smith Expires January 6, 2012 [Page 5]
Internet-Draft ABFAB Use Cases July 2011
middleware that allows them to submit and control computing jobs,
manipulate datasets, communicate with other users, etc. These users
are organised into Virtual Organisations (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 [RFC5280]. Authentication is performed
through ownership of a particular certificate, while authorisation
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 through ABFAB,
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 process. Authorisation within the grid would still be performed
using VO membership asserted issued by the user's identity provider
through the federated transport.
4.4. Databases and Directories
Databases (e.g. MySQL, PostgreSQL, Oracle, etc.) and directory
technologies (e.g. OpenLDAP, Microsoft Active Directory, Novell
eDirectory, etc.) are very commonly used within many organsiations
for a variety of purposes. This can include core administrative
functions, such as hosting identity information for its users, as
well as business functions (e.g. student records systems at
educational organisations).
Smith Expires January 6, 2012 [Page 6]
Internet-Draft ABFAB Use Cases July 2011
Access to such database and directory systems is usually provided for
internal users only, however, users external to the organisations
sometimes require access to these systems directly: for example,
external examiners in educational organisations requiring access to
student records systems, members of cross-organisational project
teams who store information in a particular organisation's systems,
external auditors, etc.
Credentials for users both internal or external to the organisation
that allow access these databases and directories are usually
provisioned manually within an organisation, either using Identity
Management technologies or through more manual processes. For the
internal users, this situation is fine - this is one of the mainstays
of Identity Management. However, for external users who require
access, this represents more of a problem for organisational
processes. The organisation either has to add these external users
to its internal Identity Management systems, or else provision these
credentials directly within the database/directory systems and
continue to manage them, including appropriate access controls
associated with each credential, for the lifetime of that credential.
Federated authentication to databases or directories, via ABFAB
technologies, would improve upon this situation as it would remove
the need to provision and deprovision credentials to access these
systems. Organisations may still wish to manually manage access
control of federated identities; however, even this could be provided
through federated means, if the trust relationship between
organisations was strong enough for the organisation providing the
service to rely upon it for this purpose.
4.5. Media Streaming
Media streaming services (audio or audio/video) are often provided
publicly to anonymous users, but authentication is important for a
protected subset of streams where rights management and access
control must be applied.
Streams can be delivered via protocols such as RTSP [RFC3226] / RTP
[RFC3550] which already include authentication, or can be published
in an encrypted form with keys only being distributed to trusted
users. Federated authentication is applicable to both of these
cases.
Alternative mechanisms to managing access exist; for example, an
approach where a unique stream URI is minted for each user. However,
this relies on preserving the secrecy of the stream URI, and also
requires a communication channel between the web page used for
authentication and the streaming service itself. Federated
Smith Expires January 6, 2012 [Page 7]
Internet-Draft ABFAB Use Cases July 2011
authentication would be a better fit for this kind of access control.
Thus, AFAB technologies that allow federated authentication directly
within (inherently non-web) media streaming protocols would represent
an enhancement to this area.
4.6. Printing
A visitor from one organisation to the premises of another often
requires the use of print services. Their home organisation may of
course offer printing, but the output could be a long way away so the
home service is not useful. The user will typically want to print
from within a desktop or mobile application.
Where this service is currently offered it would usually be achieved
through the use of 'open' printers (i.e. printers that allow
anonymous print requests), where printer availability is advertised
through the use of Bonjour or other similar protocols. If the
organisation requires authenticated print requests (usually for
accounting purposes), the the visitor would usually have to be given
credentials that allow this, often supplemented with pay-as-you-go
style payment systems.
Adding federated authentication to IPP [RFC3229] (and other relevant
protocols) would enable this kind of remote printing service without
the administrative overhead of credentialing these visitors (who, of
course, may well one time visitors to the organisation). This would
be immediately applicable to higher education, where this use case is
increasingly important thanks to the success of federated network
authentication systems such as eduroam but could also be used in
other contexts such as commercial print kiosks, or in large,
heterogeneous organisations.
4.7. KNP
TODO
4.8. PLASMA
TODO:
4.9. SIP
TODO
5. Contributors
The following individuals made important contributions to the text of
this document: Tim Bannister (Manchester University), Simon Cooper
Smith Expires January 6, 2012 [Page 8]
Internet-Draft ABFAB Use Cases July 2011
(JANET(UK)), Josh Howlett (JANET(UK)), and Mark Tysom (JANET(UK)).
6. Acknowledgements
These use-cases have been deve3loped 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).
7. Security Considerations
TODO
8. IANA Considerations
This document does not require actions by IANA.
9. References
9.1. Normative References
[RFC1939] Myers, J. and M. Rose, "Post Office
Protocol - Version 3", STD 53,
RFC 1939, May 1996.
[RFC2060] Crispin, M., "Internet Message Access
Protocol - Version 4rev1", RFC 2060,
December 1996.
[RFC2616] Fielding, R., Gettys, J., Mogul, J.,
Frystyk, H., Masinter, L., Leach, P.,
and T. Berners-Lee, "Hypertext Transfer
Protocol -- HTTP/1.1", RFC 2616,
June 1999.
[RFC2821] Klensin, J., "Simple Mail Transfer
Protocol", RFC 2821, April 2001.
[RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6
aware server/resolver message size
requirements", RFC 3226, December 2001.
[RFC3229] Mogul, J., Krishnamurthy, B., Douglis,
F., Feldmann, A., Goland, Y., van Hoff,
A., and D. Hellerstein, "Delta encoding
in HTTP", RFC 3229, January 2002.
Smith Expires January 6, 2012 [Page 9]
Internet-Draft ABFAB Use Cases July 2011
[RFC3550] Schulzrinne, H., Casner, S., Frederick,
R., and V. Jacobson, "RTP: A Transport
Protocol for Real-Time Applications",
STD 64, RFC 3550, July 2003.
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure
Shell (SSH) Protocol Architecture",
RFC 4251, January 2006.
[RFC5280] Cooper, D., Santesson, S., Farrell, S.,
Boeyen, S., Housley, R., and W. Polk,
"Internet X.509 Public Key
Infrastructure Certificate and
Certificate Revocation List (CRL)
Profile", RFC 5280, May 2008.
[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.
[I-D.lear-abfab-arch] Howlett, J., Hartman, S., Tschofenig,
H., and E. Lear, "Application Bridging
for Federated Access Beyond Web (ABFAB)
Architecture", draft-lear-abfab-arch-02
(work in progress), March 2011.
9.2. Informative References
Appendix A. Change Log
Note to RFC Editor: if this document does not obsolete an existing
RFC, please remove this appendix before publication as an RFC.
Draft -00 to draft -01
1. Added Databases and Directories use case.
2. Added Media Streaming use case.
3. Added printing use case.
4. Added remote working use case.
Smith Expires January 6, 2012 [Page 10]
Internet-Draft ABFAB Use Cases July 2011
5. Minor changes in wording through the draft.
6. Added references to the various protocols mentioned.
Appendix B. Open Issues
Note to RFC Editor: please remove this appendix before publication as
an RFC.
Author's Address
Dr. Rhys Smith (editor)
Cardiff University
39-41 Park Place
Cardiff CF10 3BB
United Kingdom
Phone: +44 29 2087 0126
EMail: smith@cardiff.ac.uk
Smith Expires January 6, 2012 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-24 01:13:17 |