WS-Security2004: SOAP消息安全1.1规范

需积分: 9 40 浏览量更新于2024-08-01 收藏 266KB PDF 举报

"wss-v1.1-spec-os-SOAPMessageSecurity" 《WSS:SOAPMessageSecurity 1.1 (WS-Security 2004)》是2006年2月由OASIS（Organization for the Advancement of Structured Information Standards）发布的Web服务安全标准，其OASIS标识为wss-v1.1-spec-os-SOAPMessageSecurity。这个规范旨在增强SOAP消息的安全性，提供消息完整性和机密性，适用于多种安全模型和加密技术。此规范的核心目标是通过引入一系列机制来保护Web服务之间的通信。这些机制包括但不限于数字签名、消息加密以及安全令牌的使用，确保消息在传输过程中的不可篡改性和隐私性。此外，规范还定义了一种通用方法，用于将安全令牌与消息内容关联，允许使用各种不同类型的安全令牌，设计上具有可扩展性，以支持未来的安全需求和技术发展。具体来说，WS-Security 2004包含了以下几个关键概念： 1. **数字签名**：用于验证消息的完整性和来源。通过在SOAP消息中添加一个签名元素，接收方可以检查签名，确保消息在传输过程中未被修改，并确认发送者的身份。 2. **消息加密**：保护敏感信息不被未经授权的第三方读取。这可以通过对整个SOAP消息或者消息的部分内容进行加密实现，确保数据在传输过程中的保密性。 3. **安全令牌**：这些令牌可以是X.509证书、 Kerberos票据或者其他形式的身份凭证，用于认证参与Web服务交互的实体。规范提供了将这些令牌附加到消息上的方式，以供接收方验证发送方的身份。 4. **头元素扩展**：WS-Security定义了一系列XML头元素，如`wsse:Security`，这些元素包含了安全相关的属性和信息，如签名、加密和令牌等。 5. **处理规则**：规范定义了如何解析和处理这些安全头元素的规则，以及在什么情况下消息应该被视为无效或不安全。 6. **互操作性**：WS-Security 2004的设计考虑了不同平台和实现之间的互操作性，确保遵循该标准的不同系统可以顺利通信。编辑团队包括来自IBM的Anthony Nadalin、Microsoft的Chris Kaler和Ronald Monzillo（Sun Microsystems），以及Verisign的Phillip Hallam-Baker，他们共同推动了这个标准的制定和实施。 WSS:SOAPMessageSecurity 1.1（WS-Security 2004）是一个重要的Web服务安全框架，它为保护Web服务通信提供了坚实的基础，促进了Web服务在不同组织和平台间的安全互操作。这一标准的发布对于确保企业间基于Web服务的数据交换安全性和可靠性至关重要。

WSS: SOAP Message Security (WS-Security 2004) 1 February 2006

3 Message Protection Mechanisms 348

When securing SOAP messages, various types of threats should be considered. This includes, 349

but is not limited to: 350

351

• the message could be modified or read by attacker or 352

• an antagonist could send messages to a service that, while well-formed, lack appropriate 353

security claims to warrant processing 354

• an antagonist could alter a message to the service which being well formed causes the 355

service to process and respond to the client for an incorrect request. 356

357

To understand these threats this specification defines a message security model. 358

3.1 Message Security Model 359

This document specifies an abstract message security model in terms of security tokens 360

combined with digital signatures to protect and authenticate SOAP messages. 361

362

Security tokens assert claims and can be used to assert the binding between authentication 363

secrets or keys and security identities. An authority can vouch for or endorse the claims in a 364

security token by using its key to sign or encrypt (it is recommended to use a keyed encryption) 365

the security token thereby enabling the authentication of the claims in the token. An X.509 [X509] 366

certificate, claiming the binding between one’s identity and public key, is an example of a signed 367

security token endorsed by the certificate authority. In the absence of endorsement by a third 368

party, the recipient of a security token may choose to accept the claims made in the token based 369

on its trust of the producer of the containing message. 370

371

Signatures are used to verify message origin and integrity. Signatures are also used by message 372

producers to demonstrate knowledge of the key, typically from a third party, used to confirm the 373

claims in a security token and thus to bind their identity (and any other claims occurring in the 374

security token) to the messages they create. 375

376

It should be noted that this security model, by itself, is subject to multiple security attacks. Refer 377

to the Security Considerations section for additional details. 378

379

Where the specification requires that an element be "processed" it means that the element type 380

MUST be recognized to the extent that an appropriate error is returned if the element is not 381

supported. 382

3.2 Message Protection 383

Protecting the message content from being disclosed (confidentiality) or modified without 384

detection (integrity) are primary security concerns. This specification provides a means to protect 385

a message by encrypting and/or digitally signing a body, a header, or any combination of them (or 386

parts of them). 387

WSS: SOAP Message Security (WS-Security 2004) 1 February 2006

388

Message integrity is provided by XML Signature [XMLSIG] in conjunction with security tokens to 389

ensure that modifications to messages are detected. The integrity mechanisms are designed to 390

support multiple signatures, potentially by multiple SOAP actors/roles, and to be extensible to 391

support additional signature formats. 392

393

Message confidentiality leverages XML Encryption [XMLENC] in conjunction with security tokens 394

to keep portions of a SOAP message confidential. The encryption mechanisms are designed to 395

support additional encryption processes and operations by multiple SOAP actors/roles. 396

397

This document defines syntax and semantics of signatures within a <wsse:Security> element. 398

This document does not constrain any signature appearing outside of a <wsse:Security> 399

element. 400

3.3 Invalid or Missing Claims 401

A message recipient SHOULD reject messages containing invalid signatures, messages missing 402

necessary claims or messages whose claims have unacceptable values. Such messages are 403

unauthorized (or malformed). This specification provides a flexible way for the message producer 404

to make a claim about the security properties by associating zero or more security tokens with the 405

message. An example of a security claim is the identity of the producer; the producer can claim 406

that he is Bob, known as an employee of some company, and therefore he has the right to send 407

the message. 408

3.4 Example 409

The following example illustrates the use of a custom security token and associated signature. 410

The token contains base64 encoded binary data conveying a symmetric key which, we assume, 411

can be properly authenticated by the recipient. The message producer uses the symmetric key 412

with an HMAC signing algorithm to sign the message. The message receiver uses its knowledge 413

of the shared secret to repeat the HMAC key calculation which it uses to validate the signature 414

and in the process confirm that the message was authored by the claimed user identity. 415

416

(001) <?xml version="1.0" encoding="utf-8"?> 417

(002) <S11:Envelope xmlns:S11="..." xmlns:wsse="..." xmlns:wsu="..." 418

xmlns:ds="..."> 419

(003) <S11:Header> 420

(004) <wsse:Security 421

xmlns:wsse="..."> 422

(005) <wsse:BinarySecurityToken ValueType=" 423

http://fabrikam123#CustomToken " 424

EncodingType="...#Base64Binary" wsu:Id=" MyID "> 425

(006) FHUIORv... 426

(007) </wsse:BinarySecurityToken> 427

(008) <ds:Signature> 428

(009) <ds:SignedInfo> 429

(010) <ds:CanonicalizationMethod 430

Algorithm= 431

"http://www.w3.org/2001/10/xml-exc-c14n#"/> 432

(011) <ds:SignatureMethod 433

WSS: SOAP Message Security (WS-Security 2004) 1 February 2006

Algorithm= 434

"http://www.w3.org/2000/09/xmldsig#hmac-sha1"/> 435

(012) <ds:Reference URI="#MsgBody"> 436

(013) <ds:DigestMethod 437

Algorithm= 438

"http://www.w3.org/2000/09/xmldsig#sha1"/> 439

(014) <ds:DigestValue>LyLsF0Pi4wPU...</ds:DigestValue> 440

(015) </ds:Reference> 441

(016) </ds:SignedInfo> 442

(017) <ds:SignatureValue>DJbchm5gK...</ds:SignatureValue> 443

(018) <ds:KeyInfo> 444

(019) <wsse:SecurityTokenReference> 445

(020) <wsse:Reference URI="#MyID"/> 446

(021) </wsse:SecurityTokenReference> 447

(022) </ds:KeyInfo> 448

(023) </ds:Signature> 449

(024) </wsse:Security> 450

(025) </S11:Header> 451

(026) <S11:Body wsu:Id="MsgBody"> 452

(027) <tru:StockSymbol xmlns:tru="http://fabrikam123.com/payloads"> 453

QQQ 454

</tru:StockSymbol> 455

(028) </S11:Body> 456

(029) </S11:Envelope> 457

458

The first two lines start the SOAP envelope. Line (003) begins the headers that are associated 459

with this SOAP message. 460

461

Line (004) starts the <wsse:Security> header defined in this specification. This header 462

contains security information for an intended recipient. This element continues until line (024). 463

464

Lines (005) to (007) specify a custom token that is associated with the message. In this case, it 465

uses an externally defined custom token format. 466

467

Lines (008) to (023) specify a digital signature. This signature ensures the integrity of the signed 468

elements. The signature uses the XML Signature specification identified by the ds namespace 469

declaration in Line (002). 470

471

Lines (009) to (016) describe what is being signed and the type of canonicalization being used. 472

473

Line (010) specifies how to canonicalize (normalize) the data that is being signed. Lines (012) to 474

(015) select the elements that are signed and how to digest them. Specifically, line (012) 475

indicates that the <S11:Body> element is signed. In this example only the message body is 476

signed; typically all critical elements of the message are included in the signature (see the 477

Extended Example below). 478

479

Line (017) specifies the signature value of the canonicalized form of the data that is being signed 480

as defined in the XML Signature specification. 481

482

剩余75页未读，继续阅读

millersisi

粉丝: 1
资源: 13

WS-Security2004: SOAP消息安全1.1规范

windows 配置freeswitch开启wss

nginx wss配置

nginx ws配置wss

<groupId>org.apache.wss4j</groupId>

qt websocket wss例程

uni-app能使用wss协议的websocket吗

netty-websocket-spring-boot-starter包创建的websocket controller怎么采用wss

输出SOAPheader

nginx wss正向代理

docker 部署 freeswitch 开启wss

最新资源