[要約] 要約：RFC 7832は、ABFAB（Application Bridging for Federated Access Beyond Web）の使用例に関する情報を提供するものであり、非Web環境でのアプリケーション間の連携に焦点を当てています。目的：このRFCの目的は、ABFABの使用例を示し、非Web環境でのアプリケーション間の連携における課題や解決策についての理解を促進することです。
Internet Engineering Task Force (IETF) R. Smith, Ed.
Request for Comments: 7832 Jisc
Category: Informational May 2016
ISSN: 2070-1721
Application Bridging for Federated Access Beyond Web (ABFAB) Use Cases
Webを超えたフェデレーションアクセスのアプリケーションブリッジング（ABFAB）の使用例
Abstract
概要
Federated identity is typically associated with web-based services at present, but there is growing interest in its application in non-web-based contexts. The goal of this memo is to document a selection of the wide variety of these contexts whose user experience could be improved through the use of technologies based on the Application Bridging for Federated Access Beyond web (ABFAB) architecture and specifications.
現在、フェデレーションIDは現在、Webベースのサービスに関連付けられていますが、Webベース以外のコンテキストでのアプリケーションへの関心が高まっています。このメモの目的は、Web上のアプリケーションブリッジング（ABFAB）アーキテクチャと仕様に基づくテクノロジーを使用することでユーザーエクスペリエンスを改善できる、これらのさまざまなコンテキストの選択を文書化することです。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7832.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7832で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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 described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
Federated identity facilitates the controlled sharing of information about people (a.k.a. "principals"), commonly across organizational boundaries. This avoids redundant registration of principals who operate in and across multiple domains, both reducing the administrative overhead for the organizations involved and improving the usability of systems for the principal. Simultaneously, it can also help address privacy-related concerns, along with the regulatory and statutory requirements of some jurisdictions.
フェデレーションIDは、一般に組織の境界を越えて、人（別名「プリンシパル」）に関する情報の制御された共有を容易にします。これにより、複数のドメインで動作するプリンシパルの重複登録が回避され、関係する組織の管理オーバーヘッドが削減され、プリンシパルのシステムの使いやすさが向上します。同時に、一部の法域の規制および法的要件とともに、プライバシー関連の懸念への対処にも役立ちます。
The information that is passed between organizations 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 in particular (e.g., the Security Assertion Markup Language (SAML) [OASIS.saml-profiles-2.0-os]), but there is significant interest in the more general application of federated identity to include non-web use cases. This document enumerates some of these use cases, describing how technologies based on the ABFAB architecture [RFC7831] and specifications could be used.
組織間で渡される情報には、アクセス管理の決定を行うなど、多くの目的に使用できる認証状態とID情報が含まれる場合があります。多くのメカニズムは、特にWebベースのシナリオ（たとえば、セキュリティアサーションマークアップ言語（SAML）[OASIS.saml-profiles-2.0-os]）のこの情報の送信をサポートしていますが、より一般的な非Webユースケースを含めるためのフェデレーションIDのアプリケーション。このドキュメントでは、これらの使用例のいくつかを列挙し、ABFABアーキテクチャ[RFC7831]に基づく技術と仕様をどのように使用できるかを説明します。
The use cases described in this document are a result of work led by Jisc, the operator of the United Kingdom's education and research network, responding to requirements from its community. These use cases have also been augmented by various inputs from the IETF community.
このドキュメントで説明する使用例は、英国の教育研究ネットワークの運営者であるJiscが率い、コミュニティの要件に対応した成果です。これらの使用例は、IETFコミュニティからのさまざまな情報によっても強化されています。
The ABFAB architecture and specifications enables authentication and authorization to occur across organizational boundaries. For many applications, principals need not have pre-instantiated accounts that their federated identity maps to before their first visit to that application; the application can perform this process on the fly. In cases where such accounts are required for particular applications, the pre-provisioning process is out of scope; the ABFAB technology assumes that any such requirements have already been fulfilled. Standards-based work of note that would assist with this pre-provisioning of accounts includes the standards and specifications produced by the IETF SCIM working group.
ABFABのアーキテクチャと仕様により、組織の境界を越えて認証と承認を行うことができます。多くのアプリケーションでは、プリンシパルは、そのアプリケーションに初めてアクセスする前に、フェデレーションIDがマッピングする事前にインスタンス化されたアカウントを持っている必要はありません。アプリケーションはこのプロセスをその場で実行できます。特定のアプリケーションにそのようなアカウントが必要な場合、事前プロビジョニングプロセスは範囲外です。 ABFABテクノロジーは、そのような要件がすでに満たされていることを前提としています。このアカウントの事前プロビジョニングを支援する標準ベースの注目すべき作業には、IETF SCIMワーキンググループによって作成された標準と仕様が含まれます。
This section describes some of the various potential 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 be improved upon by ABFAB implementations.
このセクションでは、ABFABアーキテクチャと仕様に基づくテクノロジーがユーザーエクスペリエンスの向上に役立つ可能性のあるさまざまな潜在的な使用例について説明します。それぞれには、現在のテクノロジーがユースケースを解決しようとする方法と、ABFAB実装によってこれをどのように改善できるかについての簡単な説明が含まれています。
Cloud computing is emerging as a common way of provisioning infrastructure services in an on-demand manner. These services are typically offered as one of three models:
クラウドコンピューティングは、インフラストラクチャサービスをオンデマンドでプロビジョニングする一般的な方法として浮上しています。これらのサービスは通常、次の3つのモデルのいずれかとして提供されます。
o General infrastructure services such as computing power, networks, storage, and utilities ("Infrastructure as a Service", or IaaS);
o コンピューティングパワー、ネットワーク、ストレージ、ユーティリティなどの一般的なインフラストラクチャサービス（「サービスとしてのインフラストラクチャ」、またはIaaS）。
o Software stacks or platforms such as database servers, web servers, and application runtime environments ("Platform as a Service", or PaaS);
o データベースサーバー、Webサーバー、アプリケーションランタイム環境（「サービスとしてのプラットフォーム」、またはPaaS）などのソフトウェアスタックまたはプラットフォーム。
o Common application software such as email, shared storage, business applications such as Customer Relationship Management (CRM), or scientific applications ("Software as a Service", or SaaS).
o 電子メール、共有ストレージなどの一般的なアプリケーションソフトウェア、カスタマーリレーションシップマネジメント（CRM）などのビジネスアプリケーション、または科学アプリケーション（「サービスとしてのソフトウェア」、またはSaaS）。
In many cases, the provisioned cloud infrastructures and applications need to be integrated with existing infrastructure of the organization, and it is of course desirable if this could be achieved in a way that allows business or scientific workflows to act across infrastructure -- both across the cloud and in the local infrastructure -- in as seamless a manner as possible.
多くの場合、プロビジョニングされたクラウドインフラストラクチャとアプリケーションは、組織の既存のインフラストラクチャと統合する必要があります。もちろん、インフラストラクチャ全体でビジネスワークフローまたは科学的ワークフローが機能できるようにしてこれを実現できることが望ましいです。クラウドとローカルインフラストラクチャ-可能な限りシームレスな方法で。
There are two main areas where federated access fits in cloud computing:
フェデレーションアクセスがクラウドコンピューティングに適合する主な領域は2つあります。
o Using federation to help mediate access to cloud-based application services (e.g., cloud-provided email or CRM systems);
o フェデレーションを使用して、クラウドベースのアプリケーションサービス（たとえば、クラウドで提供される電子メールやCRMシステム）へのアクセスを仲介するのに役立ちます。
o Using federation to help mediate access to the management of cloud-based infrastructure services.
o フェデレーションを使用して、クラウドベースのインフラストラクチャサービスの管理へのアクセスを仲介します。
Many organizations 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 that, 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 "webmail" applications where access is mediated through the use of SAML [OASIS.saml-profiles-2.0-os]. This use of federated authentication enables organizations that consume cloud services to more efficiently orchestrate the delivery of these services to their users and also enables single sign-on to the services for these users.
多くのプロバイダーは、従来のフェデレーション認証メカニズムを使用してWebベースのアクセスをすでに提供しています-たとえば、SAMLの使用を通じてアクセスが仲介される「ウェブメール」アプリケーションを使用してフェデレーションアクセスが有効になっているアウトソーシングされた電子メールプロビジョニング[OASIS.saml-profiles-2.0-os ]。このフェデレーテッド認証の使用により、クラウドサービスを利用する組織は、これらのサービスのユーザーへの配信をより効率的に調整でき、これらのユーザーのサービスへのシングルサインオンも可能になります。
Frequently, however, users will prefer to use desktop applications that do not use web (i.e., based on HTTP) protocols. For example, a desktop email client may use a variety of non-web protocols, including SMTP [RFC5321], IMAP [RFC3501], and the Post Office Protocol (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 synchronized from the user organization to the provider, with the obvious overhead this imparts on the organization along with the obvious implications for security and privacy, or else be provisioned directly by the provider to the user.
ただし、多くの場合、ユーザーはWeb（つまり、HTTPベース）プロトコルを使用しないデスクトップアプリケーションを使用することを好みます。たとえば、デスクトップメールクライアントは、SMTP [RFC5321]、IMAP [RFC3501]、Post Office Protocol（POP）[RFC1939]など、さまざまな非Webプロトコルを使用する場合があります。一部のクラウドプロバイダーは、非Webプロトコルを使用したサービスへのアクセスをサポートしています。ただし、これらのプロトコルで使用される認証メカニズムでは、通常、プロバイダーがユーザーの資格情報（非フェデレーション）にアクセスできる必要があります。したがって、プロバイダーは、ユーザーの資格情報をユーザー組織からプロバイダーに定期的に同期することを要求します。これにより、セキュリティとプライバシーへの明らかな影響とともに組織に与える明白なオーバーヘッド、またはプロバイダーからプロバイダーに直接プロビジョニングされます。ユーザー。
The latter approach of directly provisioning accounts may be acceptable in the case where an organization has relationships with only a small number of providers, but this approach may become untenable if an organization obtains services from many providers. Consequently, any organization 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 utilize federated authentication with non-web protocols to obtain access to cloud-based providers.
組織が少数のプロバイダーとのみ関係を持っている場合、アカウントを直接プロビジョニングする後者のアプローチは受け入れられますが、組織が多くのプロバイダーからサービスを取得する場合、このアプローチは受け入れられなくなる可能性があります。したがって、非Webプロトコルを使用する必要がある組織は、ユーザーがすでにプロビジョニングした資格情報を利用し、非Webプロトコルを使用したフェデレーション認証を利用してクラウドベースのプロバイダーへのアクセスを取得することを好みます。
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.
ABFABは、その仕様がさまざまな非Webプロトコルのフェデレーション認証を可能にするため、このコンテキストで役立つ可能性があり、現在経験している欠点のないフェデレーション認証の利点を獲得します。
Typical IaaS or PaaS cloud use cases deal with provisioning on-demand cloud-based infrastructure services that may include infrastructure components such as computing and storage resources, network infrastructure, and other utilities. Cloud-based virtualized applications should ideally operate in the same way as regular non-virtualized applications whilst allowing management of the virtual computing resources (scaling, migration, reconfiguration) without changing the management applications.
典型的なIaaSまたはPaaSクラウドの使用例は、コンピューティングリソースやストレージリソース、ネットワークインフラストラクチャ、その他のユーティリティなどのインフラストラクチャコンポーネントを含む、オンデマンドのクラウドベースのインフラストラクチャサービスのプロビジョニングを扱います。クラウドベースの仮想化アプリケーションは、通常の非仮想化アプリケーションと同じように動作するのが理想的ですが、管理アプリケーションを変更せずに仮想コンピューティングリソースの管理（スケーリング、移行、再構成）を行うことができます。
In many cases, moving applications or platforms to the cloud may require their redesigning/refactoring to support dynamic deployment and configuration, including their security services, and authentication and authorization services. These will typically today be extensively based on manual setup and configuration of such components and features as trusted certificates and trust anchors, authorities and trusted services (both their location and certificates), attribute namespaces, and policies.
多くの場合、アプリケーションまたはプラットフォームをクラウドに移動するには、セキュリティサービス、認証および承認サービスを含む動的な展開と構成をサポートするために、再設計/リファクタリングが必要になる場合があります。これらは今日、一般に、信頼できる証明書とトラストアンカー、機関と信頼できるサービス（場所と証明書の両方）、属性名前空間、ポリシーなどのコンポーネントと機能の手動セットアップと構成に広く基づいています。
ABFAB could help in this context as a way of moving from the model of manually configured authentication and authorization towards a more easily managed system involving federated trust and identity, and ABFAB will be applicable for a wide range of existing features (e.g., connecting to a newly provisioned Virtual Machine through ABFAB-enabled Secure Shell (SSH) [RFC4251] instead of having to manually manage an administrative login to that machine).
ABFABは、手動で構成された認証と承認のモデルから、フェデレーションの信頼とIDを含むより簡単に管理できるシステムに移行する方法として、このコンテキストで役立ちます。ABFABは、既存の幅広い機能（たとえば、 ABFAB対応のSecure Shell（SSH）[RFC4251]を介して新しくプロビジョニングされた仮想マシン（そのマシンへの管理ログインを手動で管理する必要はありません）。
High-Performance Computing (HPC) is a discipline that uses supercomputers and computer clusters to solve complex computation problems; it is most commonly associated with scientific research or computational science.
ハイパフォーマンスコンピューティング（HPC）は、スーパーコンピューターとコンピュータークラスターを使用して複雑な計算問題を解決する分野です。最も一般的には、科学研究または計算科学に関連しています。
Access to HPC resources, often mediated through technologies such as SSH, is typically managed through the use of user digital certificates [RFC5280] or through manually provisioned credentials and accounts. This requires HPC operators to issue certificates or accounts to users using a registration process that often duplicates identity management processes that already exist within most user organizations. The HPC community would like to utilize 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.
HPCリソースへのアクセスは、SSHなどのテクノロジを介して仲介されることが多く、通常、ユーザーデジタル証明書[RFC5280]を使用するか、手動でプロビジョニングされた資格情報とアカウントを使用して管理されます。これにより、HPCオペレーターは、ほとんどのユーザー組織内に既に存在するID管理プロセスを複製する登録プロセスを使用して、ユーザーに証明書またはアカウントを発行する必要があります。 HPCコミュニティは、フェデレーションIDを利用して、HPCリソースを使用するために必要なユーザー登録と認証機能の両方を実行し、この重複した作業を回避してコストを削減したいと考えています。
The HPC community also have the following additional requirements:
HPCコミュニティには、次の追加要件もあります。
o Improve business continuity: In the event of operational issues at an HPC system at one organization (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 organizations;
o ビジネス継続性の向上：1つの組織のHPCシステムで運用上の問題（停電など）が発生した場合、ユーザーとジョブを他のHPCシステムに透過的に移動でき、複数の組織のユーザー資格情報を管理する必要がありません。
o Establish "HPC as a service": Many organizations 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 「サービスとしてのHPC」の確立：HPCシステムに投資した多くの組織は、システムを外部の顧客が簡単に利用できるようにしたいと考えています。フェデレーション認証は、これらの顧客が既存のID管理、ユーザー資格情報、およびサポートプロセスを使用できるようにすることで、これを容易にします。
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.
o ユーザーエクスペリエンスの向上：HPCシステムへの認証は、通常、ユーザーデジタル証明書を使用して実行されます。フェデレーション認証では、他の種類の資格情報を使用できるようにすることで、HPCシステムに技術的な変更を加えなくてもこれらをサポートできるため、ユーザーエクスペリエンスが向上します。
ABFAB could help in this context, as it could enable federated authentication for many of the protocols and technologies currently in use by HPC providers, such as SSH.
ABFABは、SSHなどのHPCプロバイダーが現在使用している多くのプロトコルとテクノロジのフェデレーション認証を有効にすることができるため、この状況で役立ちます。
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 their users and the meditation of agreements between their users and resource providers.
グリッドは、大規模な分散インフラストラクチャであり、疎結合され、独立して管理され、地理的に分散されたリソースで構成され、組織的に独立したプロバイダーによって管理されます。グリッドのユーザーは、グリッドミドルウェアを使用してこれらのリソースを利用し、コンピューティングジョブの送信と制御、データセットの操作、他のユーザーとの通信などを行うことができます。これらのユーザーは仮想組織（VO）に編成されます。各VOは、共通のプロジェクトで共同で作業する人々のグループを表します。 VOは、ユーザーの管理と、ユーザーとリソースプロバイダーの間の合意の瞑想の両方を促進します。
Authentication and authorization within most grids are 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 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.
ほとんどのグリッド内の認証と承認は、公開鍵インフラストラクチャを使用して実行され、各ユーザーにX.509公開鍵証明書[RFC5280]が必要です。認証は特定の証明書の所有権を通じて実行されますが、承認の決定は、ユーザーのID（X.509証明書から派生）、特定のVOのメンバーシップ、またはVOによってユーザーに割り当てられた追加情報に基づいて行われます。このアプローチは効率的でスケーラブルですが、使いやすさの点で望まれていることがわかりました。多くのユーザーは、さまざまな理由で証明書の管理が難しいと感じています。
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 SSH daemons.
この問題を改善する1つのアプローチは、一部のグリッドコミュニティですでにある程度採用されていますが、代替の認証メカニズムを使用してユーザーからの証明書への直接アクセスを抽象化し、これらによって提供される資格情報を標準のグリッド証明書に変換することです。このアイデアの一部の実装では、既存のフェデレーション認証技術を使用しています。ただし、このアプローチの現在の実装にはいくつかの問題があります。少なくとも、SSHデーモンなどの非Webリソースに対して直接認証するために、認証情報変換ポータルへの認証に使用されるフェデレーション認証情報を使用できないことです。
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. Authorization within the grid would still be performed using VO membership as asserted by the user's Identity Provider (IdP) through the federated transport.
資格情報変換サービスを使用せずに、ABFABを介して直接統合認証を使用する機能により、ユーザーはグリッドとそれに関連するサービスに対して認証を行うことができ、管理や管理の必要なしに、コンピューティングジョブを直接起動および制御できます。プロセスの任意の時点でのX.509公開鍵証明書もご覧ください。グリッド内の承認は、フェデレーショントランスポートを介してユーザーのIDプロバイダー（IdP）によってアサートされるVOメンバーシップを使用して実行されます。
Databases (e.g., MySQL, PostgreSQL, Oracle) and directory technologies (e.g., OpenLDAP (http://www.openldap.org/), Microsoft Active Directory, Novell eDirectory) are very commonly used within many organizations for a variety of purposes. Such purposes 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 organizations).
データベース（MySQL、PostgreSQL、Oracleなど）およびディレクトリテクノロジー（OpenLDAP（http://www.openldap.org/)、Microsoft Active Directory、Novell eDirectoryなど）は、さまざまな目的で多くの組織で非常に一般的に使用されています。そのような目的には、ユーザーのID情報のホスティングなどのコア管理機能や、ビジネス機能（教育機関の学生記録システムなど）が含まれます。
Access to such database and directory systems is usually provided for internal users only; however, users external to the organizations sometimes require access to these systems directly -- for example, external examiners in educational organizations requiring access to student records systems, members of cross-organizational project teams who store information in a particular organization's systems, and external auditors.
このようなデータベースおよびディレクトリシステムへのアクセスは通常、内部ユーザーのみに提供されます。ただし、組織外部のユーザーは、これらのシステムに直接アクセスする必要がある場合があります。たとえば、学生の記録システムへのアクセスを必要とする教育組織の外部審査官、特定の組織のシステムに情報を保存する組織横断プロジェクトチームのメンバー、外部監査人など。
Credentials for users either internal or external to the organization that allow access to these databases and directories are usually provisioned manually within an organization, 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 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 continue to manage them, including appropriate access controls associated with each credential, for the lifetime of that credential.
これらのデータベースとディレクトリへのアクセスを許可する組織の内部または外部のユーザーの資格情報は、通常、ID管理技術を使用するか、より手動のプロセスを使用して、組織内で手動でプロビジョニングされます。内部ユーザーにとって、この状況は問題ありません。これは、ID管理の主力の1つです。ただし、アクセスを必要とする外部ユーザーの場合、これは組織プロセスの問題の多くを表します。組織は、（1）これらの外部ユーザーを内部ID管理システムに追加するか、（2）これらの資格情報をデータベース/ディレクトリシステム内で直接プロビジョニングし、有効期間中、各資格情報に関連付けられた適切なアクセス制御を含め、それらを引き続き管理する必要があります。その信任状の。
Federated authentication to databases or directories, via ABFAB technologies, would improve upon this situation, as it would remove the need to provision and de-provision credentials to access these systems. Organizations 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 organizations was strong enough for the organization providing the service to rely upon it for this purpose.
ABFABテクノロジを介したデータベースまたはディレクトリへのフェデレーション認証は、これらのシステムにアクセスするための資格情報をプロビジョニングおよびプロビジョニング解除する必要をなくすため、この状況を改善します。組織は依然として、フェデレーションIDのアクセス制御を手動で管理したい場合があります。ただし、組織間の信頼関係が、サービスを提供する組織がこの目的のためにサービスに依存するのに十分な強さである場合は、フェデレーション手段によって提供することもできます。
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 that already include authentication, such as the Real Time Streaming Protocol (RTSP) [RFC2326] or RTP [RFC3550], 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.
ストリームは、リアルタイムストリーミングプロトコル（RTSP）[RFC2326]またはRTP [RFC3550]などの認証がすでに含まれているプロトコルを介して配信できます。また、信頼できるユーザーにのみ配布されるキーを使用して暗号化された形式で公開できます。フェデレーション認証は、これらのどちらの場合にも適用できます。
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 authentication would be a better fit for this kind of access control. Thus, ABFAB technologies that allow federated authentication directly within (inherently non-web) media streaming protocols would represent an enhancement to this area.
アクセスを管理するための代替メカニズムが存在します。たとえば、ユーザーごとに一意のストリームURIが作成されるアプローチです。ただし、これはストリームURIの機密性の保持に依存しており、認証に使用されるWebページとストリーミングサービス自体の間の通信チャネルも必要です。フェデレーション認証は、この種のアクセス制御に適しています。したがって、（本質的に非Webの）メディアストリーミングプロトコル内で直接フェデレーション認証を可能にするABFABテクノロジは、この領域の拡張を表します。
A visitor from one organization to the premises of another often requires the use of print services. Their home organization 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 organization requires authenticated print requests (usually for accounting purposes), the visitor would usually have to be given credentials that allow this, often supplemented with pay-as-you-go style payment systems.
このサービスが現在提供されている場合、通常は「オープン」プリンター（つまり、匿名の印刷要求を許可するプリンター）を使用して実現します。プリンターの可用性は、Bonjourまたは他の同様のプロトコルを使用してアドバタイズされます。組織が認証された印刷要求を要求する場合（通常は会計目的で）、ビジターには通常、これを許可する資格情報を付与する必要があり、多くの場合、従量課金方式の支払いシステムが追加されます。
Adding federated authentication to the Internet Printing Protocol (IPP) [RFC2911] (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 be one-time visitors to the organization). 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 (https://www.eduroam.org), but could also be used in other contexts such as commercial print kiosks, or in large heterogeneous organizations.
インターネット印刷プロトコル（IPP）[RFC2911]（およびその他の関連プロトコル）にフェデレーション認証を追加すると、これらの訪問者（もちろん、1回限りの訪問者である可能性が高い）を認証する管理オーバーヘッドなしに、この種のリモート印刷サービスが可能になります組織）。これは高等教育にすぐに適用でき、eduroam（https://www.eduroam.org）などのフェデレーションネットワーク認証システムの成功により、このユースケースはますます重要になりますが、次のような他のコンテキストでも使用できます。商業印刷キオスク、または大規模な異種組織。
Telecom operators typically have the following properties:
電気通信事業者には通常、次のような特性があります。
o A large collection of registered users, many of whom may have identities registered to a fairly high level of assurance (often for payment purposes). However, not all users will have this property -- for example, non-contract customers on mobile telecoms infrastructures in countries with low levels of identity registration requirements.
o 登録ユーザーの大規模なコレクション。その多くは、IDをかなり高いレベルの保証（多くの場合、支払い目的）で登録している可能性があります。ただし、すべてのユーザーがこの特性を持つわけではありません。たとえば、ID登録要件のレベルが低い国のモバイル通信インフラストラクチャを利用している非契約の顧客などです。
o An existing network infrastructure capable of authenticating a device (e.g., a cellphone or an Asymmetric Digital Subscriber Line (ADSL) router) and, by inference, its owner.
o デバイス（携帯電話や非対称デジタル加入者線（ADSL）ルーターなど）を認証できる既存のネットワークインフラストラクチャ。
o A large collection of applications (both web-based and non-web-based) that its users wish to access using their devices. These applications could be hosted by the telecom operator directly, or they could be any application or system on the internet -- for example, network messaging services, VoIP, or email.
o ユーザーがデバイスを使用してアクセスしたいアプリケーション（Webベースと非Webベースの両方）の大規模なコレクション。これらのアプリケーションは、通信事業者が直接ホストすることも、インターネット上の任意のアプリケーションやシステム（ネットワークメッセージングサービス、VoIP、電子メールなど）にすることもできます。
At present, authentication to these applications will be typically configured manually by the user on the device (or on a different device connected to that device) by inputting their (usually pre-provisioned out of band) credentials for that application -- one per application.
現在、これらのアプリケーションに対する認証は、通常、ユーザーがデバイス（またはそのデバイスに接続されている別のデバイス）で、そのアプリケーションの（通常は事前にプロビジョニングされている帯域外で）資格情報を入力することにより、アプリケーションごとに1つずつ手動で構成されます。
The use of ABFAB technologies in this case, via a mechanism dubbed "federated cross-layer access" (see [FCLA]) would greatly enhance the user experience of using these applications through devices. Federated cross-layer access would make use of the initial mutual authentication between device and network, to allow subsequent authentication and authorization to happen in a seamless manner for the user of that device authenticating to applications.
この場合、「フェデレーテッドクロスレイヤーアクセス」（[FCLA]を参照）と呼ばれるメカニズムを介してABFABテクノロジーを使用すると、デバイスを介してこれらのアプリケーションを使用するユーザーエクスペリエンスが大幅に向上します。フェデレーテッドクロスレイヤーアクセスは、デバイスとネットワーク間の最初の相互認証を利用して、その後の認証と承認を、そのデバイスのユーザーがアプリケーションに認証するためのシームレスな方法で実行できるようにします。
There are many situations where organizations want to protect information with robust access control, either for implementation of intellectual property right protections, for enforcement of contractual confidentiality agreements, or because of legal regulations. The Enhanced Security Services (ESS) for S/MIME defines an access control mechanism that is enforced by the recipient's client after decryption of the message (see [MSG-AC-REQ]). The data model used makes use of Policy Decision Points (PDPs), which make the policy decisions; Policy Enforcement Points (PEPs), which make decision requests to the PDP; and Policy Information Points (PIPs), which issue attributes about subjects. The decisions themselves are based on the policies and on the subject attributes.
組織が、知的財産権保護の実装、契約上の機密保持契約の実施、または法的規制のために、堅牢なアクセス制御で情報を保護したい状況が数多くあります。 S / MIMEの拡張セキュリティサービス（ESS）は、メッセージの復号化後に受信者のクライアントによって適用されるアクセス制御メカニズムを定義します（[MSG-AC-REQ]を参照）。使用されるデータモデルは、ポリシー決定を行うポリシー決定ポイント（PDP）を利用します。 PDPに決定を要求するポリシー実施ポイント（PEP）。主題に関する属性を発行するポリシー情報ポイント（PIP）。決定自体は、ポリシーとサブジェクト属性に基づいています。
The use of ABFAB technologies in this case would enable both the front-end and back-end attribute exchange required to provide subject attributes. When the PEP contacts the PDP, it would initiate an ABFAB authentication in order to authenticate to the PDP and allow it to obtain these required subject attributes. Once authenticated, the PDP would return a token to the subject PEP that could then be used for subsequent authentications to the PDP.
この場合、ABFABテクノロジーを使用すると、サブジェクト属性を提供するために必要なフロントエンドとバックエンドの両方の属性交換が可能になります。 PEPがPDPに連絡すると、PDPを認証し、これらの必要なサブジェクト属性を取得できるようにするために、ABFAB認証を開始します。認証されると、PDPは対象のPEPにトークンを返し、それをPDPに対する後続の認証に使用できます。
Many smart device deployments involve multiple organizations that do not directly share security infrastructure. For example, in smart power deployments, devices (e.g., appliances) and infrastructure (e.g., electric car chargers) will wish to connect to an energy management system. The energy management system is provided by a utility company in some deployments. The utility company may wish to grant access only to authorized devices; for example, a consortium of utility companies and device manufacturers may certify devices to connect to power networks.
多くのスマートデバイスの展開には、セキュリティインフラストラクチャを直接共有しない複数の組織が関係しています。たとえば、スマートな電力導入では、デバイス（たとえば、アプライアンス）とインフラストラクチャ（たとえば、電気自動車の充電器）がエネルギー管理システムに接続することを望みます。エネルギー管理システムは、一部の展開では公益事業会社によって提供されます。公益事業会社は、許可されたデバイスへのアクセスのみを許可したい場合があります。たとえば、公益事業会社とデバイスメーカーのコンソーシアムは、デバイスを認定して電力ネットワークに接続することができます。
In another example, consumer devices may be used to access cloud services. For example, a camera could be bound to a photo processing site. Authentication and authorization for uploading pictures or ordering prints are required. Sensors could be used to provide data to services run by organizations other than the sensor manufacturer. Authorization and authentication can become very tricky when sensors have no user interface. Cellular devices may want to access services provided by a third party, regardless of whether the cellular network or Wi-Fi is used. This becomes difficult when authorization and billing are coordinated by the cellular provider.
別の例では、消費者向けデバイスを使用してクラウドサービスにアクセスできます。たとえば、カメラを写真処理サイトにバインドできます。写真のアップロードやプリントの注文には認証と承認が必要です。センサーは、センサーメーカー以外の組織が実行するサービスにデータを提供するために使用できます。センサーにユーザーインターフェイスがない場合、承認と認証は非常に難しくなる可能性があります。セルラーデバイスは、セルラーネットワークとWi-Fiのどちらが使用されているかに関係なく、サードパーティが提供するサービスにアクセスする場合があります。これは、承認と請求がセルラープロバイダーによって調整されると困難になります。
The use of ABFAB technologies in this case would provide authentication between one entity, such as a smart device, and its IdP. Only two parties are involved in this exchange; this means that the smart device need not participate in any complicated public-key infrastructure even if it is authenticating against many cloud services. Instead, the device can delegate the process of authenticating the service, and even deciding whether the device should be permitted to access the service, to the IdP. This has several advantages. A wide variety of revenue-sharing models are enabled. Because device authentication is only with a single IdP, phishing of device credentials can be avoided. Authorization and decisions about what personal information to release are made by the IdP. The device owner can use a rich interface such as a website to configure authorization and privacy policy even if the device has no user interface. This model works well with pre-provisioning of device credentials.
この場合のABFABテクノロジーの使用により、スマートデバイスなどの1つのエンティティとそのIdP間の認証が提供されます。この交換に関与するのは2つの当事者のみです。これは、スマートデバイスが多くのクラウドサービスに対して認証されている場合でも、スマートデバイスが複雑な公開鍵インフラストラクチャに参加する必要がないことを意味します。代わりに、デバイスはサービスを認証するプロセスを委任することができ、サービスへのアクセスをデバイスに許可する必要があるかどうかをIdPに委任することもできます。これにはいくつかの利点があります。さまざまな収益分配モデルが可能です。デバイス認証は単一のIdPでのみ行われるため、デバイス資格情報のフィッシングを回避できます。 IdPは、リリースする個人情報の承認と決定を行います。デバイスの所有者は、デバイスにユーザーインターフェイスがない場合でも、Webサイトなどの豊富なインターフェイスを使用して、承認およびプライバシーポリシーを構成できます。このモデルは、デバイスクレデンシャルの事前プロビジョニングに適しています。
This document contains only use cases and defines no protocol operations for ABFAB. Security considerations for the ABFAB architecture are documented in [RFC7831], and security considerations for ABFAB technologies and protocols that are discussed in these use cases are documented in the corresponding protocol specifications.
このドキュメントには使用例のみが含まれ、ABFABのプロトコル操作は定義されていません。 ABFABアーキテクチャのセキュリティに関する考慮事項は[RFC7831]に記載されており、これらの使用例で説明されているABFABテクノロジーとプロトコルのセキュリティに関する考慮事項は、対応するプロトコル仕様に記載されています。
[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>.
[RFC7831]ハウレット、J。、ハートマン、S.、Tschofenig、H。、およびJ.シャード、「Webを超えたフェデレーテッドアクセスのアプリケーションブリッジング（ABFAB）アーキテクチャ」、RFC 7831、DOI 10.17487 / RFC7831、2016年5月、<http ：//www.rfc-editor.org/info/rfc7831>。
[FCLA] Wei, Y., Ed., "Federated Cross-Layer Access", Work in Progress, draft-wei-abfab-fcla-02, March 2012.
[FCLA] Wei、Y.、Ed。、「Federated Cross-Layer Access」、Work in Progress、draft-wei-abfab-fcla-02、2012年3月。
[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.
[MSG-AC-REQ]フリーマン、T。、シャード、J。、およびP.パターソン、「メッセージアクセスコントロールの要件」、進行中の作業、draft-freeman-plasma-requirements-11、2015年3月。
[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>.
[OASIS.saml-profiles-2.0-os] Hughes、J.、Cantor、S.、Hodges、J.、Hirsch、F.、Mishra、P.、Philpott、R.、およびE. Maler、「Profiles for the OASISセキュリティアサーションマークアップ言語（SAML）V2.0」、OASIS標準OASIS.saml-profiles-2.0-os、2005年3月、<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>.
[RFC1939]マイヤーズ、J。およびM.ローズ、「Post Office Protocol-Version 3」、STD 53、RFC 1939、DOI 10.17487 / RFC1939、1996年5月、<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>.
[RFC2326] Schulzrinne、H.、Rao、A。、およびR. Lanphier、「Real Time Streaming Protocol（RTSP）」、RFC 2326、DOI 10.17487 / RFC2326、1998年4月、<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>.
[RFC2911]ヘイスティングス、T。、編、Herriot、R.、deBry、R.、Isaacson、S。、およびP. Powell、「Internet Printing Protocol / 1.1：Model and Semantics」、RFC 2911、DOI 10.17487 / RFC2911 、2000年9月、<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>.
[RFC3501] Crispin、M。、「インターネットメッセージアクセスプロトコル-バージョン4rev1」、RFC 3501、DOI 10.17487 / RFC3501、2003年3月、<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>.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、DOI 10.17487 / RFC3550、2003年7月、 <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>.
[RFC4251] Ylonen、T。およびC. Lonvick、編、「The Secure Shell（SSH）Protocol Architecture」、RFC 4251、DOI 10.17487 / RFC4251、2006年1月、<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>.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<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>.
[RFC5321] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、DOI 10.17487 / RFC5321、2008年10月、<http://www.rfc-editor.org/info/rfc5321>。
Acknowledgments
謝辞
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), Robin Breathe (Oxford Brookes University), Yinxing Wei (ZTE Corporation), Trevor Freeman (Microsoft Corporation), Sam Hartman (Painless Security, LLC), and Yuri Demchenko (University of Amsterdam).
これらの使用例は、イェンスジェンセン（STFCラザフォードアップルトン研究所）、ダニエルクウリル（CESNET）、ミハルプロチャスカ（CESNET）、イアンスチュワート（エジンバラ大学）、スティーブンブース（エディンバラパラレルコンピューティングセンター）からの重要な情報を使用して開発および文書化されています。 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）、およびYuri Demchenko（アムステルダム大学）。
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).
次の個人は、このドキュメントのテキストに重要な貢献をしました：Tim Bannister（マンチェスター大学）、Simon Cooper（Jisc）、Josh Howlett（Jisc）、およびMark Tysom（Jisc）。
Author's Address
著者のアドレス
Dr. Rhys Smith (editor) Jisc Lumen House, Library Avenue, Harwell Oxford OX11 0SG United Kingdom
Dr. Rhys Smith（編集者）Jisc Lumen House、Library Avenue、Harwell Oxford OX11 0SGイギリス
Phone: +44 1235 822145
Email: rhys.smith@jisc.ac.uk