RFC 7832

Application Bridging for Federated Access Beyond Web (ABFAB) Use Cases

📅 published May 2016, from ietf

Application Bridging for Federated Access Beyond Web (ABFAB) Use Cases ✨

okay bestie, this is RFC 7832 🦋 it's an Informational doc (so it's just sharing info, not a formal standard 💅), written by R. Smith, Ed. from Jisc 🎀, dated May 2016. It's published in the IETF stream with ISSN 2070-1721 🌸. It doesn't list any RFCs it obsoletes or updates, so it's a standalone vibe 🧚

Abstract ✨

Okay so right now, federated identity is mostly a web thing 💻 but people are lowkey wanting it everywhere else, like in non-web contexts 👀 This memo is basically a highlight reel 🎞️ of a bunch of those non-web situations where the user experience could get a big glow-up if we used tech built on the Application Bridging for Federated Access Beyond web (ABFAB) architecture and specs 💖

Status of This Memo

Real talk: this document is not an Internet Standards Track spec 🙅‍♀️ It's just published for info purposes 📚

It's a product of the Internet Engineering Task Force (IETF) 🌈 and it reflects the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 👑 Not every IESG-approved doc is eligible for any level of Internet Standard, so check Section 2 of RFC 5741 for the deets 🫶

For the latest status, errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7832 🔗

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved 💜

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date ✨ Please actually read these, bestie, because they explain your rights and restrictions for this document 📜 Any Code Components pulled out of this doc have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License says 🍓

Table of Contents

   1. Introduction ....................................................2
   2. Context of Use Cases ............................................3
   3. Use Cases .......................................................3
      3.1. Cloud Services .............................................3
           3.1.1. Cloud-Based Application Services ....................4
           3.1.2. Cloud-Based Infrastructure Services .................5
      3.2. High-Performance Computing .................................6
      3.3. Grid Infrastructure ........................................6
      3.4. Databases and Directories ..................................7
      3.5. Media Streaming ............................................8
      3.6. Printing ...................................................9
      3.7. Accessing Applications from Devices on a Telecoms
           Infrastructure .............................................9
      3.8. Enhanced Security Services for S/MIME .....................10
      3.9. Smart Objects .............................................11
   4. Security Considerations ........................................11
   5. References .....................................................12
      5.1. Normative References ......................................12
      5.2. Informative References ....................................12
   Acknowledgments ...................................................13
   Contributors ......................................................13
   Author's Address ..................................................13

1. Introduction ✨

Federated identity is all about sharing info about people (a.k.a. "principals") in a controlled way, and it usually works across organization lines 🤝 The big win is that principals who show up in multiple domains don't have to keep re-registering 🙌 That cuts admin overhead for the orgs and makes systems way more usable for the principal 💅 It can also help with privacy worries, plus the regulatory and statutory rules some jurisdictions have 🔐

The info passed between orgs can include authentication state and identity details, which can be used for all kinds of stuff, including access management decisions 🧠 There are already mechanisms for sending this info in web scenarios (like the Security Assertion Markup Language (SAML) [OASIS.saml-profiles-2.0-os]), but people are super into applying federated identity to non-web use cases too 🎀 So this doc lists some of those use cases and describes how tech based on the ABFAB architecture [RFC7831] and specs could be used for them 🦋

2. Context of Use Cases 🌸

These use cases came out of work led by Jisc, the operator of the United Kingdom's education and research network 🇬🇧 They were built in response to requirements from its community, and the IETF community added more inputs too 🫶

The ABFAB architecture and specs make it possible to do authentication and authorization across organizational boundaries ✨ For lots of apps, principals don't need pre-made accounts that their federated identity maps to before their first visit, because the app can set things up on the fly 🧚 When an app does need those accounts, the pre-provisioning process is out of scope, and ABFAB assumes those requirements are already handled 💅 A standards-based effort that could help with pre-provisioning accounts is the stuff produced by the IETF SCIM working group 🌈

3. Use Cases 💖

This section covers a bunch of potential use cases where ABFAB-based tech could make the user experience better 🌟 Each one has a quick description of how current tech tries to solve it, and how ABFAB implementations could level it up 🦋

3.1. Cloud Services ☁️

Cloud computing is blowing up as a go-to way to get infrastructure services on demand 🚀 These services usually come in one of three models:

  • General infrastructure services like computing power, networks, storage, and utilities ("Infrastructure as a Service", or IaaS) 🖥️
  • Software stacks or platforms like database servers, web servers, and application runtime environments ("Platform as a Service", or PaaS) 🧩
  • Common application software like email, shared storage, business apps such as Customer Relationship Management (CRM), or scientific applications ("Software as a Service", or SaaS) 📬

Usually the cloud infrastructure and apps need to plug into the org's existing infrastructure 🔌 It's honestly so desirable if business or scientific workflows can run across infrastructure, both in the cloud and locally, as seamlessly as possible 💫

There are two main places where federated access fits into cloud computing 👑

  • Using federation to help mediate access to cloud-based application services (like cloud-provided email or CRM systems) 💌
  • Using federation to help mediate access to the management of cloud-based infrastructure services 🛠️

3.1.1. Cloud-Based Application Services 📧

Lots of orgs want to deliver services to their users through providers based in the "cloud" ☁️ The main motivation is avoiding having to manage and run commodity services themselves, because economies of scale and stuff mean providers can often deliver them more efficiently 💅

Plenty of providers already offer web-based access using conventional federated authentication mechanisms 🌐 For example, outsourced email where federated access works through "webmail" apps that are mediated with SAML [OASIS.saml-profiles-2.0-os] 💖 This setup helps orgs that consume cloud services orchestrate delivery to their users more efficiently, and it also gives those users single sign-on to the services ✨

Honestly though, users often prefer desktop apps that don't use web (i.e., HTTP-based) protocols 🖥️ A desktop email client, for instance, might use a mix of non-web protocols, including SMTP [RFC5321], IMAP [RFC3501], and the Post Office Protocol (POP) [RFC1939] 📨 Some cloud providers do support access to their services over non-web protocols, but those protocols' auth mechanisms usually need the provider to have the user's credentials, meaning it's non-federated 😬 So the provider ends up needing users' credentials regularly synchronized from the user's org, which adds obvious overhead for the org and obvious security and privacy implications 🙈 The other option is for the provider to provision accounts directly to the user 🫠

Directly provisioning accounts might be fine if an org only works with a small number of providers 🌸 But it can get totally untenable if an org gets services from lots of providers 💀 So any org that needs non-web protocols would rather use the credentials it has already given its users, and use federated authentication with those non-web protocols to reach cloud-based providers 🔑

ABFAB could really help here 🦋 Its specs would enable federated authentication for a variety of non-web protocols, so orgs get all the perks of federated authentication without the drawbacks people are dealing with right now 👑✨

3.1.2. Cloud-Based Infrastructure Services ☁️

okay so IaaS or PaaS cloud use cases are all about provisioning on-demand cloud-based infrastructure services 💅 that can include stuff like computing and storage resources, network infrastructure, and other utilities. The vibe is that cloud-based virtualized applications should ideally behave just like regular non-virtualized applications ✨, while you still get to manage the virtual computing resources (scaling, migration, reconfiguration) without changing the management applications. Iconic, right? 🦋

ngl moving apps or platforms to the cloud often means redesigning or refactoring them so they can be deployed and configured dynamically 🌸, and that includes their security services and their authentication and authorization services too. Today these are typically set up by hand 🙈, with trusted certificates and trust anchors, authorities and trusted services (both their location and certificates), attribute namespaces, and policies all manually configured. It's a lot, bestie 😭.

ABFAB could help here 🫶 by moving things away from manually configured authentication and authorization toward a system that's much easier to manage, one built on federated trust and identity. It's applicable to a wide range of existing features too. For example, you could connect to a newly provisioned Virtual Machine through ABFAB-enabled Secure Shell (SSH) [RFC4251] instead of manually managing an administrative login to that machine. Main character energy for sure 👑.

3.2. High-Performance Computing 🔥

High-Performance Computing (HPC) is a discipline that uses supercomputers and computer clusters to solve complex computation problems 🧠. It's most commonly associated with scientific research or computational science.

Access to HPC resources is often mediated through technologies like SSH, and it's typically managed with user digital certificates [RFC5280] or with manually provisioned credentials and accounts. So HPC operators have to issue certificates or accounts to users through a registration process that often duplicates identity management processes the user organizations already have 😩. The HPC community would love to use federated identity for both the user registration and the authentication functions needed to use HPC resources 💜. That would reduce costs by avoiding all this duplicated effort.

The HPC community also has the following additional requirements:

  • Improve business continuity: If an HPC system at one organization runs into operational issues (for example, a power failure), users and jobs could be transparently moved to other HPC systems without the overhead of managing user credentials for multiple organizations 🌈.
  • Establish "HPC as a service": Lots of organizations have invested in HPC systems and want to make them easily available to external customers 🍓. Federated authentication helps with this by letting those customers use their existing identity management, user credentialing, and support processes.
  • Improve the user experience: Authenticating to HPC systems usually means using user digital certificates, and some users find those really hard to use 😵‍💫. Federated authentication can give a better experience by allowing other types of credentials, without requiring technical modifications to the HPC system to support them.

ABFAB could help in this context, since it could enable federated authentication for many of the protocols and technologies that HPC providers use today, such as SSH 🎀.

3.3. Grid Infrastructure 🌐

Grids are large-scale distributed infrastructures made up of many loosely coupled, independently managed, and geographically distributed resources. Those resources are managed by organizationally independent providers 🧩. Users of grids use these resources through grid middleware, which lets them submit and control computing jobs, manipulate datasets, communicate with other users, and more. These users are organized into Virtual Organizations (VOs), and each VO represents a group of people working together on a common project 🤝. VOs handle the management of their users and the mediating of agreements between those users and resource providers.

Authentication and authorization within most grids are done with a Public Key Infrastructure, which means every user needs an X.509 public-key certificate [RFC5280] 🔐. Authentication happens through ownership of a particular certificate. Authorization decisions are based on the user's identity (derived from their X.509 certificate), their membership in a particular VO, or additional information a VO has assigned to them. It's efficient and scalable, but usability has been a real problem 😩 since many users find certificates difficult to manage, for various reasons.

Some grid communities already address this to some extent by abstracting away direct access to certificates 🙈. Instead, users authenticate with alternative mechanisms, and those credentials get converted into standard grid certificates. Some implementations of this idea use existing federated authentication techniques. However, these current implementations have a number of problems 💀, and the biggest one is that the federated credentials used to authenticate to a credential-conversion portal can't also be used to directly authenticate to non-web resources such as SSH daemons.

With ABFAB, users could use federated authentication directly, without a credential-conversion service ✨. That would let them authenticate to a grid and its associated services, and then directly launch and control computing jobs, all without having to manage, or even see, an X.509 public-key certificate at any point 🦋. Authorization within the grid would still be based on VO membership, as asserted by the user's Identity Provider (IdP) through the federated transport 💜.

3.4. Databases and Directories 🗂️

Databases (e.g., MySQL, PostgreSQL, Oracle) and directory technologies (e.g., OpenLDAP (http://www.openldap.org/), Microsoft Active Directory, Novell eDirectory) are super common across many organizations and get used for all kinds of things 📚. That can include core administrative functions, like hosting identity information for users, as well as business functions (e.g., student records systems at educational organizations).

Access to these database and directory systems is usually only for internal users 🔒. Still, external users sometimes need direct access. Examples include external examiners at educational organizations who need to reach student records systems, members of cross-organizational project teams who store information in a particular organization's systems, and external auditors 🧐.

Credentials for users, whether internal or external to the organization, that grant access to these databases and directories are usually provisioned manually. That can happen through identity management technologies or through more manual processes 🙃. For internal users this is fine, honestly, since this is one of the mainstays of identity management. For external users who need access, though, it's more of a headache for organizational processes. The organization has to either (1) add these external users to its internal identity management systems or (2) provision these credentials directly within the database/directory systems and keep managing them, including the appropriate access controls associated with each credential, for the lifetime of that credential 😮‍💨.

Federated authentication to databases or directories, via ABFAB technologies, would make this a lot better 🎉. It would remove the need to provision and de-provision credentials to access these systems. Organizations may still want to manually manage access control for federated identities. Even that could be handled through federated means, though, if the trust relationship between organizations is strong enough for the organization providing the service to rely on it for this purpose 🫶.

3.5. Media Streaming 🎶

Media streaming services (audio or audio/video) are often provided publicly to anonymous users 📻. Authentication still matters for a protected subset of streams, though, where rights management and access control must be applied 🔑.

Streams can be delivered over protocols that already include authentication, such as the Real Time Streaming Protocol (RTSP) [RFC2326] or RTP [RFC3550]. Streams can also be published in an encrypted form, with keys only distributed to trusted users. Federated authentication applies to both of these cases 💖.

There are alternative ways to manage access. For example, you can mint a unique stream URI for each user 🎬. But this relies on keeping the stream URI secret, and it also requires a communication channel between the web page used for authentication and the streaming service itself. Federated authentication is a better fit for this kind of access control 🙌. So ABFAB technologies that allow federated authentication directly within (inherently non-web) media streaming protocols would be a real enhancement in this area 🌸.

3.6. Printing 🖨️

When a visitor from one organization goes to the premises of another, they often need to use print services 🧳. Their home organization may offer printing too, but the output could be a long way away, which makes the home service not useful. The visitor will typically want to print from within a desktop or mobile application 📱.

Where this is offered right now, it's usually done with "open" printers (i.e., printers that allow anonymous print requests), and printer availability is advertised using Bonjour or other similar protocols 📡. If the organization requires authenticated print requests (usually for accounting purposes), the visitor usually has to be given credentials that allow this. Those are often supplemented with pay-as-you-go style payment systems 💳.

Adding federated authentication to the Internet Printing Protocol (IPP) [RFC2911] (and other relevant protocols) would enable remote printing like this without the administrative overhead of credentialing these visitors, who, of course, may well be one-time visitors to the organization 🧚. This would be immediately applicable to higher education, where this use case is becoming more and more important thanks to the success of federated network authentication systems such as eduroam (https://www.eduroam.org) 🎓. It could also be used in other contexts, like commercial print kiosks or large heterogeneous organizations 🏢.

3.7. Accessing Applications from Devices on a Telecoms Infrastructure 📱

okay so telecom operators have a few things going for them, bestie 🫶

  • They have a huge pile of registered users, and a lot of those people have identities verified to a pretty high level of assurance (usually because payment is involved) 💸. Not everyone is like that though. Non-contract customers on mobile networks in countries with weak identity registration rules are a different story 👀.
  • They already have network infrastructure that can authenticate a device (like a cellphone or an Asymmetric Digital Subscriber Line (ADSL) router) and, by extension, its owner 🔐.
  • Their users want to reach a ton of applications from their devices, both web-based and non-web-based ✨. The operator might host some of these itself, or they could be any application or system on the internet, like network messaging services, VoIP, or email 📧.

Right now, logging in to these apps is usually a manual mess. The user has to type in their credentials on the device (or on another device connected to it) for each app, one by one. Those credentials are usually pre-provisioned out of band 😩.

ABFAB technologies could fix this with something called "federated cross-layer access" (see [FCLA]) 🦋. The vibe is that the user's device already did a mutual authentication with the network, so later authentication and authorization to applications can happen seamlessly for the user. It's giving effortless 💅✨.

3.8. Enhanced Security Services for S/MIME 🔒

lots of orgs need to lock down their info with serious access control 🙅‍♀️. Maybe it's for protecting intellectual property, enforcing confidentiality agreements, or because the law says so ⚖️.

The Enhanced Security Services (ESS) for S/MIME defines an access control mechanism that the recipient's client enforces after the message is decrypted (see [MSG-AC-REQ]) 🗝️. The data model has three main roles:

  • Policy Decision Points (PDPs) make the policy decisions 🧠.
  • Policy Enforcement Points (PEPs) send decision requests to the PDP 📨.
  • Policy Information Points (PIPs) issue attributes about subjects 🏷️.

The decisions are based on the policies and the subject attributes. Simple, but powerful 🌸.

ABFAB would handle both the front-end and back-end attribute exchange needed to provide subject attributes ✨. When the PEP reaches out to the PDP, it starts an ABFAB authentication so it can authenticate to the PDP and let the PDP fetch those attributes 🙌. Once that's done, the PDP sends a token back to the subject PEP. The PEP can reuse that token for later authentications to the PDP 🎟️. Iconic 👑.

3.9. Smart Objects 🏠

lowkey, a ton of smart device setups involve multiple orgs that don't share security infrastructure at all 🙈. Take smart power: appliances and infrastructure like electric car chargers want to connect to an energy management system 🔌. In some setups, a utility company runs that system. The utility might only want to grant access to authorized devices, so a consortium of utilities and device makers could certify which devices are allowed to connect to power networks 🏅.

Consumer devices are also starting to talk to cloud services ☁️. A camera could be tied to a photo-processing site 📸. Uploading pictures or ordering prints needs authentication and authorization 🖨️. Sensors might send data to services run by someone other than the sensor manufacturer 🌡️. Auth gets really tricky when a sensor has no user interface at all 💀. Cellular devices may also want to reach third-party services whether they're on the cellular network or on Wi-Fi 📶. It gets messy when the cellular provider is the one coordinating authorization and billing 💸.

Here's where ABFAB shines 💖. It would provide authentication between one entity, like a smart device, and its IdP. Only two parties are in that exchange, so the smart device doesn't need to deal with a complicated public-key infrastructure, even when it's authenticating against many cloud services 🧚. The device can hand off the job of authenticating the service, and even deciding whether the device is allowed to access it, to the IdP 🤝. The perks are huge:

  • A wide range of revenue-sharing models become possible 💰.
  • Because the device only authenticates with a single IdP, phishing of device credentials can be avoided 🛡️.
  • The IdP makes the authorization calls and decides what personal information gets released 🕵️‍♀️.
  • The device owner can use a rich interface, like a website, to set up authorization and privacy policy, even if the device itself has no user interface 🖥️.
  • This model works well with pre-provisioning of device credentials 📦.

4. Security Considerations 🔐😭

This document is only use cases. It doesn't define any protocol operations for ABFAB 📚. The security considerations for the ABFAB architecture live in [RFC7831] 🏛️. The security considerations for the ABFAB technologies and protocols mentioned in these use cases are in their own protocol specifications, so go check those too 🫡. Don't skip them, bestie, this stuff matters a LOT 🚨.

5. References 📚

5.1. Normative References

[RFC7831]  Howlett, J., Hartman, S., Tschofenig, H., and J. Schaad,
           "Application Bridging for Federated Access Beyond Web
           (ABFAB) Architecture", RFC 7831, DOI 10.17487/RFC7831,
           May 2016, <http://www.rfc-editor.org/info/rfc7831>.

5.2. Informative References

[FCLA]     Wei, Y., Ed., "Federated Cross-Layer Access", Work in
           Progress, draft-wei-abfab-fcla-02, March 2012.

[MSG-AC-REQ]
           Freeman, T., Schaad, J., and P. Patterson, "Requirements
           for Message Access Control", Work in Progress,
           draft-freeman-plasma-requirements-11, March 2015.

[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,
           <http://docs.oasis-open.org/security/saml/v2.0/
           saml-profiles-2.0-os.pdf>.

[RFC1939]  Myers, J. and M. Rose, "Post Office Protocol - Version 3",
           STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996,
           <http://www.rfc-editor.org/info/rfc1939>.

[RFC2326]  Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
           Streaming Protocol (RTSP)", RFC 2326,
           DOI 10.17487/RFC2326, April 1998,
           <http://www.rfc-editor.org/info/rfc2326>.

[RFC2911]  Hastings, T., Ed., Herriot, R., deBry, R., Isaacson, S.,
           and P. Powell, "Internet Printing Protocol/1.1: Model and
           Semantics", RFC 2911, DOI 10.17487/RFC2911,
           September 2000, <http://www.rfc-editor.org/info/rfc2911>.

[RFC3501]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
           VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501,
           March 2003, <http://www.rfc-editor.org/info/rfc3501>.

[RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
           Jacobson, "RTP: A Transport Protocol for Real-Time
           Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
           July 2003, <http://www.rfc-editor.org/info/rfc3550>.

[RFC4251]  Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
           Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251,
           January 2006, <http://www.rfc-editor.org/info/rfc4251>.

[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, DOI 10.17487/RFC5280, May 2008,
           <http://www.rfc-editor.org/info/rfc5280>.

[RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
           DOI 10.17487/RFC5321, October 2008,
           <http://www.rfc-editor.org/info/rfc5321>.

Acknowledgments 🫶

These use cases were developed and documented with a ton of 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), Robin Breathe (Oxford Brookes University), Yinxing Wei (ZTE Corporation), Trevor Freeman (Microsoft Corporation), Sam Hartman (Painless Security, LLC), and Yuri Demchenko (University of Amsterdam) 💜. Thank you all, you're literally the best 🌈.

Contributors 🎀

The following individuals made important contributions to the text of this document: Tim Bannister (Manchester University), Simon Cooper (Jisc), Josh Howlett (Jisc), and Mark Tysom (Jisc) ⭐.

Author's Address 📮

Dr. Rhys Smith (editor)
Jisc
Lumen House, Library Avenue, Harwell
Oxford  OX11 0SG
United Kingdom

Phone: +44 1235 822145
Email: rhys.smith@jisc.ac.uk
📦 where this page comes from