马上注册，结交更多好友，享用更多功能^_^
您需要 登录 才可以下载或查看，没有账号？立即注册
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 可以预见，将定义一种协议，支持相同的框架，做不同的路由。成果之一是可信路由，创建一个可信框架，支持点对点的信道飞行。
| 
( 粤ICP备18085999号-1 | 粤公网安备 44051102000585号)
狗仔卡
发表于 2015-3-5 23:17:06
置顶卡
千斤顶
显身卡
发表于 2015-3-6 18:59:50
