<>http://www2.ccw.com.cn/05/0505/e/0505e04_1.asp</P>
SAML：集中身份管理的秘诀
<>
<B>■ 晓晨 编译</B>

</P>

<>

<P>身份管理是个复杂问题。它包括口令维护、用户配置和访问控制管理。本文着重介绍了身份管理中被SAML大大简化了的一部分，即基于角色的访问控制（RBAC）。越来越多的厂商在支持RBAC，因为它可以让管理员简化访问控制列表。
<P>曾经调查过一个数据：内部用户和外部伙伴同时在使用的口令有多少？回答居然超过15个。当然，他们可以把这15个口令全记在脑子里，每次需要访问新的资源、新的应用或者新的数据库时，找到相应的管理员。管理员会随叫随到，永不休假，而且始终会有后备管理员。当用户离开公司、被解雇或伙伴转眼间变成对手后，管理员总是会被告知要迅速取消他们的访问权限。在这种理想情况下，我们知道，CIO们总是会因为得到了用户反映的能非常容易地访问数据的夸奖而开心不已。
<P>解决这些问题的一个方法是身份管理。身份管理是指对用户配置、口令和访问控制的管理。访问权限通常存放在不同的位置，不同的应用和资源有着不同的访问控制列表。身份管理必须控制分布在不同位置上的数据、人员和资源的使用情况。过去，身份管理功能由许多不同的系统完成，比如，某一个程序处理用户的配置，另一个程序管理口令，轻型目录访问协议（LDAP）可保存验证信息，而每个应用程序（或管理员）则维持不同的用户访问控制列表。那时，维护、同步及更新这些不同功能是一件费力又费钱的事。
<P>为此，有人开发了结合身份管理等多项功能的验证/授权（AA）Web服务，向整个企业推行联合的单次登录方案，向加强身份管理这一目标迈出了第一步。这种AA Web服务是一种系列的多级服务，可以让用户登录一次，然后就可以调用Web服务、访问很多应用系统和数据资源。这种方法有两大好处：首先，它有助于简化身份管理，因为它把对访问控制的管理从本地的多个应用系统转移到了管理中心，如LDAP。其次，它提供了让Web服务可以访问数据的一般的方法。
<P><B>集中是关键</B>
<P>使用LDAP作为管理中心的办法可采用Jericho Systems公司提供的规则集。这家软件公司开发的EnterSpace产品将SAML服务和规则引擎作为安全包的一个部分。之所以选择Jericho Systems，是因为这家公司提供的产品物美价廉，而且愿意迁就各种限制。利用EnterSpace，你可以结合使用SAML、规则集以及定制的规则，把身份管理的所有部分与作为管理中心的LDAP联系起来。
<P>集中及联系配置、口令管理和访问控制让生活更简单。把身份管理流程与作为参考点和管理中心的LDAP联系起来是很自然的事。不过，LDAP通常用于验证，而不是用于授权。SAML便于把LDAP验证和访问授权联系起来。 
<P><B>SAML的作用</B>
<P>2002年11月，结构化信息标准促进组织（OASIS）批准了SAML作为商业合作伙伴之间交换验证和授权信息的可扩展标记语言（XML）框架，尤其是借助Web服务交换的信息。有了SAML，多家公司管理的站点之间就可以实现基于Web的安全兼容，如单次登录。
<P>SAML利用基本的Web服务标准，如XML、简单对象访问协议（SOAP）和传输层安全（TLS），支持安全交换验证和授权信息。RSA、Netegrity、IBM、Oracle、BEA、Oblix和Jericho等厂商已承诺支持SAML，并正在把这项规范实施到各自的产品中去。
<P>“SAML断言”（SAML Assertion）使用SOAP消息里面的标题通过HTTP进行传输，在断言管理方和转发方之间传输安全信息。比如，用户在某一站点登录后，SAML断言会传输用户验证令牌，其中提供了通过验证登录远程站点验证的手段。SAML封包包括验证令牌和用户属性，可以对照用于验证和访问控制的规则引擎进行检验。
<P>值得一提的是，SAML不负责验证，它只负责传输被验证的信息。另外，SAML可使用不同的验证管理机构，比如LDAP、活动目录和RADIUS，允许使用不同的识别方法，如口令、生物检测术、公钥基础设施（PKI）、安全套接层（SSL）和Kerberos等等。随后，作为传输机制，SAML传输用户已通过验证的断言信息。相比之下，SAML既不进行授权，也不传输访问控制信息。
<P>不妨把SAML想像成电影里由彪形大汉看守的一道门。如果某个可疑的人过来说：“是Joe让我来的”，这意味着Joe验证了该人身份，门卫会把他引到玩扑克牌的地方。如果一位光彩照人的女演员过来说：“是Rudolph让我来的”，门卫会先检查Rudolph的贵宾访问列表，找到她的名字后，一路护送她观看赌场。最后，如果詹姆斯·邦德亮一下卡，看一眼扫描装置，就可能通过了身份卡和虹膜扫描的验证。然后，验证系统会与识别哪些特工有权进入的授权列表作一个对照。
<P><B>SAML的安全风险</B>
<P>SAML可能会受到三种广为人知的安全攻击：
<P>重放攻击（replay attack）:如果恶意黑客劫持SAML令牌后进行重放，获得非法访问权，就会发生这种攻击；
<P>DNS欺骗：如果黑客截获SAML令牌后，发送虚假的DNS地址，就会发生这种攻击;
<P>HTTP链接攻击（HTTP Referrer Attack）：如果黑客重新使用HTTP链接标记，就会发生这种攻击。
<P>利用定时会话可以减小或者消除这三种攻击的威胁。可以采用以下办法来消除攻击：令牌只用一次，并且把令牌使用情况记入日志，这样重新使用就会被标出来；使用IP地址避免DNS欺骗；使用安全超文本传输协议（HTTPS）和SSL/TLS，消除HTTP攻击。专家和分析师一致认为，这些风险是可以缓解的；SAML为断言提供了一种安全标准。
<P><B>过程简介</B>
<P>AA Web服务按顺序执行安全操作。使用用户名和口令对与LDAP服务器上的信息进行对照，就可以识别及验证用户的独特身份。每次登录会话都会创建携有验证信息和用户信息的SAML令牌。用户通过使用定义访问控制的规则，获得访问数据资源的授权，而Jericho Systems的EnterSpace规则引擎负责评估。
<P>这个大体上的流程如图1所示。评估工作包括解析来自SAML令牌的信息，规则基于策略创建而成。因为规则控制访问，并体现策略，所以引擎通过实施规则来执行策略管理。非常笼统地说，用户基于LDAP信息、用户信息和访问规则获得访问权限。此外，用户离开公司后，他们的由LDAP管理的所有账户会被注销，所有访问权同时被取消。这样，你就可以基于作为管理中心的LDAP来集中管理身份。

图1 安全作业顺序
<P>为了加以说明，不妨看看图2所示的几个步骤。用户登录到桌面机上的客户端后，客户端通过本地LDAP（图中没有显示）对其进行验证。然后，客户端向SAML服务方发送包括返回验证信息的请求，SAML服务方对信息打包处理后供Web服务使用。Web服务就会通过发送查询给LDAP服务器（图中没有显示）核实SAML令牌里的验证信息。一旦通过了核实，Web服务就根据规则引擎中的规则，允许访问数据资源。然后，Web服务返回响应给客户端，从而完成用户的请求过程。

图2 验证/授权Web服务过程的重要参与者
<P><B>工作原理</B>
<P>AA服务是一种复杂的Web服务，遵守面向服务架构（SOA）的原则。它基于HTTPS上的SOAP，两者都是非专利性的开放标准，独立于软件语言或者厂商系统。它们不需要使用、许可或维护的费用。利用SOA原则进行设计意味着，你可用模块化方式构建这项Web服务，为了使用和维护的方便性，必要时可以删除或者更换它。因此，你不必改动其他部分，就可以改动架构的任何部分。
<P>AA服务使用本地域LDAP进行验证及随后基于SAML的安全断言。SAML令牌用来把断言传输到可信资源，再由可信资源允许或拒绝对数据资源的访问。
<P>这种功能类似驾驶执照：机动车辆管理局（DMV）就是管理方（好比LDAP），负责核实你的身份及驾驶资格。交警充当可信资源，负责向DMV复核身份，然后根据目前的驾驶资格或者道路规则，批准或者禁止某驾驶员是否有权驾驶。
<P>AA服务在使用规则引擎评估授权规则时，以允许或拒绝访问数据资源限定条件的安全策略为基础。引擎规则对加强策略管理来说是核心所在。
<P>使用LDAP作为管理方还有助于实现身份集中管理。不是在单个资源处管理资源访问，而是使用LDAP和定义用户角色及相应数据参数（如部门和管理级别）的相应策略，来管理用户访问列表。
<P>以下是这个过程的几个重要步骤：
<P>第1步：用户登录。用户需要访问数据资源，于是使用SOAP客户端利用用户名和口令对进行登录。客户端把用户名和口令对（还有可能是其他安全因素）传送给LDAP进行验证。LDAP核实用户后，把信息返回给客户端。
<P>第2步：SAML令牌。SOAP客户端把返回的LDAP信息及其他用户信息传送给SAML客户端。该服务方会按正确格式把信息打包成SAML令牌，SAML客户端把令牌返回给SOAP客户端，然后SOAP客户端把SAML令牌和用户请求打包成SOAP请求。
<P>第3步：SAML会话开始。SOAP客户端开启定时的SAML会话，并发送SOAP请求给相应的Web服务，以满足用户需求。Web服务解析SAML令牌后，通过LDAP核实验证信息。这样，用户只要登录一次：每个Web服务都可以充当用户代理，并获得数据资源的信任，因为Web服务核实了请求信息。
<P>第4步: 授权。经验证后，Web服务发送请求给运行规则引擎的SAML服务器。SAML在这一步并不是绝对必要的，但对我们来说很方便。规则引擎评估用户参数后，确定授权用户的访问级别。评估工作基于体现一组预定访问策略的规则进行。访问级别核实信息返回给Web服务。
<P>第5步: 请求完成。Web服务请求数据源提供数据，把请求结果打包成SOAP响应，然后发回给SOAP客户端。SOAP客户端再把数据提供给用户，同时终止SAML会话。SAML令牌期满，不能重复使用。
<P><B>集中就是统一</B>
<P>总的说来，我们建立的基于SAML的AA Web服务依靠LDAP作为管理中心。使用LDAP和执行安全策略的授权规则引擎可以实现集中身份管理。集中身份管理的一个好处是，可以获得简化和统一的访问控制管理。
<P>集中身份管理意味着，你可以在某一个点管理访问控制列表。比如，终止某个员工的账户就可以终止与中央账户（这里是LDAP）相关的所有访问。这种Web服务为断言、认证和服务提供了通用服务。开发人员可以调用这种Web服务，允许Web服务访问所需的应用和数据资源。
<P><B>所汲取经验</B>
<P>SAML传输的是令牌，它不是验证或者授权机制。为了缓解风险，SAML系统使用定时会话、IP地址、HTTPS和SSL/TLS。安全Web服务非常复杂，涉及法律、安全和政治等方面。
<P>使用LDAP作为管理中心可以实现集中身份管理。规则引擎为访问控制和策略管理提供了有效而灵活的方案（它同时支持基于角色和基于属性的访问控制）。
<P>可以简化身份管理，首先是因为可以在LDAP处激活或者禁用账户。其次，可以避免费用，因为可以集中及减少验证应用，减少审查风险。最后，可以简化身份管理，是因为账户管理使用现有的LDAP服务，从而减少了开销、加强了同步。
（计算机世界报 第05期 B25、B26） </P></P>

　　WSS、SAML和XACML之间有许多共性。或许最明显的就是它们都使用XML表示信息。其次是，因为这三种可用的安全服务都已经在计算机系统中应用多年了，为了更加适用于大型分布式环境，如互联网，它们都具有一些特定的功能。此外，三者都参考并结合了现有的安全性标准，并尽量减少对已有功能的重复。

　　两个主要原因促使三者都采用了XML技术。第一，XML使它们便于扩展，以便可以以一种原有格式无法实现的方式来满足某种特殊需求。第二，XML支持采用大量可用的软件工具进行处理的实现。对于WSS来说，还有一个原因，即，WSS被设计为支持与SOAP的语法和处理模型进行紧密集成，而SOAP是用XML定义的。
SAML

　　授权和审计跟踪是常见的安全服务。以前，大多数系统设计时都假设做出访问控制决定所必需的所有信息都由单个系统来处理，并且所有要记录的数据都放在审计跟踪中。但是，大规模分布式系统通常是由多个组织使用各种产品建立的。这意味着用户可能要由不同的验证方使用不同的方法进行验证。此外，不同的验证方还要保存有关用户特性和属性的不同信息。集中管理所有这些能力和信息是不现实的。SAML提供了标准格式来表示身份验证、用户属性以及请求和接受该标准的协议。这被称为身份联盟（Identity Federation）。

　　在OASIS的最初开发阶段，SAML只指定了该身份信息的生产者与消费者之间的通信。SAML定义了如何创建有关用户属性和身份验证事件的断言，以及如何以一种灵活而可扩展（以便满足其它需求）的方式获得这些信息。SAML还详细定义了一些常见场景（如：Web单点登录）来确保互操作性。

　　Liberty Alliance Project和Internet2 Shiboleth group进一步地增强和扩展了SAML。增加了许多新功能，以便支持SAML验证方之间的通信，更加详细地描述身份验证方法，注销用户并保护隐私。这些工作又提交给OASIS，并合并到SAML2.0中，SAML2.0在2005年3月成为一个OASIS标准。SAML被设计为用于多种不同的环境，支持使用不同的身份验证和加密方法。它支持各种不同的消息流，甚至可以用于不使用XML的遗留环境中。

XACML

　　XACML，也是由OASIS开发的，是一种表示访问控制策略的语言。大多数计算机专业人士都熟悉基于权限或访问控制列表（ACL）的访问控制。但是，这些机制缺少表示复杂策略（在现实系统中经常需要用到）的能力。因此，访问控制策略通常会嵌入应用程序代码中。这使得更改策略（或者只是找出哪些策略正在实施）变得很困难。

　　XACML能够实际地使用任何可用的信息来决定是否该许可对一个资源的访问。也可以关联附加的动作、被调用的契约和决定，例如，要求请求的数据在90天后删除。

　　XACML可以根据资源的属性做出决定，包括资源的内容或环境因素，如日期、时间或位置。它也会考虑到与请求关联的各方的特性，比如角色或组成员关系。这可能不只包括请求方，还包括其他方，比如接受数据方或请求中转方。

　　XACML 2.0在2005年2月成为一个OASIS标准。它在具有多个创建策略的管理员的大规模环境中运行良好。因为SAML可用于任何访问控制系统，XACML可以与SAML一起使用，或者单独使用。有专门的支持它们一起工作的特性。
WSS

　　WSS指定了如何保护通过网络传递的SOAP消息。它包括身份验证、完整性保护和保密性。它没有指定如何实现访问控制，但提供了可以用于访问控制的信息。在WSS出现之前，最常见的保护消息的方法是使用SSL或TLS协议。这些协议仍然适用于许多应用程序，但WSS提供了更多的功能和灵活性。

　　SSL和TLS是对整个消息进行加密，而WSS允许有选择性地实现加密。例如，它允许应用程序防火墙检查没有加密的部分。此外，WSS还支持复杂的多方交互，这是处理复杂的电子商务事务所需要的。

　　此外，WSS在基础架构选择方面提供了更大的灵活性。同SSL和TLS一样，它也支持X.509技术，还可以使用Kerberos、SAML或以前的普通用户名和密码。因为WSS作用于SOAP层，在信息在网络上传输甚至在对消息进行排队或存储时，它都能发挥作用。

　　WSS采用W3C所开发的XML数字签名（XML Digital Signature）和XML加密（XML Encryption）标准。WSS通过将称为Security的XML元素插入SOAP标题中而发挥作用。其中包含所有有关应用于消息的身份验证、数字签名和加密的信息。它向接受方提供解密和验证消息所需的信息。密钥和身份验证信息可以使用X.509证书、Kerberos ticket、SAML断言或其他方法进行定义。

　　2004年，WSS 1.0成为一个OASIS标准。现在，WSS 1.1就要完成了。由于WSS所提供的灵活性，不同产品间的互操作可能会比较困难。为了解决这个问题，Web Services Interoperability Organization组织(WS-I)正在开发一个配置文件，以便减少可变性，并给出使用WSS（以及SSL和TLS）的最佳实践。这个Basic Security Profile (BSP)的草案已经公布，并预计于2006年初完成。WS-I成员还构建了一个示例应用程序来说明WSS和测试工具（可以检查消息是否服从BSP）的正确使用。
结束语

　　上面介绍的三个安全性标准在设计时就被赋予了极大的灵活性，这是通过使用XML而实现的。SAML和XACML在几乎所有的环境中都支持身份验证服务，但更适用于大规模分布式系统。在SOAP环境中，WSS提供了明确的消息保护，但是在软件基础架构方面，它提供了很多选择。有XML作为其共同的基础，这三个标准可以有效地共同使用，或者也可以单独使用。
参考资料
OASIS主页
WSS主页
SAML主页
XACML主页
dev2dev Web ServicesTechnologyCenter
Quick WLS 9.0 SAML Overview——Neil Smithline的blog（dev2dev，2005年8月）

原文出处

Demystifying Security Standards

http://dev2dev.bea.com/pub/a/2005/10/security_standards.html

 作者简介 
Harold Lockhart是BEA的Standards and Architecture Group中的主要工程技术专家。他是在国际上很有知名度的作家和演讲家，他一直以来都是OASIS的Web Services Security和SAML技术委员会的积极捐献者。

如上图所示，微软早期对客户端P3P的支持需要用户有对cookie行为的控制权。
如果用户浏览的网站与用户记录的参数不同，或没有发现隐私政策，IE就会通过其状态栏中的一个图标警告用户（参见下图），并使用户如何处理这一情况。

XACML━━XML访问控制标记语言

         XACML是一种获取资源授权策略的提议，它将解决授权活动的控制问题。它之所以与隐私有关是因为，访问控制是企业保证用户隐私的一种安全机制，XACML可能被用来获取用户为资料源定义的隐私策略。 
         下面是一个XACML策略的例子，病人能够访问他自己的病历。这一策略说明了XACML和SAML（安全主张标记语言）之间的联系。SAML定义了一种语法，认证、授权主张和查询能够用它来表达，并在网络上传输。在下面的例子中，我们假设已经收到了SAML AuthorizationDecisionQuery，它询问应当授予要求查询自己病历的病人什么样的权限。
<?xml version="1.0"/>
<rule>
<target>
<subject>
samlp:AuthorizationDecisionQuery/Subject/NameIdentifier/Name
</subject>
<resource>
<patternMatch>
<attributeRef>
samlp:AuthorizationDecisionQuery/Resource
</attributeRef>
<attibutevalue>medico.com/record.*</attibutevalue>
</patternMatch>
</resource>

<actions>
<saml:Actions>
<saml:Action>read<saml:Action>
</saml:Actions>
</actions>
</target>

<condition>
<equal>
<attributeRef>
samlp:AuthorizationDecisionQuery/Subject/NameIdentifier/Name
</attributeRef>
<attributeRef>
file://medico.com/records/patient/patientName
</attributeRef>
</equal>
</condition>

<effect>Permit</effect>

</rule>

XML Encryption

         XML Encryption是一个获取在任意数据上完成加密操作结果的XML符号的提案。XML Encryption提案的一个重要功能就是它支持只对部分XML文档加密，这不但能够减少加密的工作量，更重要的是，它能够将非机密数据仍然用纯文本形式表达，使一般的XML工具能够处理这部分内容。下面的图显示了一个工资元素被使用XML Encryption加密在单独的xenc名字空间的员工档案：
<?xml version="1.0"?>
<employee id="b3456">
<name>John Smith</name>
<title>Senior Analyst</title>
<salary>
<xenc:EncryptedData>
<xenc:CipherData>
<xenc:Ciphervalue>AbC234ndZ...</xenc:Ciphervalue>
</xenc:CipherData>
</xenc:EncryptedData>
</salary>
</employee>
只有员工自己或被授权的人力资源代表才能够解密<Ciphervalue>元素中的内容，看到员工实际的工资。

XML Signature
         数字签名定义了一个获取对任何数据进行数字签名操作结果的XML模型。与以前的非XML数字签名标准不同的是。XML数字签名既是为了解决了互联网和XML应用中所带来的问题，但它又充分利用了互联网和XML。

XML Signature与隐私密切相关，因为，首先在象.NET My Services和Liberty这样的信息共享环境中，将通过XML Signature对要求应用程序验证的SOAP请求进行处理；第二，用户“肯定”的确认可以作为XML Signature，以防止用户以后再对作出的选择反悔，如下图所示：

如果用户选择了“Sign Confirmation”（确认）按钮，就会（使用用户的私有密码）生成一个与显示出的HTML网页相关的XML Signature，并进行存档，以防止用户对作出的选择反悔。
当然了，现在的浏览器还不支持完成对显示的HTML网页的数字签名，更不用说XML Signature了。但扩展浏览器功能，使它支持签名的技术已经问世了，最终XML Signature技术也会得到支持。


WS-Security
         WS-Security是由微软提出的一个有关在SOAP消息中添加安全元数据的提案。在这里，我们将讨论一个从NET My Services请求用户资料的网站，它有二个方面与WS-Security有关：

1. 请求用户资料的应用程序将使用WWS-Security机制获得.NET My Services的认证，以便.NET My Services确定该用户是否被授予了在其隐私策略中描述的权限。

2. 返回的用户资料的机密性将通过WS-Security对加密功能的支持得到保障。 

         为了保证只有被授权的用户能够访问相关资料，网站必须首先对用户的身份进行认证。应用程序并不直接向.NET My Services认证，而是向微软的Passport服务认证，以获得一个令牌。然后应用程序再把令牌提交给NET My Services，在对令牌进行验证并确认它是来自Passport后，.NET My Services将确认请求符合用户的隐私策略。然后就会接受请求，并在SOAP响应中返回请求的资料。 


         下面是一个SOAP客户端向.NET My Services请求资料的例子，它说明了WS-Security名字空间和HSDL（.NET My Services的数据处理语言）的元素。为了简单起见，我们在下面的代码中活力了实际的名字空间定义：

<SOAP:Envelope>
<SOAP:Header>
<wsse:Security>
<wsse:BinarySecurityToken wsse:valueType="wsse:Kerberosv5"
EncodingType="wsse:Base64Binary" Id="token">
MIIEZzCCA9CgAwIBAgIQEmtJZc0...
</wsse:BinarySecurityToken>

<dsig:Signature>
<dsig:Reference="#busmsg"/>
<dsig:SignatureMethod Algorithm="#hmac-sha1">
<HMACOutputLength>128</HMACOutputLength>
</dsig:SignatureMethod>
<dsig:Signaturevalue>IU(89.Hl8*.</dsig:Signaturevalue>
<dsig:KeyInfo>
<wsse:SecurityTokenReference>
<wsse:Reference URI="#token"/>
</wsse:SecurityTokenReference>
</disg:KeyInfo>
</dsig:Signature>
</wsse:Security>
</SOAP:Header>

<SOAP:Body>
<hsdl:queryRequest id="busmsg">
<xpQuery select='/contact[Name="Smith"]'/>
</hsdl:queryRequest>
</SOAP:Body>

</SOAP:Envelope>

为了对SOAP消息进行认证和授权，.NET My Services应当执行下面的处理： 

         1、使用与Passport共享的私钥加密<BinarySecurityToken>元素中的Kerberos说明书。说明书中包含： 
                  A、发出请求的用户的Passport的PUID。 
                  B、发出请求的应用程序的标识符。 
                  C、临时的对话关健字。 
         2、检查XML Signature中的<Reference>元素，判断SOAP消息中的哪个元素是计算出来的MAC。 
         3、使用从Kerberos证书中解析出来的对话关健字，计算出相同元素的MAC。 
         4、对计算出的MAC与由发出请求的应用程序提供的MAC进行比较。 
         5、如果二个MAC相同，则比较被认证的发出请求的应用程序和用户的隐私政策，判断其请求是否应当被批准。

         下面是一个SOAP响应的例子，我们假设在SOAP响应中返回的用户资料是机密资料，用户的隐私政策要求在传输过程中保证资料的保密性：


<SOAP:Envelope>
<SOAP:Header>
<wsse:Security>
<xenc:EncryptedData id="encdata">
<xenc:EncryptionMethod
Algorithm='http://www.w3.org/xmlenc#3des-cbc'/>
<xenc:CipherData>
<xenc:Ciphervalue>JS*du89sad7</xenc:Ciphervalue>
</xenc:CipherData>
</xenc:EncryptedData>
</wsse:Security>
</SOAP:Header>
<SOAP:Body>
<hsdl:queryResponse id="busmsg">
<xenc:CipherReference idref="#encdata"/>
</hsdl:queryResponse>
</SOAP:Body>
</SOAP:Envelope>

         为适当的人提供适当的访问权限和首先拥有信息同样重要（如果不是更重要的话）。可扩展访问控制标记语言（或 XACML）提供了创建策略和规则来控制信息访问的机制。本文中，作者 Manish Verma 将继续关于 XML 问题的讨论，介绍如何在应用程序中集成 XACML。
关于 XML 安全的上一篇文章中，我讨论了安全性断言标记语言（Security Assertion Markup Language，SAML）。本文将讨论可扩展访问控制标记语言，并从上一期留下的问题开始。SAML 提供了进行验证和授权断言以及传递断言的机制，而 XACML 则提供了定义进行必要的授权决策所需规则的语言。

         比如，假设这样一个场景：某一主体请求访问目标资源，策略执行点（PEP）在决定将目标资源发布给主体之前，要使用策略决策点（PDP）进行检查。访问目标资源请求的生成，以及后续的允许或拒绝访问响应，都属于 SAML 的范围。XACML 解决了 PEP 与 PDP 之间的策略决策交换问题。

访问控制 XACML
         XACML 的初衷是开发一项访问控制和授权系统的标准。目前多数系统都以专有的方式实现访问控制和授权。

         典型的访问控制和授权场景包括三个主要实体：主体、资源和动作以及它们的属性。主体请求得到对资源执行动作的权限。比如，访问请求“允许财务经理在财务服务器上的发票文件夹中创建文件”中，主体是“财务经理”，目标资源是“财务服务器上的发票文件夹”，动作是“创建文件”。

         在专有访问控制系统中，这些实体及其属性的信息保存在资料库中。这种资料库称为访问控制链表（ACL）。不同的专有系统有不同的实现 ACL 的机制，因此难以交换和共享信息。

XACML 的目标

XACML 主要将解决以下问题：

      1，创建一种可移植的、标准的方式来描述访问控制实体及其属性。 
      2， 提供一种机制，以比简单地拒绝访问或授权访问更细粒度的控制访问，也就是说，在“允许”或  “拒绝”之前或之后执行某些操作。

XACML 和 SAML：差别与类似之处

      XACML 体系结构与 SAML 体系结构是紧密相关的。它们有很多相同的概念，要处理的问题域也在很大程度上重叠：验证、授权和访问控制。但是在同一问题域中，它们要解决的是不同的问题。SAML 要解决的是验证，并提供一种机制，在协同实体间传递验证和授权决策，而 XACML 则专注于传递这些授权决策的机制。

      SAML 标准提供了允许第三方实体请求验证和授权信息的接口。内部如何处理这些授权请求则由 XACML 标准解决。XACML 不但处理授权请求，而且还定义了一种机制，来创建进行授权决策所需的规则、策略和策略集的完整基础设施。我将在 XACML 详解中详细说明这些概念。

既然 SAML 与 XACML 分享同一个领域，那么这两种规范很可能最终会合并成一个规范，希望如此。

XACML 体系结构
         XACML 由图 1 中所示的多个组件组成。其中一些组件还可以与 SAML 共享。共享的组件用红线框标记。

图 1. XACML 主要组件

         授权请求到达策略执行点（PEP）。PEP 创建一个 XACML 请求并发送到策略决策点（PDP），后者评估请求并返回一个响应。该响应可以是允许访问的，也可以是拒绝访问的，并具有适当的义务。本文稍后部分将解释这些义务。

         PDP 评估请求中的相关策略和规则后会作出决策。可以应用的策略有多种，PDP 并没有评估所有的策略，而是根据策略目标选择相关的策略进行评估。策略目标包括关于主体、动作和其他环境属性的信息。后面的策略目标创建一节中将说明 PDP 选择评估策略的完整过程。

         为了获得策略，PDP 要用到策略访问点（PAP），PAP 编写策略和策略集，供 PDP 使用。PDP 也可以调用策略信息点（PIP）服务检索与主体、资源或者环境有关的属性值。PDP 作出的授权决策被发送到 PEP。PEP 履行义务，并根据 PDP 发送的授权决策允许或拒绝访问。

XACML 详解

         为了说明 XACML 的不同组件，我们将以一个具体的访问请求为例，创建所需的全部 XACML 组件。访问请求如下：主体 mverma@secf.com 属于 owner 组（主体的属性），它尝试对资源 file:///D:/Documents/Administrator/Desktop/Project Plan.html 执行 open 动作。创建所有必需的 XACML 组件之后，应该能够获得该请求的授权决策。

         要记住，XACML 有三个顶层组件：策略、PEP 和 PDP。为定义的请求创建 XACML 基础设施的过程，也是紧密围绕这三个组件进行的。图 2 说明了这些组件之间的联系：

图 2. 策略语言模型

首先要创建一个策略处理请求。

XACML 策略
         策略包括：一组规则、规则组合算法的标识符、一组义务和一个目标。这就是 XACML 最主要的方面。XACML 的多数动作发生在策略中。

         现在说明如何创建能够处理该请求的策略，策略的范围应该比请求的范围广。您可以创建一个这样的策略：secf.com 名称空间中有电子邮件名的所有用户都可以对资源 file:///D:/Documents/Administrator/Desktop/Project Plan.html 执行任何操作。注意，策略比请求更具一般性。

规则组合算法
         规则组合算法结合策略中所有规则的结果得到最终的授权决策。XACML 定义了下面的规则组合算法（也可定义自己的算法）：

1，eny-overrides（拒绝覆盖）： 只要有一条规则的评估为 Deny，那么最终授权决策也是 Deny。

Ordered-deny-overrides（有序拒绝覆盖）： 与拒绝覆盖相同，只不过评估相关规则的顺序与将规则添加到策略中的顺序相同。

2，ermit-overrides（允许覆盖）： 只要有一条规则计算的评估为 Permit，则最终授权决策也是 Permit。

3，rdered-permit-overrides（允许按顺序覆盖）： 与允许覆盖相同，只不过评估相关规则的顺序与规则添加到策略中的顺序相同。

4，irst-applicable（最先应用）： 遇到的第一条相关规则的评估结果作为最终授权决策的评估结果。
 

策略包括几种子组件：目标、规则、规则组合算法和义务。理解策略就必须理解这些子组件（subcomponent）。现在来看看各种子组件的重要性：

目标（Target）：
         每个策略只有一个目标。该目标有助于确定策略是否与请求有关。策略和请求的相关性决定了是否要为请求评估该策略。这是通过定义目标中的三类属性（主体、资源、动作）及其属性值来实现的。目标中不一定都有这三类属性。将这些属性的值与请求中具有相同属性的值进行比较，如果匹配（对其应用某些函数之后，将会看到它们是否匹配），则认为该策略是相关的，并对其进行评估。

规则：一个策略可以与多条规则相关联。每条规则由条件、结果和目标组成。 
         条件是关于属性的陈述，评估结果为 True、False 或 Indeterminate。 
         结果是符合规则的预期后果，值可以为 Permit 或 Deny。 
         目标：与策略中的目标相同，都有助于确定规则是否与请求有关，实现的机制也与策略中的目标的实现机制类似。

         规则的最终结果取决于条件的评估。如果条件返回 Indeterminate，则该规则返回 Indeterminate。如果条件返回 False，则规则返回 NotApplicable。如果条件返回 True，则返回 Effect 元素的值，可以是 Permit 或 Deny。 

         规则组合算法：如上一条规则所述，一个策略可以包含多条规则。不同的规则有可能得到冲突的结果。规则组合算法负责解决这种冲突，每一策略、每一请求都得到一个最终结果。每个策略只能使用一种规则组合算法。详情请参阅规则组合算法。 

      义务：要知道，XACML 的目标之一是提供更高层次的访问控制，而不仅仅是允许和拒绝决策，义务是实现这种控制的机制。义务是 PEP 必须与授权决策的实施一起执行的动作。在评估策略之后，特定的义务与授权决策一起发送给 PEP。除了强制实施授权决策外，PEP 还负责执行义务所规定的操作。
策略的创建

这一节深入探讨策略创建代码。首先要创建 policy 对象（参见清单 1）和需要的子组件。 本文中的代码例子都使用 Sun 的 XACML 实现（请参阅参考资料）。

清单 1. 创建策略

// Create policy identifier and policy description
URI policyId = new URI("ProjectPlanAccessPolicy");
String description =
"This AccessPolicy applies to any account at secf.com "
+ "accessing file:///D:/Documents/Administrator/Desktop/Project Plan.html.";

// Rule combining algorithm for the Policy

URI combiningAlgId = new URI(OrderedPermitOverridesRuleAlg.algId);

CombiningAlgFactory factory = CombiningAlgFactory.getInstance();

RuleCombiningAlgorithm combiningAlg =
  (RuleCombiningAlgorithm) (factory.createAlgorithm(combiningAlgId));

// Create the target for the policy
Target policyTarget = createPolicyTarget();

// Create the rules for the policy

List ruleList = createRules();

// Create the policy
Policy policy =
  new Policy(
    policyId,
    combiningAlg,
    description,
    policyTarget,
    ruleList);

// Display the policy on the std out
policy.encode(System.out, new Indenter());

清单 1 说明了 policy 的创建过程。真是这样吗？policy 创建的主要部分是子组件的创建。该清单仅仅说明了如何将这些子组件组合成 policy 对象。不过，它确实说明了 policy 的总体结构。策略的组成过程如下：

选择策略的规则组合算法。我使用了 ordered-permit-override 算法，因此将按照策略中规定的顺序评估规则。

创建策略的目标。目标创建有点复杂，它需要专门的代码清单和说明。清单 2 说明了策略的目标创建。
创建策略相关的规则。与目标相同，规则创建也是一个复杂的过程，需要专门的清单。清单 3 专用于说明规则创建。

创建所有必需的策略子组件之后，用它们创建 policy 对象。

将 policy 对象保存到文件中以便传递给 PDP。


下面几小节说明策略子组件的创建。首先是目标创建，最后以规则创建和相关条件结束关于策略创建的讨论。

策略目标创建
         目标创建是创建策略的一个重要方面。目标是为评估请求选择相关策略的机制。为了创建策略目标，需要定义属于主体、资源和动作这三种类型的实体的属性和属性值。当 PDP 评估请求时，它将查找目标属性值与请求中的属性值相同的策略。

         然后将说明如何通过编程来实现这些目标。XACML 提供了一种称为 AttributeDesignator 的机制，用它来比较请求与策略目标中的属性值。

         利用 AttributeDesignator，可以通过定义属性名和类型来指定一个属性。此外，还可以指定属性值，也就是在目标中规定与请求中的属性值进行比较的那个值。要进行比较，需要选择一个预置的函数。该函数以及 AttributeDesignator 都可以用来创建 TargetMatch 对象。您可以创建多个 TargetMatch 对象，每个对象对应一个属性。同一类的所有 TargetMatch 对象放在一个列表中，并传递给 Target 对象。这个 Target 对象就是用来创建 Policy 的目标对象。

         策略的形式应该如下所示：“允许 secf.com 名称空间中列有电子邮件名的任何用户对资源 file:///D:/Documents/Administrator/Desktop/Project Plan.html 执行任何动作。”对于该策略，可以创建包含两个属性的目标，分别用于主体和资源。不需要为动作创建属性，因为要创建的策略对动作没有任何限制。

         清单 2 说明了策略目标的创建。因为要比较请求中主体电子邮件字段的值和目标中规定的字段的值，因此对于主体，可以在目标中指定属性 urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name（电子邮件 ID）。在目标中定义属性类型（urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name）、属性名（urn:oasis:names:tc:xacml:1.0:subject:subject-id）和比较函数（urn:oasis:names:tc:xacml:1.0:function:rfc822Name-match）。 该函数将目标中规定的属性值与请求中具有相同属性的值进行比较。资源类型 http://www.w3.org/2001/XMLSchema#anyURI 的属性也是按照类似的步骤进行比较的。

清单 2. 创建策略目标

public static Target createPolicyTarget() throws URISyntaxException {
  List subjects = new ArrayList();
  List resources = new ArrayList();

  // Attributes of Subject type
  // Multiple subject attributes can be specified. In this
  // case only one is being defined.

  List subject = new ArrayList();

  URI subjectDesignatorType =
    new URI("urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name");
  URI subjectDesignatorId =
    new URI("urn:oasis:names:tc:xacml:1.0:subject:subject-id");
  // Match function for the subject-id attribute
  String subjectMatchId =
    "urn:oasis:names:tc:xacml:1.0:function:rfc822Name-match";
  AttributeDesignator subjectDesignator =
    new AttributeDesignator(
                  AttributeDesignator.SUBJECT_TARGET,
                  subjectDesignatorType,
                  subjectDesignatorId,
                  false);

  StringAttribute subjectvalue = new
    StringAttribute("secf.com");

  // get the factory that handles Target functions
  FunctionFactory factory =
    FunctionFactory.getTargetInstance();

  // get an instance of the right function for matching
  // subject attributes
  Function subjectFunction =
    factory.createFunction(subjectMatchId);

  TargetMatch subjectMatch = new TargetMatch(
                          TargetMatch.SUBJECT,
                  subjectFunction,
                  subjectDesignator,
                  subjectvalue);

  subject.add(subjectMatch);

  // Attributes of resource type
  // Multiple resource attributes can be specified. In this
  // case only one is being defined.

  List resource = new ArrayList();

  URI resourceDesignatorType =
    new URI("http://www.w3.org/2001/XMLSchema#anyURI");
  URI resourceDesignatorId =
    new URI("urn:oasis:names:tc:xacml:1.0:resource:resource-id");

  // Match function for the resource-id attribute
  String resourceMatchId =
    "urn:oasis:names:tc:xacml:1.0:function:anyURI-equal";

  AttributeDesignator resourceDesignator =
    new AttributeDesignator(
                  AttributeDesignator.RESOURCE_TARGET,
                  resourceDesignatorType,
                  resourceDesignatorId,
                  false);

  AnyURIAttribute resourcevalue =
    new AnyURIAttribute(
      new URI("file:///D:/Documents/Administrator/Desktop/Project Plan.html"));

  // Get an instance of the right function for matching
  // resource attribute
  Function resourceFunction =
    factory.createFunction(resourceMatchId);

  TargetMatch resourceMatch = new TargetMatch(
                               TargetMatch.RESOURCE,
                         resourceFunction,
                         resourceDesignator,
                         resourcevalue);

  resource.add(resourceMatch);

  // Put the subject and resource sections into their lists
  subjects.add(subject);
  resources.add(resource);

  // Create and return the new target. No action type
  // attributes have been specified in the target
  return new Target(subjects, resources, null);
}

规则的创建
         规则是策略中最重要的子组件。如前所述，规则实质上是评估 Permit、Deny、Indeterminate 或 NotApplicable 的条件。

继续创建处理授权请求（请参阅“XACML 详解”中的第一张图片）所需要的 XACML 组件，现在需要创建适当的规则。创建规则实质上就是创建相应的条件，如清单 3 所示。查看代码，可以看到它完成了以下三项操作：

创建规则目标。
定义规则结果。
创建条件。
其中的两个：创建规则目标和定义规则结果，非常简单。第三点创建条件比较复杂，后面还将详细说明。

         要创建的符合该请求的规则应该是：“如果主体 mverma@secf.com 属于组 owner，并尝试打开资源 file:///D:/Documents/Administrator/Desktop/Project Plan.html，那么允许访问。” 创建这样的规则，首先要创建目标，以便针对将处理的请求评估规则。创建规则目标的方式类似于策略目标的创建方式。然后，将规则的 effect 定义为 Permit。为了让规则返回 effect 的值，关联条件必须返回 True。清单 4 中的代码说明了条件的创建。

清单 3. 创建规则

public static List createRules() throws URISyntaxException {
  // Step 1: Define the identifier for the rule
  URI ruleId = new URI("ProjectPlanAccessRule");
  String ruleDescription = “Rule for accessing project plan";

  // Step 2: Define the effect of the rule
  int effect = Result.DECISION_PERMIT;

  // Step 3: Get the target for the rule
  Target target = createRuleTarget();

  // Step 4: Get the condition for the rule
  Apply condition = createRuleCondition();

  // Step 5: Create the rule
  Rule openRule = new Rule(ruleId, effect,ruleDescription, target, condition);

  // Create a list for the rules and add the rule to it

  List ruleList = new ArrayList();
  ruleList.add(openRule);

  return ruleList;

}

AttributeDesignator 返回值
         AttributeDesignator 可能为一个属性返回多个值（因为请求可能包含多个匹配）。为此，XACML 有一种称为袋子（bag）的特殊数据类型。袋子是允许重复的无序集合。AttributeDesignator 总是返回袋子，即使只有一个返回值。一旦返回一个袋子，就将对袋子中的值与预期值进行比较，以便作出授权决策。对于目标，不需要使用函数从袋子中提取任何值，但是对于条件，却需要这样做。这是因为，对于目标，PDP 会自动为 AttributeDesignator 返回的每个元素应用匹配的函数。
 

清单 4 说明了规则条件的创建。与为策略目标创建 AttributeDesignator 的方式基本相同，也需要创建 AttributeDesignator 对象，比较请求中的属性值和条件中规定的值。在这里，我们感兴趣的属性是主体所属的 group。如果要让条件返回 True，那么 group 属性的值必须是 owner。

惟一要补充的是，必须满足以下条件：使用函数从 AttributeDesignator 返回的多个值中提取一个值。该例中使用函数 urn:oasis:names:tc:xacml:1.0:function:string-one-and-only。关于处理 AttributeDesignator 中的多个值的更多信息，请参阅 AttributeDesignator 返回值。

正如从清单 4 中可以看到的，需要创建 AttributeDesignator 对象来定义希望与请求中的值进行比较的属性。比较算法是用来比较属性值的。然后要定义可以从 AttributeDesignator 返回的那些值中选出一个值的函数。最后创建 Apply 对象，它类似于目标中创建的 TargetMatch 对象。Apply 对象的目的是对从袋子（由 AttributeDesignator 返回）中选择的值应用比较函数，将它与条件中规定的值进行比较。

清单 4. 创建规则条件

public static Apply createRuleCondition() throws URISyntaxException {
  List conditionArgs = new ArrayList();

  // Define the name and type of the attribute
  // to be used in the condition
  URI designatorType = new URI("http://www.w3.org/2001/XMLSchema#string");
  URI designatorId = new URI("group");

  // Pick the function that the condition uses
  FunctionFactory factory = FunctionFactory.getConditionInstance();
  Function conditionFunction = null;
  try {
      conditionFunction =
          factory.createFunction(
              "urn:oasis:names:tc:xacml:1.0:function:" + "string-equal");
  } catch (Exception e) {
      return null;
  }

  // Choose the function to pick one of the
  // multiple values returned by AttributetDesignator

  List applyArgs = new ArrayList();

  factory = FunctionFactory.getGeneralInstance();
  Function applyFunction = null;
  try {
      applyFunction =
          factory.createFunction(
              "urn:oasis:names:tc:xacml:1.0:function:"
                  + "string-one-and-only");
  } catch (Exception e) {
      return null;
  }

  // Create the AttributeDesignator
  AttributeDesignator designator =
      new AttributeDesignator(
           AttributeDesignator.SUBJECT_TARGET,
           designatorType,
           designatorId,
           false
           null);
  applyArgs.add(designator);

  // Create the Apply object and pass it the
  // function and the AttributeDesignator. The function
  // picks up one of the multiple values returned by the
  // AttributeDesignator
  Apply apply = new Apply(applyFunction, applyArgs, false);

  // Add the new apply element to the list of inputs
  // to the condition along with the Attributevalue
  conditionArgs.add(apply);

  StringAttribute value = new StringAttribute("owner");
  conditionArgs.add(value);

  // Finally, create and return the condition
  return new Apply(conditionFunction, conditionArgs, true);
}

这样，策略创建任务就完成了。我们简单回顾一下策略创建过程。首先，要创建必要的策略子组件：策略目标、规则和规则组合算法。不用为策略创建义务，因为它们是可选的。创建规则实质上意味着创建规则目标和条件，这些都使用它们自己的代码清单作了说明。这里使用的所有的策略子组件都是用来创建策略的。

创建处理授权请求所需 XACML 组件的下一步是创建 PEP。PEP 的作用是什么呢？它为您创建的所有这些 XACML 组件创建授权请求！

策略实施点（PEP）

         PEP 根据请求者的属性、请求的资源、动作和其他信息创建请求。在这里，我将展示创建请求的机制。为了方便起见，我将再次使用该请求：主体 mverma@secf.com 属于 owner 组（主体的属性），并尝试对资源 file:///D:/Documents/Administrator/Desktop/Project Plan.html 执行 open 动作。要创建这样的请求，您需要两个主体属性、一个资源属性和一个动作属性。两个主体属性是 rfc822Name（电子邮件 ID）和主体所属的组。资源属性是资源的 URI，动作属性是打开资源的动作。清单 5 说明了 PEP 和所有这些属性的创建。

现在，您已经看到了策略的创建和 PEP 请求的生成，剩下的只有创建 PDP 了。

策略决策点（PDP）
         PDP 针对策略评估请求，并返回响应。

因为 XACML 规范没有规定把策略和请求传递给 PDP 以便评估请求的具体机制，所以可以选择您认为方便的任何机制。该例中，策略和请求是作为命令行参数传递给 PDP。

注意，PDP 仍然基于需要服务的请求类型。它是一种通用组件，接受任何请求和相关的策略集合，并为可用的策略评估请求。清单 6 说明了如何创建 PDP，以及如何用它来评估来自 PEP 的请求。PDP 创建和请求评估的详细过程将在清单 6 后介绍。

清单 6. 创建 PDP

public static void main(String[] args) throws Exception {
  if (args.length < 2) {
      System.out.println("Usage: <request> <AccessPolicy> [policies]");
      System.exit(1);
  }
 
  // Step 1: Get the request and policy file from the command line
  String requestFile = null;

  requestFile = args[0];
  String[] policyFiles = new String[args.length - 1];

  for (int i = 1; i < args.length; i++)
      policyFiles[i - 1] = args[i];
 
  // Step 2: Create a PolicyFinderModule and initialize it
  // Use the sample FilePolicyModule, which
  // is configured using the policies from the command line
 
  FilePolicyModule filePolicyModule = new FilePolicyModule();
  for (int i = 0; i < policyFiles.length; i++)
      filePolicyModule.addPolicy(policyFiles[i]);

  // Step 3: Set up the PolicyFinder that this PDP will use
  //
  PolicyFinder policyFinder = new PolicyFinder();
  Set policyModules = new HashSet();
  policyModules.add(filePolicyModule);
  policyFinder.setModules(policyModules);

  // Step 4: Create the PDP
  PDP pdp = new PDP(new PDPConfig(null, policyFinder, null));

 //  Get the request send by the PEP
  RequestCtx request =
      RequestCtx.getInstance(new FileInputStream(requestFile));

  // Step 5: Evaluate the request. Generate the response.
  ResponseCtx response = pdp.evaluate(request);

  // Display the output on std out
  response.encode(System.out, new Indenter());
}

下面将一步步地说明 PDP 的创建和请求评估：

从命令行参数获得请求和策略文件。
创建 PolicyFinderModule，并使用 FilePolicyModule 对象将其初始化。使用命令行中的策略配置 FilePolicyModule。PolicyFinderModule 是下面三个发现程序模块（finder module）之一：
PolicyFinderModule
AttributeFinderModule
ResourceFinderModule
这些模块是 SUN XACML 实现用来发现属性、策略和资源的机制。
设置 PDP 将使用的策略发现程序。
通过初始化 PDP 类来创建 PDP。把使用 FilepolicyModule 配置的 PDPConfig 对象提供给 PDP 构造函数。
为 PDP 调用 evaluate 方法评估来自 PEP 的请求，这将返回授权决策。如果完全按照本文所述创建 XACML 组件，PDP 将提供 Permit 授权决策。
授权决策传回 PEP。可以选择把决策发回 PEP 的机制。

到此为止，处理请求需要创建的三种主要 XACML 组件 —— 策略、PEP 和 PDP —— 都已经介绍完毕，并给出了相应的例子。

结束语
访问控制几乎是所有应用程序或多或少都要用到的一个领域。XACML 是将该领域标准化的一次尝试。虽然 XACML 是一种冗长的语言，但是一旦掌握了其基本概念和语言流，就很容易构造访问控制机制。

本文介绍了创建基本的 XACML 组件的过程：

策略，包括规则和策略目标
PEP
PDP
掌握这些知识之后，就可以在当前和将来的应用程序中采用 XACML 处理访问控制。

结构化信息标准促进组织（OASIS）建立的安全标准SAML（安全声明标记语言），是基于XML（可扩展标记语言）面向Web服务的架构。SAML通过因特网对不同的安全系统的信息交换进行处理。

了解SAML
         SAML并不是一项新技术。确切地说，它是一种语言，进行单一的XML描述，允许不同安全系统产生的信息进行交换。通常来说，一个企业物理或逻辑的范围已经界定了企业的IT安全；然而，由于在线合作需要共享更可靠的安全服务环境，因此IT安全越来越成为人们关注的重点问题。

         SAML正是为解决网络安全性问题而发挥其作用。SAML在传统意义上的安全界定与商务站点之间，建立了一种安全信息的交换渠道。SAML作为安全信息交换的"中间人"，促使一个站点上的交易业务能够在另一个信任的站点上得到处理完成。由此可见，实现交易双方商业协议或合作的一个先决条件，是要求使用SAML作为共享的安全架构的一部份。

SAML是如何工作的
         SAML在标准行业传输协议环境里工作，例如HTTP、SMTP和FTP；同时也服务于各种各样的XML文件交换框架，如：SOAP和BizTalk。SAML具备的一个最突出的好处，是使用户能够通过因特网进行安全证书移动。也就是说，使用SAML标准作为安全认证和共享资料的中间语言，能够在多个站点之间实现单点登录。

         此外，SAML还针对不同的安全系统提供了一个共有的框架，允许企业及其供应商、客户与合作伙伴进行安全的认证、授权和基本信息交换。由于SAML是通过XML对现有的安全模式进行描述，因此它是一个中立的平台并且不需要依赖于供应商的基础结构。

Web浏览器－SAML声明是由一个Web浏览器通过cookies或URL链接进行通信。

HTTP - SAML声明通过标题或一个HTTP POST ，从源站点传送到目的站点。

MIME - SAML 声明被封装为一个单一的MIME（多用途网际邮件扩充协议）安全包，由消息的有效载荷组成，例如：一张定购单、或在线银行的信用报告书等等。

SOAP - SAML 声明限制／约束SOAP文档的信封标题以保证有效载荷。

         ebXML- 电子商务全球化标准提供了一个基于MIME的封装结构，通常用于绑定SAML声明进行商业有效载荷。

         若你所见，SAML使用的对象称为断言或声明。这些声明由值得信任的权威安全机构，通过使用请求／响应协议（SAMLQuery, SAML QueryResponse）产生并发送。SAML在XML中为认证声明和认证属性建立了一个数据格式，其参数取决于安全服务产生的基于政策的认证结果。
SAML的消息格式能够从一个源站点(站点起到SAML认证管理机构的作用)将声明发送给一个接受者。使电子商务合作中的事务处理速度得到加快，并且使认证环境的复杂性得到全面的简化。事实上，SAML并没有创建安全政策，而是由相关的安全权威机构进行制定；但是SAML为这些安全政策的表达提供了标准格式，因此安全决议能够得到有效地制定。

SAML的工作原理
1．用户向认证机构提交证书（这里的认识机构是指SAML能够识别的任何安全引擎或商业应用程序）。

2．认证机构对用户的证书进行断言，并且产生一个认证声明以及一个或更多的属性声明（例如用户资料信息）。用户立即就会得到由SAML断言的认证和识别标志。

3．用户使用这个SAML标志尝试访问一个受保护的资源。

4．最终用户对保护资源的访问请求被PEP（Policy Enforcement Point）截取，同时最终用户的SAML标志（认证声明）被PEP提交给属性管理（能够被SAML识别的任何安全引擎或商业应用程序）。

5．属性管理或PDP（Policy Decision Point）基于自身的政策标准产生一个决定。一旦批准最终用户对保护资源进行访问，就会产生一个附加在SAML标志上的属性声明。最终用户的SAML标志就能够以单点登录方式呈现给信任的商业伙伴。

SAML如何使用

介绍几种SAML的使用方式

单点登录
         举一个简单的例子：用户在一个站点上取得认证授权，当用户需要访问另一个相关站点的资源时，目的站点（保护资源的持有者）能够使用SAML从源站点调取用户的证书信息。此时SAML对信息交换的处理发生在后台，因此用户的资源实际上被不同的安全系统进行了定位。

授权服务
         通常来说，当一个用户请求访问一个动态保护的或受限制的Web 资源时，访问请求已被传递给一个后端应用程序。SAML使合作组织的后端安全架构相互作用，确定是否他们准予用户的访问请求。

B2B
         在B2B情形中，参与在线商业合作的双方能够利用SAML，允许他们各自的安全架构彼此进行信息交换，从而使商业活动得到安全快捷的进行。或者，合伙人通过使用值得信任的第三方SAML B2B服务，在交易过程中对安全信息进行交换和断言。

会话
        当用户采用单点登录方式并且保持会话参数和通过不同资源站点的数据时，SAML能够允许用户在不同站点自由行进。源站点提供证书信息，目的站点保持会话对所需要的数据进行验证。在这个过程中，用户可能并没有意识到后台正在进行的相关安全处理。

掌握SAML的实际应用知识

         企业管理者需要知道SAML能够提供哪些服务。SAML促进了不同安全系统之间的互操作性，是Web服务功能性方面的一大发展。在许多情形中，管理将越来越需要对安全问题进行监督，并且实现安全标准的通信。

         在过去的三年中，人们开发出了许多关于信息安全（Information Security）的新标准。其中最为人们所认可的是Web Services安全性（Web Services Security，WSS）、安全性断言标记语言（Security Assertion Markup Language，SAML）和可扩展访问控制标记语言（Extensible Access Control Markup Language，XACML）。本文会简单介绍这三者，包括它们是如何开发出来的、为什么需要它们、如何使用它们、它们之间以及它们与现有各种安全性标准之间的关联。以后的文章会对这些内容进行更详细的介绍。

简介

         WSS、SAML和XACML之间有许多共性。或许最明显的就是它们都使用XML表示信息。其次是，因为这三种可用的安全服务都已经在计算机系统中应用多年了，为了更加适用于大型分布式环境，如互联网，它们都具有一些特定的功能。此外，三者都参考并结合了现有的安全性标准，并尽量减少对已有功能的重复。

         两个主要原因促使三者都采用了XML技术。第一，XML使它们便于扩展，以便可以以一种原有格式无法实现的方式来满足某种特殊需求。第二，XML支持采用大量可用的软件工具进行处理的实现。对于WSS来说，还有一个原因，即，WSS被设计为支持与SOAP的语法和处理模型进行紧密集成，而SOAP是用XML定义的。

SAML

         授权和审计跟踪是常见的安全服务。以前，大多数系统设计时都假设做出访问控制决定所必需的所有信息都由单个系统来处理，并且所有要记录的数据都放在审计跟踪中。但是，大规模分布式系统通常是由多个组织使用各种产品建立的。这意味着用户可能要由不同的验证方使用不同的方法进行验证。此外，不同的验证方还要保存有关用户特性和属性的不同信息。集中管理所有这些能力和信息是不现实的。SAML提供了标准格式来表示身份验证、用户属性以及请求和接受该标准的协议。这被称为身份联盟（Identity Federation）。

         在OASIS的最初开发阶段，SAML只指定了该身份信息的生产者与消费者之间的通信。SAML定义了如何创建有关用户属性和身份验证事件的断言，以及如何以一种灵活而可扩展（以便满足其它需求）的方式获得这些信息。SAML还详细定义了一些常见场景（如：Web单点登录）来确保互操作性。

         Liberty Alliance Project和Internet2 Shiboleth group进一步地增强和扩展了SAML。增加了许多新功能，以便支持SAML验证方之间的通信，更加详细地描述身份验证方法，注销用户并保护隐私。这些工作又提交给OASIS，并合并到SAML2.0中，SAML2.0在2005年3月成为一个OASIS标准。SAML被设计为用于多种不同的环境，支持使用不同的身份验证和加密方法。它支持各种不同的消息流，甚至可以用于不使用XML的遗留环境中。

XACML

         XACML，也是由OASIS开发的，是一种表示访问控制策略的语言。大多数计算机专业人士都熟悉基于权限或访问控制列表（ACL）的访问控制。但是，这些机制缺少表示复杂策略（在现实系统中经常需要用到）的能力。因此，访问控制策略通常会嵌入应用程序代码中。这使得更改策略（或者只是找出哪些策略正在实施）变得很困难。

         XACML能够实际地使用任何可用的信息来决定是否该许可对一个资源的访问。也可以关联附加的动作、被调用的契约和决定，例如，要求请求的数据在90天后删除。

         XACML可以根据资源的属性做出决定，包括资源的内容或环境因素，如日期、时间或位置。它也会考虑到与请求关联的各方的特性，比如角色或组成员关系。这可能不只包括请求方，还包括其他方，比如接受数据方或请求中转方。

         XACML 2.0在2005年2月成为一个OASIS标准。它在具有多个创建策略的管理员的大规模环境中运行良好。因为SAML可用于任何访问控制系统，XACML可以与SAML一起使用，或者单独使用。有专门的支持它们一起工作的特性。

WSS

         WSS指定了如何保护通过网络传递的SOAP消息。它包括身份验证、完整性保护和保密性。它没有指定如何实现访问控制，但提供了可以用于访问控制的信息。在WSS出现之前，最常见的保护消息的方法是使用SSL或TLS协议。这些协议仍然适用于许多应用程序，但WSS提供了更多的功能和灵活性。

         SSL和TLS是对整个消息进行加密，而WSS允许有选择性地实现加密。例如，它允许应用程序防火墙检查没有加密的部分。此外，WSS还支持复杂的多方交互，这是处理复杂的电子商务事务所需要的。

         此外，WSS在基础架构选择方面提供了更大的灵活性。同SSL和TLS一样，它也支持X.509技术，还可以使用Kerberos、SAML或以前的普通用户名和密码。因为WSS作用于SOAP层，在信息在网络上传输甚至在对消息进行排队或存储时，它都能发挥作用。

         WSS采用W3C所开发的XML数字签名（XML Digital Signature）和XML加密（XML Encryption）标准。WSS通过将称为Security的XML元素插入SOAP标题中而发挥作用。其中包含所有有关应用于消息的身份验证、数字签名和加密的信息。它向接受方提供解密和验证消息所需的信息。密钥和身份验证信息可以使用X.509证书、Kerberos ticket、SAML断言或其他方法进行定义。

         2004年，WSS 1.0成为一个OASIS标准。现在，WSS 1.1就要完成了。由于WSS所提供的灵活性，不同产品间的互操作可能会比较困难。为了解决这个问题，Web Services Interoperability Organization组织(WS-I)正在开发一个配置文件，以便减少可变性，并给出使用WSS（以及SSL和TLS）的最佳实践。这个Basic Security Profile (BSP)的草案已经公布，并预计于2006年初完成。WS-I成员还构建了一个示例应用程序来说明WSS和测试工具（可以检查消息是否服从BSP）的正确使用。

结束语

上面介绍的三个安全性标准在设计时就被赋予了极大的灵活性，这是通过使用XML而实现的。SAML和XACML在几乎所有的环境中都支持身份验证服务，但更适用于大规模分布式系统。在SOAP环境中，WSS提供了明确的消息保护，但是在软件基础架构方面，它提供了很多选择。有XML作为其共同的基础，这三个标准可以有效地共同使用，或者也可以单独使用。

      XACML是由OASIS technique committee制定的，目前的规范是2.0，大家可以从这个连接下载：http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml

      XACML3.0最近刚出来，是用来制定administration and delegation of XACML的，我的导师的观点，delegation是属于daministration的一部分。
从上面的连接可以下载。。

若大家真的对XACML有兴趣，必须加入OASIS的mailing lists，从上面那个连接加入。

      Sun什么事情都不落后，他针对XACML已经开发API了，基本上实现了XACML1.0的全部规范，2.0也差不多了，你需要从CVS里面下载，另外一点，SUN也有针对XACML实现的讨论的mailing lists.
Sun implemenation of XACML的连接在这里：
http://sunxacml.sourceforge.net/

         请问谁现在在看RB-XACML profile，是否可以跟小弟讨论一下，里面的user-role assignment如何来弄，如何将user-role assignment, role-permission assignment整合起来。

         现在介绍一些SAML，SAML的全称是 SECURITY ASSERTATION MARKUP LANGUAGE。他表示安全的信息传递以断言的形式表示。SAML的specification可以在下面的连接：
http://www.oasis-open.org/committees/security/
和XACML一样，你最好也加入他们的user mailing lists来看别人提出的问题。我现在只简单说明一下SAML有什么用，详细的请看specification

SAML实现单点登陆 
         单点登陆表示用户A在站点A认证登陆了，到用户到达站点B的时候自动登陆，不需要在站点B重新输入用户名和密码再次验证。如何做到这样呢，需要用SAML，站点B会向站点A发出SAML 的认证请求，站点A会回复站点B一个SAML认证断言，说明用户A在我站点A认证过了，而站点B信任站点A来的认证断言。所以。。。

SAML在web services中的应用 
         web service-security，security的信息加在soap head信息中，我们将安全信息用SAML表达，将SAML断言放在soap head里面

SAML在XACML结合使用 
         这个是我研究的东西，也是要做的。因为在分布式系统中，policies可能不在同一个地方，PEP和PDP可能是不同的domain或者application，XACML请求和决定等信息最好放在SAML中来传递，也就是SAML2.0 profile of XACML,大家可以去XACML官方网站下载（我在上面一提了XACML的连接了）。。

若有朋友在使用SAML和XACML结合，来研究SAML2.0 Profile of XACML，请联系小弟讨论一下好吗？？

Web服务的安全模型和安全规范

         Web 服务安全性模型引入了一个由各个相互联系的规范组成的集合，这些规范描述了把安全性功能程序放到 Web 服务环境中的方法。体系结构被设计成允许对规范进行混合匹配，使实现者能够仅部署他们需要的那部分。这些规范中的第一个 — Web 服务安全性（Web Services Security）（或称 WS-Security）文档 — 提供了把消息完整性和机密性功能程序添加到 Web 服务中所必需的基本元素，并且提供把安全性令牌（例如，数字证书和 Kerberos 票据）关联到 SOAP 消息的方法。WS-Security 为正提议的 Web 服务安全性模型打下了基础。随着时间的推移，除安全性外，还将引入其它规范来解决安全性策略、信任、隐私权和授权。



      访问控制模型有很多，按照年代来例举有: BLP model, HRU model, The Clark wilson model, The chinese wall model, RBAC model.

ACL and capability lists 是属于 protection matrix model中两种实现方式。Idea来自 access control matrix。

      XACML是一个access control policy，request and response语言，它的idea来自access control matrix (subject, resource (object), action).她可以用来实现以上的几种model。

         我的毕业设计中是XACML同时实现了ACL and RBAC，单点登陆是用proxy certificate来实现的。。现在SAML比较成绩了，可以用SAML和XACML结合了。。请问你们有用到将SAML 和XACML结合吗？？ 你们有发表或者提供技术报告否？？

         web service作为一个service，client or another service来访问，需要进行认证和授权。所以在SOAP消息中携带安全因素，是否允许调用service某个function对information object进行访问，可以写access control policy。
      关于单点登陆的问题如果通过saml实现，应该是有着很大实际意义的实现；如何通过这些实现对分布式用户或者资源的访问控制不是一个简单的问题，尤其在分布式策略的制定上也是一个需要通过一定机制划分的问题，关键在于这种策略的制定应该层次清楚和控制明确；
saml的应用prototype希望哪位lz能够提供一下？

SAML 国外，国内都已经在用了。。

实现请访问：http://www.opensaml.org/

         XACML3.0最近刚出来，是用来制定administration  and  delegation  of  XACML的，我的导师的观点，delegation是属于daministration的一部分。 
从上面的连接可以下载。。 

         若大家真的对XACML有兴趣，必须加入OASIS的mailing  lists，从上面那个连接加入。 

Sun什么事情都不落后，他针对XACML已经开发API了，基本上实现了XACML1.0的全部规范，2.0也差不多了，你需要从CVS里面下载，另外一点，SUN也有针对XACML实现的讨论的mailing  lists. 
Sun  implemenation  of  XACML的连接在这里： 
http://sunxacml.sourceforge.net/ 

         请问谁现在在看RB-XACML  profile，是否可以跟小弟讨论一下，里面的user-role  assignment如何来弄，如何将user-role  assignment,  role-permission  assignment整合起来。



         现在介绍一些SAML，SAML的全称是  SECURITY  ASSERTATION  MARKUP  LANGUAGE。他表示安全的信息传递以断言的形式表示。SAML的specification可以在下面的连接： 
http://www.oasis-open.org/committees/security/ 
和XACML一样，你最好也加入他们的user  mailing  lists来看别人提出的问题。我现在只简单说明一下SAML有什么用，详细的请看specification 

SAML实现单点登陆  
         单点登陆表示用户A在站点A认证登陆了，到用户到达站点B的时候自动登陆，不需要在站点B重新输入用户名和密码再次验证。如何做到这样呢，需要用SAML，站点B会向站点A发出SAML  的认证请求，站点A会回复站点B一个SAML认证断言，说明用户A在我站点A认证过了，而站点B信任站点A来的认证断言。所以。。。 

SAML在web  services中的应用  
         web  service-security，security的信息加在soap  head信息中，我们将安全信息用SAML表达，将SAML断言放在soap  head里面 

SAML在XACML结合使用  
         这个是我研究的东西，也是要做的。因为在分布式系统中，policies可能不在同一个地方，PEP和PDP可能是不同的domain或者application，XACML请求和决定等信息最好放在SAML中来传递，也就是SAML2.0  profile  of  XACML,大家可以去XACML官方网站下载（我在上面一提了XACML的连接了）。

在系统安全方面分为：身份认证和访问控制（权限管理）：  
         身份认证、单点登录方面的的技术规范或协议有Kerbos、SAML；  
         在访问控制（权限管理）有RBAC、ACL、XACML; 

我们已经讲这些技术进行整合，正在开发新的统一身份认证与权限管理系统。

　　Web 服务体系架构的关键是能够交付集成的、可互操作的解决方案。通过应用这个安全模型，确保 Web 服务的完整性、机密性和安全性，这对软件商和它们的客户来说都至关重要。将会出台的Web服务基本的安全规范包括：

　　用于整合的Web服务描述语言、用于认证和授权的安全性声明标记语言、用于渠道保密的安全槽层（SSL）、用于高度机密的XML加密标准和用于高级授权的XML数字签名。此外，其他几项规范也会陆续出台，包括：

　　Web服务安全性规范（包括XML-加密和XML-数字签名）、XML密钥管理规范和用于授权的可扩展访问控制标记语言规范等等。

　　为Web服务提供安全功能和组件的模型需要把现有的流程和技术与将来的应用程序的安全性需求集成起来。统一的安全技术就必须把应用程序对安全的需求从特定的机制中抽象出来。目的是让开发者能够容易地使用异类系统建立可互操作的安全解决方案。成功的Web服务安全方法需要一组灵活的、可互操作的基本元素，通过策略和配置，这些安全性基本元素可以使多种安全解决方案成为可行的方案。可行的Web服务安全性机制需要满足和包括下列组件的要求：

　　网络安全性

　　支持如SSL等提供机密性和完整性的安全传输机制。

　　XML消息安全性

　　1)XML数字签名，以便接收方可以证明消息发送方的身份。

　　2)XML加密，提供数据元素的机密性使能够验证交换。W3C发布XML密钥管理服务(XML Key Management Services，简称XKMS)的备忘录，帮助分发及管理在端点之间进行安全通信所需的密钥。

　　端点验证及授权

　　1)支持在企业之间交换信息的合同中定义哪些雇员可以使用哪些服务。中介体负责审计和服务原始性证明。

　　2)支持网络内部的、可信任的第三方验证服务，例如Kerberos。

　　安全性服务描述

　　1)描述是否支持数字签名、加密、验证和授权以及如何支持它们。Web服务请求者使用服务描述的安全性元素，来查找符合政策要求及其安全性方法的服务端点。

　　2)OASIS成立了一个技术委员会来定义授权和验证断言(Authorization and Authentication Assertions，简称SAML)，帮助端点接受和决断访问控制权。

　　3)OASIS同时成立了另一个技术委员会来标准化访问控制权的表达 (eXtensible Access Control Markup Language，简称XACML)，帮助端点能够以一致的方式解析SAML断言。

　　XML相关标准化团体"Organization for the Advancement of Structured Information Standards（OASIS）"的加盟企业成立了制定Web服务安全标准"Web Services Security（WS-Security）"的技术委员会"Web Services Security Technical Committee（WS-Security TC）"。这是OASIS于美国当地时间2002年7月23日宣布的。

　　WS-Security标准的目的是确保Web服务应用软件处理数据的完整性及保密性，规定了Web服务协议SOAP的扩展及消息头（Message Header）。这是由IBM、微软和VeriSign共同研究制定的。 WS-Security融合了多种安全模式、结构和技术，是面向Web服务的标准规格之一。各种系统可以通过平台及不依赖语言的方法确保相互兼容。

　　WS-Security 描述通过消息完整性、消息机密性和单独消息认证提供保护质量对 SOAP 消息传递的增强。这些机制可以用于提供多种安全性模型和加密技术。WS-Security 还提供关联安全性令牌和消息的通用机制。WS-Security 不需要特定类型的安全性令牌。它在设计上就是可扩展的（例如支持多安全性令牌格式）。举例来说，客户机可能会提供身份证明和他们有特定商业认证的证明。

　　另外，WS-Security 还描述如何对二进制安全性令牌编码。此规范特别描述如何对 X.509 证书和 Kerberos 票据编码以及如何加入难于理解的加密密钥。它还包括可以用于进一步描述消息中包含的凭证特征的扩展性机制。

　　WS-Security 很灵活，它被设计成用来构建多种安全性模型（包括 PKI、Kerberos 和 SSL）的基础。WS-Security 特别为多安全性令牌、多信任域、多签名格式和多加密技术提供支持。规范提供了三种主要的机制：安全性令牌传播、消息完整性和消息机密性。这些机制本身并不提供完整的安全性解决方案。相反，WS-Security 是一种构件，它可以与其它 Web 服务扩展和更高级的特定于应用程序的协议联合使用，以适应多种安全性模型和加密技术。这些机制可以独立使用（例如传送安全性令牌），或以紧密集成的方式使用（例如，对消息签名和加密，并提供与用于签名和加密的密钥相关的安全性令牌层次结构）。

　1、WS-Security及有关的规范

　　下面介绍一个能够满足真实企业的Web服务安全性需要的基于标准的体系架构。IBM、Microsoft和Verisign联手制定了有关Web服务安全性的计划和指南，用来开发一组提供保护Web服务安全性的规范。这个安全性模型把不同的安全性技术，比如公用密钥基础架构、Kerberos等集中在一起，以保证能够在现有的系统环境中构建安全的Web服务。通过利用Web服务模型核心处的自然可扩展性，这些规范建立在一些基础技术的基础之上，如SOAP、WSDL、XML数字签名(XML Digital Signature)、XML加密(XML Encryption)和SSL技术。这允许Web服务提供者和请求者开发满足他们应用程序的个别安全性需求的解决方案。这是一个由IBM、Microsoft和Verisign提议的WS-Security规范定义，用于保护消息完整性和机密性的核心工具，以及用于把有关安全性的声明与消息关联起来的机制。

　　目前，SSL、Transport Layer Security(TLS)和IPSec被用于为Web服务应用程序提供传输级别的安全性。它们的安全性功能包括认证、数据完整性和数据机密性，保证点对点Web服务安全性。Web服务应用程序是个多跳(Multi-Hop)拓扑，依赖于消息处理中介体转发消息。当传输层之外的中介体接收并转发数据时，数据的完整性和任何随数据流动的安全性信息都可能失去。所以，全面的Web服务安全性体系架构必须是一个提供端到端安全性的机制。

　　图1所示为提议的Web服务安全性规范组合。

图1 WEB 服务安全性规范组合

　　这组规范建立在SOAP标准规范上，包括一个WS-Security的消息安全性模型、一个描述Web服务端点策略的WS-Policy、一个WS-Trust信任模型和一个隐私权模型WS-Privacy。在这些规范的基础上，可以跨多个信任域创建安全的、可互操作的Web服务，还可以提供后继规范，例如安全会话WS-SecureConversation、联合信任WS-Federation和授权WS-Authorization。安全性规范、相关活动和互操作性概要文件组合在一起，将方便开发者建立可互操作的、安全的Web服务。下面简单描述被提议的各个规范：

　　WS-Security

　　描述如何向SOAP消息附加签名和加密报头，还描述如何向消息附加安全性 令牌，比如二进制安全性令牌的X.509证书和Kerberos票据。提供了一个通用机制把可扩展的安全性令牌与消息关联起来。使用XML签名和安全性令牌可以确保消息的完整性，消息在传输过程中未被修改。同样地，使用XML加密和安全性令牌可以使SOAP消息的一部分保密，提供消息机密性。

　　WS-Policy

　　描述中介体和端点上的安全性策略的能力和限制，比如所需的安全性令牌、 所支持的加密算法和隐私权规则。这是可扩展的，并且不会对可以描述的要求和能力的类型做什么限制，此规范识别几个基本的服务属性，包括隐私权属性、编码格式、安全性令牌要求和支持的算法。

　　WS-Trust

　　描述使Web服务能够安全地进行互操作的信任模型的框架。此规范描述如何 通过创建安全性令牌保证服务把现有的直接信任关系用作代理信任的基础。

　　这些安全性令牌保证服务建立在WS-Security的基础上，用一种保证令牌的完整性和机密性的方式传送那些必需的安全性令牌。

　　WS-Privacy

　　描述Web服务提供者和请求者如何声明主题隐私权首选项和组织隐私权实践声明的模型。通过使用WS-Policy、WS-Security和WS-Trust的组合，商业机构可以声明并指出遵守声明的隐私权策略。此规范描述一个关于如何把隐私权语言嵌入到WS-Policy的描述，以及如何使用WS-Security把隐私权声明与消息关联起来的模型，它还描述如何使用WS-Trust机制，同时为用户首选项和组织实践声明评价这些隐私权声明。

　　WS-SecureConversation

　　描述如何管理和认证各方之间的消息交换，包括安全性上下文交换以及建立 和派生会话密钥。

　　WS-Federation

　　描述如何管理和代理异类联合的环境中的信任关系，包括支持联合身份。此 规范定义如何使用WS-Security、WS-Policy、WS-Trust和WS-SecureConversation 规范构建联合信任案例，例如如何把Kerberos和PKI基础架构联合起来。

　　WS-Authorization

　　描述如何管理授权数据和授权策略，如何在安全性令牌内指定声明，以及这 些声明在端点处将如何被解释。此规范在授权格式和授权语言上是灵活且可 扩展的。

　　由于这个Web服务安全性模型与现今普遍使用的用于认证、数据完整性和数据机密性的现有安全性模型兼容，所以它可以把基于Web服务的解决方案与现有的其他安全性模型集成起来。例如，现有技术如SSL为消息提供简单的点对点完整性和机密性，而Web服务安全性模型支持把这些现有的安全传输机制与WS-Security和其他规范集成来提供跨多个中介体和传输协议的端到端完整性和机密性。Public Key Infrastructure(PKI)模型涉及到签发带公用对称密钥的证书的证书机构和声明除密钥所有权之外属性的机构。这种证书的拥有者可以使用相关的密钥来表示多种声明。另外，Kerberos模型依靠与密钥分发中心(Key Distribution Center)通信，通过签发加密的对称密钥来代理各方之间的信任。Web服务安全性模型支持安全性令牌服务使用公用不对称密钥签发安全性令牌。现有的信任模型通常都是基于企业间的协定，例如UDDI商业注册中心的Web服务。UDDI有多个参与者，它的信任模型不是根据特定认证机制的要求为信任定义一个单独的模型，而是把认证的责任交给每个节点的信息管理员。每个UDDI中的Web服务可能有自己的认证机制并强制遵守自己的访问控制策略，而信任取决于服务请求者和管理其信息的操作员之间的信任。

2、Web服务可靠性及SOAP层安全扩展

　　由富士通、日立、NEC、Oracle、Sonic软件和Sun等领先IT厂商宣布，它们将合作发布Web服务可靠性(Web Services Reliability)技术规范工作草案。这一WS-Reliability技术规范将通过提供一个更为可靠的传输基础设施，加快Web服务的采用，以适应企业界各种各样的应用需求。

　　WS-Reliability是一个针对开放的、可靠的Web服务讯息递交的技术规范，包括担保递交、复制讯息排除和讯息分类等，使各种Web服务之间得以进行更可靠的讯息传递。WS-Reliability基于SOAP协议，而不局限于基础传输协议。

　　自从SOAP规范从2001年发布以来，SOAP规范的加密性，认证和授权等安全机制一直受到人们的广泛关注。这三个方面对于任何的B2B来说都是很重要的 ，但SOAP标准在制定规范时并没有过多考虑SOAP 的安全性要求。因为SOAP一个很重要的设计目标就在于它的简单性，尽可能的利用已有的标准和协议来实现相应的功能。

　　SOAP安全的解决方案基于三个W3C的XML规范来实现：XML Digital Signature, XML encryption, and XML Key Management Services。SOAP层安全处于传输层和应用层之上，对SOAP层的安全性进行扩展，把关于安全的五个基本要求应用到整个的SOAP信息中，包括SOAP头以及SOAP体。同时，更多的安全措施也可结合SOAP层安全与传输层以及应用程序来共同解决。（如下图2）

      
图2 SOAP层安全扩展

　　1）SOAP 安全扩展: 数字签名 （Signature）

　　"SOAP Security Extensions: Digital Signature"最初设想是利用XML的数字签名（XML Digital Signature syntax [XML-Signature]）对SOAP进行扩展，在SOAP的头元素中定义签名属性（<SOAP-SEC:Signature>）来实现。

　　2）安全性令牌（Security Token） -定义安全性令牌表示与安全性相关的信息（例如，X.509 证书、Kerberos 票据和认证者、来自 SIM 卡的移动设备安全性令牌、用户名等等）。

　　SOAP规范在SOAP 1.1的头元素里定义了XML Signature 的使用，数字签名经过加密算法计算后的值附加在数据对象后面，数据接受对象从签名中可以验证数据的来源和完整性。加密后的传送信息可避免数据接受者受到伪造信息的蒙骗。虽然数字签名了提供这些安全服务:信息源的证明--信息的接受者可以确定这条信息的发出者的身份；信息的完整性---信息的接受者可以确定这条信息发出后没有被纂改；不可抵赖性---事物中的任何一方事后都不能否认他的行为。但是：数字签名没有提供信息认证，恶意破坏者可以记录一个信息并反复发送（重复攻击），为了避免受这种类型的攻击，数字签名必须结合一定的方法来保证信息的唯一性，如：时间戳（time stamps）或nonces 等。签名的日期和时间都附加在消息上,并与消息一起签名。添加这些信息可以在中加入扩展元素实现。当数字签名用来验证发送方的标识时，发送者必须提供一个私有秘钥等等。SOAP信息也可以使用其他安全技术，更多的SOAP安全规范正在不断的完善之中，随着SOAP安全性的增强，SOAP技术会得到越来越广泛的应用。

　　3) UDDI安全：识别与授权

　　使用UDDI的发布API的关键原则是只允许被授权的用户进行发布或修改UDDI商业注册中心中的数据。每一个分布式的UDDI商业注册中心维护-张唯-的授权用户列表，并跟踪所有用户创建的businessEntity或tModel数据。只有信息的创建者才允许对该信息进行更改或删除。

　　每个UDDI商业注册中心的实例被称为一个操作入口站点(Operator Site)，操作入口站点被允许定义他自己的用户授权机制，不过所有的签署协议的公共的UDDI注册中心操作入口站点都需要满足规定协议中定义的最小安全规范以提供类似的安全机制。

简介

         WSS、SAML和XACML之间有许多共性。或许最明显的就是它们都使用XML表示信息。其次是，因为这三种可用的安全服务都已经在计算机系统中应用多年了，为了更加适用于大型分布式环境，如互联网，它们都具有一些特定的功能。此外，三者都参考并结合了现有的安全性标准，并尽量减少对已有功能的重复。

         两个主要原因促使三者都采用了XML技术。第一，XML使它们便于扩展，以便可以以一种原有格式无法实现的方式来满足某种特殊需求。第二，XML支持采用大量可用的软件工具进行处理的实现。对于WSS来说，还有一个原因，即，WSS被设计为支持与SOAP的语法和处理模型进行紧密集成，而SOAP是用XML定义的。

SAML

         授权和审计跟踪是常见的安全服务。以前，大多数系统设计时都假设做出访问控制决定所必需的所有信息都由单个系统来处理，并且所有要记录的数据都放在审计跟踪中。但是，大规模分布式系统通常是由多个组织使用各种产品建立的。这意味着用户可能要由不同的验证方使用不同的方法进行验证。此外，不同的验证方还要保存有关用户特性和属性的不同信息。集中管理所有这些能力和信息是不现实的。SAML提供了标准格式来表示身份验证、用户属性以及请求和接受该标准的协议。这被称为身份联盟（Identity Federation）。

         在OASIS的最初开发阶段，SAML只指定了该身份信息的生产者与消费者之间的通信。SAML定义了如何创建有关用户属性和身份验证事件的断言，以及如何以一种灵活而可扩展（以便满足其它需求）的方式获得这些信息。SAML还详细定义了一些常见场景（如：Web单点登录）来确保互操作性。

         Liberty Alliance Project和Internet2 Shiboleth group进一步地增强和扩展了SAML。增加了许多新功能，以便支持SAML验证方之间的通信，更加详细地描述身份验证方法，注销用户并保护隐私。这些工作又提交给OASIS，并合并到SAML2.0中，SAML2.0在2005年3月成为一个OASIS标准。SAML被设计为用于多种不同的环境，支持使用不同的身份验证和加密方法。它支持各种不同的消息流，甚至可以用于不使用XML的遗留环境中。

XACML

         XACML，也是由OASIS开发的，是一种表示访问控制策略的语言。大多数计算机专业人士都熟悉基于权限或访问控制列表（ACL）的访问控制。但是，这些机制缺少表示复杂策略（在现实系统中经常需要用到）的能力。因此，访问控制策略通常会嵌入应用程序代码中。这使得更改策略（或者只是找出哪些策略正在实施）变得很困难。

         XACML能够实际地使用任何可用的信息来决定是否该许可对一个资源的访问。也可以关联附加的动作、被调用的契约和决定，例如，要求请求的数据在90天后删除。

         XACML可以根据资源的属性做出决定，包括资源的内容或环境因素，如日期、时间或位置。它也会考虑到与请求关联的各方的特性，比如角色或组成员关系。这可能不只包括请求方，还包括其他方，比如接受数据方或请求中转方。

         XACML 2.0在2005年2月成为一个OASIS标准。它在具有多个创建策略的管理员的大规模环境中运行良好。因为SAML可用于任何访问控制系统，XACML可以与SAML一起使用，或者单独使用。有专门的支持它们一起工作的特性。

WSS

         WSS指定了如何保护通过网络传递的SOAP消息。它包括身份验证、完整性保护和保密性。它没有指定如何实现访问控制，但提供了可以用于访问控制的信息。在WSS出现之前，最常见的保护消息的方法是使用SSL或TLS协议。这些协议仍然适用于许多应用程序，但WSS提供了更多的功能和灵活性。

         SSL和TLS是对整个消息进行加密，而WSS允许有选择性地实现加密。例如，它允许应用程序防火墙检查没有加密的部分。此外，WSS还支持复杂的多方交互，这是处理复杂的电子商务事务所需要的。

         此外，WSS在基础架构选择方面提供了更大的灵活性。同SSL和TLS一样，它也支持X.509技术，还可以使用Kerberos、SAML或以前的普通用户名和密码。因为WSS作用于SOAP层，在信息在网络上传输甚至在对消息进行排队或存储时，它都能发挥作用。

         WSS采用W3C所开发的XML数字签名（XML Digital Signature）和XML加密（XML Encryption）标准。WSS通过将称为Security的XML元素插入SOAP标题中而发挥作用。其中包含所有有关应用于消息的身份验证、数字签名和加密的信息。它向接受方提供解密和验证消息所需的信息。密钥和身份验证信息可以使用X.509证书、Kerberos ticket、SAML断言或其他方法进行定义。

         2004年，WSS 1.0成为一个OASIS标准。现在，WSS 1.1就要完成了。由于WSS所提供的灵活性，不同产品间的互操作可能会比较困难。为了解决这个问题，Web Services Interoperability Organization组织(WS-I)正在开发一个配置文件，以便减少可变性，并给出使用WSS（以及SSL和TLS）的最佳实践。这个Basic Security Profile (BSP)的草案已经公布，并预计于2006年初完成。WS-I成员还构建了一个示例应用程序来说明WSS和测试工具（可以检查消息是否服从BSP）的正确使用。

结束语

         上面介绍的三个安全性标准在设计时就被赋予了极大的灵活性，这是通过使用XML而实现的。SAML和XACML在几乎所有的环境中都支持身份验证服务，但更适用于大规模分布式系统。在SOAP环境中，WSS提供了明确的消息保护，但是在软件基础架构方面，它提供了很多选择。有XML作为其共同的基础，这三个标准可以有效地共同使用，或者也可以单独使用。