译文Application Bridging for Federated Access

lixiaoshuai

这是Application Bridging for Federated Access Beyond Web Architecture( ABFAB)文件中draft-ietf-abfab-arch-13的一部分。
两天来，我基本翻译了13，以上贴出其中一部分，有后续。

贴出理由：
1.炫技
2.鱼油们都是学计算机的，看懂英语文献的能力需要培养。这篇英文算是网络方面有水平的，大家尝试着阅读翻译，从心理减少看英语文献的恐惧--高le逼格都看懂了，还有什么，不会的单词可以度娘。
3.如果翻译得不够好，请指出，一起交流学习。

-----------------------------------------------------------------------------------------------------分水岭

1. 2.  Architecture
   
2. 
   
3.    We have already introduced the federated access architecture, with
   
4.    the illustration of the different actors that need to interact, but
   
5.    did not expand on the specifics of providing support for non-Web
   
6.    based applications.  This section details this aspect and motivates
   
7.    design decisions.  The main theme of the work described in this
   
8.    document is focused on re-using existing building blocks that have
   
9.    been deployed already and to re-arrange them in a novel way.
   
10. 
    
11.    Although this architecture assumes updates to the relying party, the
    
12.    client application, and the IdP, those changes are kept at a minimum.
    
13.    A mechanism that can demonstrate deployment benefits (based on ease
    
14.    of update of existing software, low implementation effort, etc.) is
    
15.    preferred and there may be a need to specify multiple mechanisms to
    
16.    support the range of different deployment scenarios.
    
17. 
    
18.    There are a number of ways to encapsulate EAP into an application
    
19.    protocol.  For ease of integration with a wide range of non-Web based
    
20.    application protocols, GSS-API was chosen.  The technical
    
21.    specification of GSS-EAP can be found in [RFC7055].
    
22. 
    
23.    The architecture consists of several building blocks, which is shown
    
24.    graphically in Figure 3.  In the following sections, we discuss the
    
25.    data flow between each of the entities, the protocols used for that
    
26.    data flow and some of the trade-offs made in choosing the protocols.
    
27. 
    
28.                                     +--------------+
    
29.                                     |   Identity   |
    
30.                                     |   Provider   |
    
31.                                     |    (IdP)     |
    
32. 
    
33. Howlett, et al.         Expires January 22, 2015               [Page 14]
    
34. Internet-Draft             ABFAB Architecture                  July 2014
    
35. 
    
36.                                     +-^----------^-+
    
37.                                       * EAP      o RADIUS
    
38.                                       *          o
    
39.                                     --v----------v--
    
40.                                  ///                \\\
    
41.                                //                      \\
    
42.                               |        Federation        |
    
43.                               |        Substrate         |
    
44.                                \\                      //
    
45.                                  \\\                ///
    
46.                                     --^----------^--
    
47.                                       * EAP      o RADIUS
    
48.                                       *          o
    
49.    +-------------+                  +-v----------v--+
    
50.    |             |                  |               |
    
51.    | Client      |  EAP/EAP Method  | Relying Party |
    
52.    | Application |<****************>|     (RP)      |
    
53.    |             |  GSS-API         |               |
    
54.    |             |<---------------->|               |
    
55.    |             |  Application     |               |
    
56.    |             |  Protocol        |               |
    
57.    |             |<================>|               |
    
58.    +-------------+                  +---------------+
    
59. 
    
60.    Legend:
    
61. 
    
62.     <****>: Client-to-IdP Exchange
    
63.     <---->: Client-to-RP Exchange
    
64.     <oooo>: RP-to-IdP Exchange
    
65.     <====>: Protocol through which GSS-API/GS2 exchanges are tunneled
    
66. 
    
67.                   Figure 3: ABFAB Protocol Instantiation
    
68. 
    
69. 2.1.  Relying Party to Identity Provider
    
70. 
    
71.    Communications between the Relying Party and the Identity Provider is
    
72.    done by the federation substrate.  This communication channel is
    
73.    responsible for:
    
74. 
    
75.    o  Establishing the trust relationship between the RP and the IdP.
    
76. 
    
77.    o  Determining the rules governing the relationship.
    
78. 
    
79.    o  Conveying authentication packets from the client to the IdP and
    
80.       back.
    
81. 
    
82.    o  Providing the means of establishing a trust relationship between
    
83.       the RP and the client.
    
84. 
    
85. Howlett, et al.         Expires January 22, 2015               [Page 15]
    
86. Internet-Draft             ABFAB Architecture                  July 2014
    
87. 
    
88.    o  Providing a means for the RP to obtain attributes about the client
    
89.       from the IdP.
    
90. 
    
91.    The ABFAB working group has chosen the AAA framework for the messages
    
92.    transported between the RP and IdP.  The AAA framework supports the
    
93.    requirements stated above as follows:
    
94. 
    
95.    o  The AAA backbone supplies the trust relationship between the RP
    
96.       and the IdP.
    
97. 
    
98.    o  The agreements governing a specific AAA backbone contains the
    
99.       rules governing the relationships within the AAA federation.
    
100. 
     
101.    o  A method exists for carrying EAP packets within RADIUS [RFC3579]
     
102.       and Diameter [RFC4072].
     
103. 
     
104.    o  The use of EAP channel binding [RFC6677] along with the core ABFAB
     
105.       protocol provide the pieces necessary to establish the identities
     
106.       of the RP and the client, while EAP provides the cryptographic
     
107.       methods for the RP and the client to validate they are talking to
     
108.       each other.
     
109. 
     
110.    o  A method exists for carrying SAML packets within RADIUS
     
111.       [I-D.ietf-abfab-aaa-saml] which allows the RP to query attributes
     
112.       about the client from the IdP.
     
113. 
     
114.    Protocols that support the same framework, but do different routing
     
115.    are expected to be defined and used the future.  One such effort call
     
116.    the Trust Router is to setup a framework that creates a trusted
     
117.    point-to-point channel on the fly [3].

复制代码

1. 我么已经推出了(网络方向的)联合访问架构,拥有不同客户端交互的例证,但对基于基础应用的非Web(方向)没有发展和提供强力的支持。本节详细介绍这方面的激励和设计决策。这份文件的主题是让现有的（构成non-Web大厦的）积木重新部署并以新颖的方式排列。
   
2. 而这种体系结构一旦更新到RP，客户端，这些变化要保持到最低限度。检验这种部署是否足够好的机制是升级现有软件的简易性，方便性等，而（对多种客户端）实现最优方案，就是指定多个机制，支持不同方案。
   
3. 有多种方式封装EAP到应用协议。为了便于系统集成广泛的非Web的应用协议，GSS-API被选中，技术规格GSS-EAP可以再[RFC7055]中找到。
   
4. 该体系包括几个积木，在下面章节的图解3，我们讨论了各实体间的数据流:基于该协议的数据流，以及在协议中协调做出的数据流。
   
5. + -------------- +
   
6. 身份|
   
7. 供应商|
   
8. （IDP）|
   
9. 
   
10. 豪利特，等。到期2015年1月22日[第14页]
    
11. 互联网草案ABFAB架构2014年7月
    
12. 
    
13. + - ^ ---------- ^ - +
    
14. * EAPRADIUS
    
15. *
    
16. --v ---------- V--
    
17. /// \\\
    
18. // \\
    
19. 联邦|
    
20. 基板|
    
21. \\ //
    
22. \\\ ///
    
23. - ^ ---------- ^ -
    
24. * EAPRADIUS
    
25. *
    
26. + ------------- + + -v ---------- V - +
    
27. | | |
    
28. 客户| EAP / EAP方法|信赖方|
    
29. 应用| <****************> |（RP）|
    
30. | GSS-API | |
    
31. | <----------------> | |
    
32. |应用| |
    
33. |协议| |
    
34. | <=====> | |
    
35. + ------------- + + --------------- +
    
36. 
    
37. 图例：
    
38. 
    
39. <****>：客户端到-IDP交易所
    
40. <---->：客户机到RP交易
    
41. <OOOO>：RP-到-IDP交换
    
42. <====>：通过该协议GSS-API / GS2交往隧道
    
43.                                                 图3：ABFAB协议实例化
    
44. 
    
45. 2.1 RP端身份提供
    
46.     RP端和身份提供者之间的通信是由联合基板完成的。这个通信通道是负责的。
    
47.     o 建立RP和ldP之间的信任关系
    
48.     o 确定管辖关系的规则
    
49.     o 客户端和ldP双向输送认证报文
    
50.     o 建立RP和客户端的信任
    
51. 
    
52. 豪利特，等。到期2015年1月22日[第15页]
    
53. 互联网草案ABFAB架构 2014年7月
    
54. 
    
55.     o 提供一种装置，用于RP从ldP获得客户端的属性
    
56. 
    
57.     该ABFAB工作组选择了AAA框架消息，支持RP与ldP的互通。在AAA框架支持的要      求如下所述:
    
58. 
    
59.     o 骨灰级AAA提供支持RP和ldP的信任关系
    
60. 
    
61.     o 拥有骨灰级AAA管理的协议制定AAA联合内部关系的规则
    
62. 
    
63.     o 一种方法用于在RADIUS[RFC3579]和Diameter[RFC4072]之间携带EPA
    
64. 
    
65.     o EAP信道结合[RFC6677](加核心ABFAB使用协议)提供RP和客户端的必要身份建    立，而EAP提供的加密批准RP和客户端的相互交谈。
    
66. 
    
67.     o 一种方法使RADIUSID [ID.ietf-abfab-AAA-SAML]携带SAML包，并允许RP从    ldP查询客户端属性。
    
68. 
    
69.     o 可以预见，将定义一种协议，支持相同的框架，做不同的路由。成果之一是可信路由，创建一个可信框架，支持点对点的信道飞行。

复制代码

L-0

看来要好好学习学习

酱油哥

强烈支持楼主ing

Ryans

看来要好好学习学习看来要好好学习学习看来要好好学习学习

Hugo101

楼主太给力了！如此枯燥的翻译 都能够坐得住完成，真心佩服，一起学习啦~~~~

StartUp

厉害，我看着就头晕。

2413780002

hongqixiadedan

完全看不懂啊

狮子王辛巴

强烈支持楼主

狮子王辛巴

楼至真威武

showyoyoya

人工置顶吧

showyoyoya1

人工置顶

桦少

不错哦，支持

TakeOver5

厲害啊！

lgx010330

see

MarcoTan

强烈支持楼主ing

自古天道酬勤

support

小小小菜菜菜

厉害了

Dragon910623

谢谢

高山

要好好学习学习