|
马上注册,结交更多好友,享用更多功能^_^
您需要 登录 才可以下载或查看,没有账号?立即注册
x
本帖最后由 lixiaoshuai 于 2015-3-6 08:06 编辑
这是Application Bridging for Federated Access Beyond Web Architecture( ABFAB)文件中draft-ietf-abfab-arch-13的一部分。
两天来,我基本翻译了13,以上贴出其中一部分,有后续。
贴出理由:
1.炫技
2.鱼油们都是学计算机的,看懂英语文献的能力需要培养。这篇英文算是网络方面有水平的,大家尝试着阅读翻译,从心理减少看英语文献的恐惧--高le逼格都看懂了,还有什么,不会的单词可以度娘。
3.如果翻译得不够好,请指出,一起交流学习。
-----------------------------------------------------------------------------------------------------分水岭
- 2. Architecture
- We have already introduced the federated access architecture, with
- the illustration of the different actors that need to interact, but
- did not expand on the specifics of providing support for non-Web
- based applications. This section details this aspect and motivates
- design decisions. The main theme of the work described in this
- document is focused on re-using existing building blocks that have
- been deployed already and to re-arrange them in a novel way.
- Although this architecture assumes updates to the relying party, the
- client application, and the IdP, those changes are kept at a minimum.
- A mechanism that can demonstrate deployment benefits (based on ease
- of update of existing software, low implementation effort, etc.) is
- preferred and there may be a need to specify multiple mechanisms to
- support the range of different deployment scenarios.
- There are a number of ways to encapsulate EAP into an application
- protocol. For ease of integration with a wide range of non-Web based
- application protocols, GSS-API was chosen. The technical
- specification of GSS-EAP can be found in [RFC7055].
- The architecture consists of several building blocks, which is shown
- graphically in Figure 3. In the following sections, we discuss the
- data flow between each of the entities, the protocols used for that
- data flow and some of the trade-offs made in choosing the protocols.
- +--------------+
- | Identity |
- | Provider |
- | (IdP) |
- Howlett, et al. Expires January 22, 2015 [Page 14]
- Internet-Draft ABFAB Architecture July 2014
- +-^----------^-+
- * EAP o RADIUS
- * o
- --v----------v--
- /// \\\
- // \\
- | Federation |
- | Substrate |
- \\ //
- \\\ ///
- --^----------^--
- * EAP o RADIUS
- * o
- +-------------+ +-v----------v--+
- | | | |
- | Client | EAP/EAP Method | Relying Party |
- | Application |<****************>| (RP) |
- | | GSS-API | |
- | |<---------------->| |
- | | Application | |
- | | Protocol | |
- | |<================>| |
- +-------------+ +---------------+
- Legend:
- <****>: Client-to-IdP Exchange
- <---->: Client-to-RP Exchange
- <oooo>: RP-to-IdP Exchange
- <====>: Protocol through which GSS-API/GS2 exchanges are tunneled
- Figure 3: ABFAB Protocol Instantiation
- 2.1. Relying Party to Identity Provider
- Communications between the Relying Party and the Identity Provider is
- done by the federation substrate. This communication channel is
- responsible for:
- o Establishing the trust relationship between the RP and the IdP.
- o Determining the rules governing the relationship.
- o Conveying authentication packets from the client to the IdP and
- back.
- o Providing the means of establishing a trust relationship between
- the RP and the client.
- Howlett, et al. Expires January 22, 2015 [Page 15]
- Internet-Draft ABFAB Architecture July 2014
- o Providing a means for the RP to obtain attributes about the client
- from the IdP.
- The ABFAB working group has chosen the AAA framework for the messages
- transported between the RP and IdP. The AAA framework supports the
- requirements stated above as follows:
- o The AAA backbone supplies the trust relationship between the RP
- and the IdP.
- o The agreements governing a specific AAA backbone contains the
- rules governing the relationships within the AAA federation.
- o A method exists for carrying EAP packets within RADIUS [RFC3579]
- and Diameter [RFC4072].
- o The use of EAP channel binding [RFC6677] along with the core ABFAB
- protocol provide the pieces necessary to establish the identities
- of the RP and the client, while EAP provides the cryptographic
- methods for the RP and the client to validate they are talking to
- each other.
- o A method exists for carrying SAML packets within RADIUS
- [I-D.ietf-abfab-aaa-saml] which allows the RP to query attributes
- about the client from the IdP.
- Protocols that support the same framework, but do different routing
- are expected to be defined and used the future. One such effort call
- the Trust Router is to setup a framework that creates a trusted
- point-to-point channel on the fly [3].
复制代码- 我么已经推出了(网络方向的)联合访问架构,拥有不同客户端交互的例证,但对基于基础应用的非Web(方向)没有发展和提供强力的支持。本节详细介绍这方面的激励和设计决策。这份文件的主题是让现有的(构成non-Web大厦的)积木重新部署并以新颖的方式排列。
- 而这种体系结构一旦更新到RP,客户端,这些变化要保持到最低限度。检验这种部署是否足够好的机制是升级现有软件的简易性,方便性等,而(对多种客户端)实现最优方案,就是指定多个机制,支持不同方案。
- 有多种方式封装EAP到应用协议。为了便于系统集成广泛的非Web的应用协议,GSS-API被选中,技术规格GSS-EAP可以再[RFC7055]中找到。
- 该体系包括几个积木,在下面章节的图解3,我们讨论了各实体间的数据流:基于该协议的数据流,以及在协议中协调做出的数据流。
- + -------------- +
- 身份|
- 供应商|
- (IDP)|
- 豪利特,等。到期2015年1月22日[第14页]
- 互联网草案ABFAB架构2014年7月
- + - ^ ---------- ^ - +
- * EAPRADIUS
- *
- --v ---------- V--
- /// \\\
- // \\
- 联邦|
- 基板|
- \\ //
- \\\ ///
- - ^ ---------- ^ -
- * EAPRADIUS
- *
- + ------------- + + -v ---------- V - +
- | | |
- 客户| EAP / EAP方法|信赖方|
- 应用| <****************> |(RP)|
- | GSS-API | |
- | <----------------> | |
- |应用| |
- |协议| |
- | <=====> | |
- + ------------- + + --------------- +
- 图例:
- <****>:客户端到-IDP交易所
- <---->:客户机到RP交易
- <OOOO>:RP-到-IDP交换
- <====>:通过该协议GSS-API / GS2交往隧道
- 图3:ABFAB协议实例化
- 2.1 RP端身份提供
- RP端和身份提供者之间的通信是由联合基板完成的。这个通信通道是负责的。
- o 建立RP和ldP之间的信任关系
- o 确定管辖关系的规则
- o 客户端和ldP双向输送认证报文
- o 建立RP和客户端的信任
- 豪利特,等。到期2015年1月22日[第15页]
- 互联网草案ABFAB架构 2014年7月
- o 提供一种装置,用于RP从ldP获得客户端的属性
- 该ABFAB工作组选择了AAA框架消息,支持RP与ldP的互通。在AAA框架支持的要 求如下所述:
- o 骨灰级AAA提供支持RP和ldP的信任关系
- o 拥有骨灰级AAA管理的协议制定AAA联合内部关系的规则
- o 一种方法用于在RADIUS[RFC3579]和Diameter[RFC4072]之间携带EPA
- o EAP信道结合[RFC6677](加核心ABFAB使用协议)提供RP和客户端的必要身份建 立,而EAP提供的加密批准RP和客户端的相互交谈。
- o 一种方法使RADIUSID [ID.ietf-abfab-AAA-SAML]携带SAML包,并允许RP从 ldP查询客户端属性。
- o 可以预见,将定义一种协议,支持相同的框架,做不同的路由。成果之一是可信路由,创建一个可信框架,支持点对点的信道飞行。
复制代码
|
|