SOAP头中的认证信息？如何传递令牌？-XML/RSS教程-PHP中文网

SOAP头中的认证信息？如何传递令牌？

月夜之吻

发布： 2025-08-26 13:52:01

原创

414人浏览过

SOAP头是传递认证信息的首选方式，因其遵循关注点分离原则，通过WS-Security规范在<wsse:Security>元素中嵌入令牌（如UsernameToken、SAML、X.509证书等），实现认证、完整性与机密性。

soap头中的认证信息？如何传递令牌？

SOAP头，毫无疑问，是传递认证信息的首选和标准实践，尤其是在需要传递令牌（Token）时。它提供了一种与消息体内容分离、灵活且可扩展的机制来承载安全上下文，确保了认证信息能够被独立的、统一的方式处理。

解决方案 在SOAP通信中，将认证信息（特别是令牌）放置在SOAP头中，最常见且标准化的做法是遵循WS-Security（Web Services Security）规范。这个规范定义了一个XML结构，允许你在SOAP信封的

Header

登录后复制

部分插入一个

<wsse:Security>

登录后复制

元素。这个

Security

登录后复制

元素就是各种认证令牌、数字签名和加密信息的大本营。

比如，一个非常普遍的场景是使用

UsernameToken

登录后复制

来传递用户名和密码。它允许你以明文、摘要（digest）或加密的形式传递凭据。当然，出于安全考虑，明文传输是绝对不推荐的，通常会使用摘要（密码哈希）或通过TLS/SSL加密整个传输通道。

以下是一个简化的SOAP头结构示例，展示了如何嵌入一个

UsernameToken

登录后复制

：

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
               xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
    <soap:Header>
        <wsse:Security soap:mustUnderstand="1">
            <wsse:UsernameToken wsu:Id="UsernameToken-1">
                <wsse:Username>myUser</wsse:Username>
                <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">myPassword</wsse:Password>
                <!-- 或者使用摘要方式：
                <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest">
                    [Base64EncodedDigest]
                </wsse:Password>
                <wsse:Nonce EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">
                    [Base64EncodedNonce]
                </wsse:Nonce>
                <wsu:Created>[Timestamp]</wsu:Created>
                -->
            </wsse:UsernameToken>
        </wsse:Security>
    </soap:Header>
    <soap:Body>
        <!-- 你的业务消息内容 -->
    </soap:Body>
</soap:Envelope>

登录后复制

这段XML清晰地展示了认证信息如何与实际的业务数据（

soap:Body

登录后复制

中的内容）解耦。

soap:mustUnderstand="1"

登录后复制

属性告诉接收方，如果它不理解或无法处理这个安全头，就应该拒绝处理整个消息，这对于强制执行安全策略至关重要。

为什么SOAP头是传递认证信息的理想选择？

在我看来，SOAP头之所以成为传递认证信息的“默认选项”，主要有几个深层原因。它首先遵循了“关注点分离”的原则。业务逻辑和数据是消息体的主要内容，而安全、事务、路由等非业务性功能则被巧妙地放在了头部。这使得服务设计更加清晰，也方便了中间件（如ESB、API网关）对消息进行拦截、处理和转发，而无需触及或解析业务数据。

想象一下，如果认证信息也塞在消息体里，每次服务提供方都要去解析特定的业务字段来提取凭据，这不仅增加了耦合度，也让安全策略的实施变得复杂且不统一。SOAP头提供了一个标准化的容器，让所有与消息本身内容无关但又对消息处理至关重要的信息，都有了一个归宿。此外，WS-Security规范正是基于SOAP头的设计，它提供了一整套成熟、可互操作的标准，这在企业级应用中尤为重要。

SOAP安全（WS-Security）标准是如何工作的？

WS-Security，说白了，就是一套XML扩展，它定义了如何在SOAP消息中集成安全功能。这不仅仅是传递一个用户名密码那么简单，它涵盖了认证、授权、消息完整性（通过数字签名）和消息机密性（通过加密）等多个方面。它的核心在于

<wsse:Security>

登录后复制

这个元素，所有与安全相关的子元素都嵌套在其中。

具体来说，WS-Security通过几种关键机制工作：

Poe

Quora旗下的对话机器人聚合工具

607

查看详情

安全令牌（Security Tokens）：这是认证信息的载体。最常见的包括
```
UsernameToken
```
登录后复制
（用户名/密码）、
```
BinarySecurityToken
```
登录后复制
（通常用于承载X.509证书）、以及
```
SAML Token
```
登录后复制
（基于SAML断言的令牌）。这些令牌告诉服务“我是谁”或者“我有什么权限”。
数字签名（Digital Signatures）：通过XML数字签名标准，WS-Security允许对SOAP消息的特定部分（或整个消息）进行签名。这能确保消息在传输过程中没有被篡改，并验证消息的发送者身份（不可否认性）。这就像给消息盖了个戳，证明它来自某个特定的人，且内容未被动过。
消息加密（Message Encryption）：同样基于XML加密标准，WS-Security可以加密SOAP消息的敏感部分，甚至整个消息体，以保护数据在传输过程中的机密性，防止未经授权的访问。

例如，当你发送一个带有

UsernameToken

登录后复制

的SOAP请求时，客户端会根据WS-Security规范构建这个安全头，可能还会计算密码的摘要（如果配置了）。服务接收到消息后，会通过支持WS-Security的框架（比如Java的Apache WSS4J或.NET的WCF）解析

Security

登录后复制

头，提取

UsernameToken

登录后复制

，然后根据配置的策略（比如，与用户数据库比对用户名和摘要）来验证请求者的身份。这个过程是高度自动化的，开发者通常只需要配置相应的安全策略。

除了UsernameToken，SOAP头还能承载哪些类型的认证令牌？

UsernameToken

登录后复制

确实是入门级且最直观的认证方式，但SOAP头的灵活性远不止于此。在企业级或更复杂的场景中，你可能会遇到其他几种重要的令牌类型：

SAML Token (Security Assertion Markup Language)：这是一种基于XML的标准，用于在不同的安全域之间交换认证和授权数据。当你的服务需要与身份提供者（IdP）集成，或者需要实现单点登录（SSO）时，SAML Token就非常有用。一个典型的流程是，用户首先向IdP认证，IdP返回一个SAML断言（通常是XML格式），然后客户端将这个SAML断言作为
```
SAML Token
```
登录后复制
嵌入到SOAP消息的
```
Security
```
登录后复制
头中发送给服务。服务再验证这个SAML断言的有效性。它提供了更强大的联邦身份管理能力。
X.509 Certificate Token (BinarySecurityToken)：这种令牌直接将X.509数字证书嵌入到SOAP头中。证书本身包含了公钥和身份信息。当使用X.509证书进行认证时，通常会结合数字签名。客户端用其私钥对消息签名，并将证书（或其引用）放入
```
BinarySecurityToken
```
登录后复制
中。服务接收后，用证书中的公钥验证签名，从而确认发送者的身份。这提供了非常高的安全级别，常用于B2B集成或需要强身份验证的场景。
Kerberos Token (BinarySecurityToken)：在Windows域环境中，Kerberos是一种常见的认证协议。WS-Security也支持将Kerberos票据作为
```
BinarySecurityToken
```
登录后复制
嵌入到SOAP消息中进行认证。这使得SOAP服务能够无缝集成到现有的Kerberos基础设施中。
自定义令牌：虽然有标准规范，但在某些特定业务需求下，你可能需要设计自己的令牌格式。只要客户端和服务端都约定好如何生成、解析和验证这种自定义令牌，理论上它也可以通过SOAP头传递。但这通常不推荐，因为它会牺牲互操作性，增加开发和维护的复杂性。只有在确实没有标准能满足需求，且能接受这种权衡时，才应该考虑。