XML 已成为一种用于在因特网上交流数据的有价值机制。SOAP，这类发送 XML 音讯的体式格局，促使历程以一种亘古未有的体式格局互相通讯，而 UDDI 看起来正在疾速成为整合 Web 效劳的供应商和用户的范例；效劳自身是 XML 以 WSDL （即“Web 效劳形貌言语”）情势形貌的。假如没有 XML，将不可以有这类灵活性和才能，而且，正如许多人所说的，将有必要发现元言语。
安全性范畴是另一个疾速增长的范畴。在差别团体之间竖立信托的传统要领在大众因特网上已不适宜，现实上，在大型 LAN 和 WAN 上也不适宜。在这些状况下，基于非对称暗码术的信托机制可以会异常有用，但现实上，布置和密钥治理的方便性、互操纵性的局限和供应的安全性远不如种种的“公钥基础设施”（Public Key Infrastructures (PKI)）的热忱的供应商曾让我们置信的那样。处置惩罚条理数据构造，以及带有秘要、接见权限或完整性等差别需求的数据的子集迥殊难题。别的，具有差别于 XML 文档的当今范例安全性掌握的应用程序一点都不简朴。
如今，一些团体正主动投身于搜检这些题目和开辟范例的运动中。个中重要的相干开辟是 XML 加密和相干的 XML 署名、“可扩大接见掌握言语（XACL）”和相干的“安全性断言标记言语（SAML — 之前是互为竞争对手的 AuthML 和 S2ML 的连系）”。一切这些都由 OASIS 和“XML 密钥治理范例（XKMS）”驱动。本文将 引见 XML 加密和 XML 署名。
“XML 安全性套件”
部份原因是由于这些范例仍处于发展阶段，因此，开辟职员可用的东西集和库的数目依然有限，但非常确信的一点是，这正在最先发作变化。IBM 已向“Java 社区历程（JCP）”提交了两种相干的“Java 范例请求（JSR）”。它们是 JSR-105、“XML 数字署名 API”和 JSR-106、“数字加密 API”。
“IBM 东京研讨实验室”在 1999 年开辟了“XML 安全性套件”作为 XML 署名的原型完成。它包含一些自动生成 XML 数字署名、完成 W3C 的“范例”XML 事变草案，以及经由过程 XML 加密的实验性完成来供应元素级加密的实用程序。它还供应一种在应用到 XML 文档时处置惩罚安全性特定请求的体式格局。还引入了“可扩大接见掌握言语（XACL）”的 XML 形式定义。
developerWorks 有一篇 Doug Tidwell 著的文章细致报告了该套件，可在 alphaWorks 站点获得该套件的最新版本。（请参阅参考资料。）
XML 加密和 XML 署名
象别的任何文档一样，可以将 XML 文档整篇加密，然后安全地发送给一个或多个接收方。比方，这是 SSL 或 TLS 的罕见功用，然则更使人感兴趣的是怎样对统一文档的差别部份举行差别处置惩罚的状况。XML 的一个有价值的优点是可以将一整篇 XML作为一个操纵发送，然后在本地保留，从而减少了收集通讯量。然则，这就带来了一个题目：怎样掌握对差别元素组的受权检察。商家可以须要晓得客户的称号和地点，然则，无需晓得任何正在运用的信用卡的种种细致信息，就像银行不须要晓得购置货色的细致信息一样。可以须要防备研讨职员看到有关个人医疗纪录的细致信息，而治理职员可以恰好须要那些细致信息，然则应当防备他们检察医疗汗青；而大夫或护士可以须要医疗细致信息和一些（但不是悉数）个人资料。
暗码术如今所做的远远不止隐蔽信息。音讯择要肯定文本完整性，数字署名支撑发送方认证，相干的机制用于确保任何一方往后没法谢绝有用事件。这些都是长途生意业务必不可少的元素，如今，用于处置惩罚全部文档的机制开辟得相当好。
有了平常的加密，对 XML 文档团体举行数字化署名不是题目。但是，当须要对文档的差别部份（可以由差别的人）署名，以及须要与选择性的要领一同来如许做时，就会涌现难题。或许不可以或许不值得强迫差别部份的加密事变由特定职员按特定递次举行，但是成功地处置惩罚文档的差别部份将取决于是不是晓得这点。另外，由于数字署名断言已运用了特定专用密钥来认证，所以要警惕署名人是以纯文本情势检察文档项的，这可以意味着对由于别的原因此加密的部份内容举行了解密。在另一种状况下，作为更大鸠合中的一部份，可以对已加密过的数据举行进一步加密。在牵扯单一 XML 文档（可以由一些差别的应用程序和差别的用户处置惩罚在事变流序列中运用的 Web 表单或一系列数据）的事件集合斟酌的差别可以性越多，就越可以看到庞大的潜伏复杂性。
另有别的题目。XML 言语的刚强之一是，搜刮是明白的，无二义性的：DTD 或 Schema 供应了相干语法的信息。假如将包含标记在内的文档的一部份作为团体加密，就会损失搜刮与那些标记相干的数据的才能。另外，假如标记自身被加密，那末一旦走漏，它们将被应用对采纳的暗码术举行纯文本进击。
这些是事变组正在斟酌的一些方面。
XML 加密示例
XML 加密语法的中心元素是 EncryptedData 元素，该元素与 EncryptedKey 元素一同用来将加密密钥从提议方传送到已知的接收方，EncryptedData 是从 EncryptedType 笼统范例派生的。要加密的数据可以是恣意数据、XML 文档、XML 元素或 XML 元素内容；加密数据的效果是一个包含或援用暗码数据的 XML 加密元素。当加密元素或元素内容时，EncryptedData 元素替代 XML 文档加密版本中的该元素或内容。当加密的是恣意数据时，EncryptedData 元素可以成为新 XML 文档的根，或许可以成为一个子代元素。当加密全部 XML 文档时，EncryptedData 元素可以成为新文档的根。另外，EncryptedData 不能是另一个 EncryptedData 元素的父代或子代元素，然则现实加密的数据可以是包含现有 EncryptedData 或 EncryptedKey 元素的任何内容。
加密事变草案给出了一些示例来演示：加密的颗粒度怎样依据请求的差别而差别，以及可以涌现什么效果。清单 1 中的代码片段显现了带有信用卡和别的个人信息的未加密 XML 文档。在某些状况下（比方，隐蔽付出机制的信息），可以愿望加密除客户称号以外的一切信息，清单 2 的代码片段演示了怎样如许做。
清单 1. 显现 John Smith 的银行帐户、5000 美圆限额、卡号和有用期的的信息
<PaymentInfo xmlns='http://example.org/paymentv2'>
<Name>John Smith<Name/>
<CreditCard Limit='5,000' Currency='USD'>
<Number>4019 2445 0277 5567</Number>
<Issuer>Bank of the Internet</Issuer>
<Expiration>04/02</Expiration>
</CreditCard>
</PaymentInfo>
清单 2. 除称号以外悉数被加密的加密文档
<PaymentInfo xmlns='http://example.org/paymentv2'>
<Name>John Smith<Name/>
<EncryptedData Type='http://www.w3.org/2001/04/xmlenc#Element'
xmlns='http://www.w3.org/2001/04/xmlenc#'>
<CipherData><Ciphervalue>A23B45C56</Ciphervalue></CipherData>
</EncryptedData>
</PaymentInfo>
然则，在别的状况下，可以只须要隐蔽一些敏感内容 — 可以来自商家或别的第三方 — 清单 3 演示了这点。（请注意，显现了与加密内容相干的标记名。）
清单 3. 只隐蔽了信用卡号的加密文档
<PaymentInfo xmlns='http://example.org/paymentv2'>
<Name>John Smith<Name/>
<CreditCard Limit='5,000' Currency='USD'>
<Number>
<EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'
Type='http://www.w3.org/2001/04/xmlenc#Content'>
<CipherData><Ciphervalue>A23B45C56</Ciphervalue>
</CipherData>
</EncryptedData>
</Number>
<Issuer>Bank of the Internet</Issuer>
<Expiration>04/02</Expiration>
</CreditCard>
</PaymentInfo>
可以另有必要加密文档中的一切信息，清单 4 演示了这点。
清单 4. 隐蔽了悉数内容的加密文档
<EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'
Type='http://www.isi.edu/in-notes/iana/assignments/media-types/text/xml'>
<CipherData><Ciphervalue>A23B45C56</Ciphervalue></CipherData>
</EncryptedData>
CipherData 可以封装，也可以援用原始加密数据。在第一种状况下，Ciphervalue 元素的内容显现原始数据，而在第二种状况，运用 CipherReference 元素，这包含了一个指向加密数据位置的 URI。
范例的 XML
对应用了暗码散列算法的音讯举行最细微的变动也会发作差别的值。这为音讯完整性方面供应了信托，并适于一般用法，然则也引入了进一步的复杂性 — 两个 XML 文档虽然在逻辑上相称，但可以在确实文本比较中差别。象行定界符、空标记、在属性中运用十六进制而不是称号以及在特定状况下存在诠释或诠释变体如许的事变都可以成为文档的逻辑构造不受影响而现实相互差别的实例。范例的 XML 范例形貌了一种生成文档的物理示意（也成为范式）的要领，该范式诠释许可的变体，以便假如两个文档具有统一范式，则以为两个文档在给定应用程序高低文中是逻辑相称的。
关于加密、迥殊是数字署名来讲，这尤为重要，由于很明显，逻辑上雷同的文本变体不应当示意文档的完整性及其发送方的认证是可疑的。用差别东西（比如，解析器）生成差别文本（并因此生成差别音讯择要）举行处置惩罚时也可以发作如许的事。因此，在生成署名和考证盘算时期，应当在范式上举行音讯择要。假如择要婚配，这将肯定：纵然文本情势可以差别，它们在其上盘算的范式也婚配。
XML 署名示例
可以将 XML 署名应用到恣意数据内容。那些应用到雷同 XML 文档中数据的署称号为封装或被封装的署名，而那些数据在署名元素外部的署称号为 星散署名。清单 5 取自署名候选引荐文档，它是一个简朴星散署名的实例。
清单 5. 一个简朴星散署名的示例
[s01] <Signature Id="MyFirstSignature"
xmlns="http://www.w3.org/2000/09/xmldsig#">
[s02] <SignedInfo>
[s03] <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/
REC-xml-c14n-20010315"/>
[s04] <SignatureMethod Algorithm="http://www.w3.org/2000/09/
xmldsig#dsa-sha1"/>
[s05] <Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/">
[s06] <Transforms>
[s07] <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-
20010315"/>
[s08] </Transforms>
[s09] <DigestMethod Algorithm="http://www.w3.org/2000/09/
xmldsig#sha1"/>
[s10] <Digestvalue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</Digestvalue>
[s11] </Reference>
[s12] </SignedInfo>
[s13] <Signaturevalue>MC0CFFrVLtRlk=</Signaturevalue>
[s14] <KeyInfo>
[s15a] <Keyvalue>
[s15b] <DSAKeyvalue>
[s15c] <p></p><Q></Q><G></G><Y></Y>
[s15d] </DSAKeyvalue>
[s15e] </Keyvalue>
[s16] </KeyInfo>
[s17] </Signature>
现实署名的信息是位于 s02 行和 s12 行之间，即 SignedInfo 元素。在署名的部份中包含用于盘算 Signaturevalue 元素的算法的援用，而谁人元素自身位于署名部份以外（在 s13 行上）。s04 行上的 SignatureMethod 援用的是将范例的 SignedInfo 转换成 Signaturevalue 所用的算法。它是密钥相干的算法和择要算法（在这里是 DSA 和 SHA-1）的组合，可以还具有象添补如许的操纵。KeyInfo 元素（在这里位于 s14 行和 s16 行之间 — 该元素是可选的）指出用来考证署名的密钥。
转换
正如前面所提到的，加密、署名、修正和可以举行的更多署名所发作的递次有很多种可以性。用户可以须要向已部份加密或部份署名的表单字段中输入更多数据，而且须要可以在不阻碍今后的考证和解密的前提下如许做。为处理这类状况，W3C 近来宣布了一个有关 XML 署名的解密转换事变草案。（请参阅参考资料。）
下面这个示例摘自谁人文档，它演示了怎样发起文档接收方采纳准确的解密和署名考证递次。第一个代码段显现了要署名的文档部份 — order 元素；个中，第 7 行到第 11 行的 cardinfo 元素是关于个人和财务方面的细致信息，它是纯文本，但也存在一些加密数据（第 12 行）。
清单 6. XML 文档中的 order 元素
[01] <order Id="order">
[02] <item>
[03] <title>XML and Java</title>
[04] <price>100.0</price>
[05] <quantity>1</quantity>
[06] </item>
[07] <cardinfo>
[08] <name>Your Name</name>
[09] <expiration>04/2002</expiration>
[10] <number>5283 8304 6232 0010</number>
[11] </cardinfo>
[12] <EncryptedData Id="enc1"xmlns="http://www.w3.org/
2001/04/xmlenc#"></EncryptedData>
[13] </order>
清单 7. 经由署名和进一步加密、且如今显现转换信息的 order 文档
[01] <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
[02] <SignedInfo>
[03]
[04] <Reference URI="#order">
[05] <Transforms>
[06] <Transform Algorithm="http://www.w3.org/2001/04/
xmlenc#decryption">
[07] <DataReference URI="#enc1"
xmlns="http://www.w3.org/2001/04/xmlenc#"/>
[08] </Transform>
[09] <Transform Algorithm="http://www.w3.org/TR/2000/
CR-xml-c14n-20001026"/>
[10] </Transforms>
[11]
[12] </Reference>
[13] </SignedInfo>
[14] <Signaturevalue></Signaturevalue>
[15] <Object>
[16] <order Id="order">
[17] <item>
[18] <title>XML and Java</title>
[19] <price>100.0</price>
[20] <quantity>1</quantity>
[21] </item>
[22] <EncryptedData Id="enc2"
xmlns="http://www.w3.org/2001/04/xmlenc#"></EncryptedData>
[23] <EncryptedData Id="enc1"
xmlns="http://www.w3.org/2001/04/xmlenc#"></EncryptedData>
[24] </order>
[25] </Object>
[26] </Signature>
第 1 行到 第 26 行的 Signature 元素如今包含前面的 order 元素（位于第 16 行到第 24 行），和之前的加密纯文本 cardinfo（显现在第 22 行这一行中）。有两个转换援用：解密（第 6 行到第 8 行）和范例化（第 9 行）。解密转换指点署名考证器解密除 DataRef 元素中第 7 行指定的数据以外的一切加密数据。解密了第 22 行中的 EncryptedData 元素以后，范例化 order 元素而且恰本地考证署名。
别的相干言语和范例
隐蔽 XML 文档中的敏感信息、竖立完整性以及认证这些文档的差别部份的泉源重要经由过程遵照加密和署名范例中列出的步骤来处置惩罚的，在援用的 W3C 草案中形貌该范例（请参阅参考资料）。别的，另有别的严密相干的范畴，比方认证用户或体系、标识受权级别和治理密钥，一切这些都与 XML 安全性相干。
SAML 是一个由 OASIS 驱动的模子，它尝试融会互相竞争的 AuthML 和 S2ML 范例，使认证和受权信息的交换便于举行。“可扩大接见掌握标记言语”是与 SAML 严密相干的，但它更着重于特定 XML 文档的高低文中的面向主题特权对象的安全性模子，它也由 OASIS 指点，又是被称为 XACML 或 XACL（纵然在统一些文档中）。经由过程用 XACL 编写划定规矩，战略制定者可以定义，关于特定 XML 文档和前面所述的状况中的相干事变，由谁来实行哪些接见特权。
关于SAML的细致内容,我将在下一篇Blog内报告.
以上就是XML加密和XML署名简介的详细引见的细致内容，更多请关注ki4网别的相干文章！
