Web Services Architecture and Its Specifications [Electronic resources] : Essentials for Understanding WS-* نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Web Services Architecture and Its Specifications [Electronic resources] : Essentials for Understanding WS-* - نسخه متنی

Luis Felipe Cabrera, Chris Kurt

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید





Message Integrity and Confidentiality


In order to provide message integrity, each Web services message can be signed with one or more XML signatures. The receiving system uses these signatures to verify that any changes made to the message during transmission can be detected.


Security Tokens


In order to sign a message, a security token is required. Although many different types of security tokenssuch as Username, X.509, SAML, and RELare available, our first example shows a simple Username Token with a password digest:


Username Token
(01) <wsse:UsernameToken wsu:Id="MyToken">
(02) <wsse:Username>SchoolofFineArt</wsse:Username>
(03) <wsse:Password Type="#PasswordDigest">
(04) weYI3nXd8LjMNVksCKFV8t3rgHh3Rw=="
(05) </wsse:Password>
(06) <wsse:Nonce>WScqanjCEAC4mQoBE07sAQ==</wsse:Nonce>
(07) <wsu:Created>2004-09-20T01:34:44Z</wsu:Created>
(08) </wsse:UsernameToken>

Line 02 The user account assigned to the School of Fine Art is included in the Username element. The Id attribute is included to allow this token to be directly referenced from other elements in the SOAP message.

Lines 0305 Because the message might travel over unsecured connections, the actual password for the School of Fine Art account is not included in the Username Token. Instead, the password digest is transmitted. This works because both the procurement system and the order management system have access to the actual password value.

Lines 0607 Both a nonce and timestamp are included in the Username Token as a countermeasure against replay attacks.

In addition to the Username Token, various binary security tokens, such as X.509 Certificate Tokens, can be used in Web services implementations. An example of the X.509 binary security token is shown here:


X509 Certificate Token
(01) <wsse:BinarySecurityToken
(02) ValueType="...#X509v3"
(03) wsu:Id="MyX509Token"
(04) EncodingType="...#Base64Binary">
(05) ME34K9CgAiemt0rqJ...
(06) </wsse:BinarySecurityToken>

Lines 0105 The attributes of the BinarySecurityToken element specify the type of token and how it is encoded. The Id attribute is included for reference to this token from other elements in the SOAP message.

Line 06 The actual binary token is Base64-encoded and opaque to the sending endpoint.


Signed Messages


Once the procurement system has the appropriate security token(s), they are included in the requests to the order management system in support of digital signatures and encryption. The following example shows the use of a username token, but any other security token format can be used similarly:


Signed Message Payload
(01) <env:Envelope>
(02) <env:Header>
...
(03) <wsse:Security>
(04) <wsse:BinarySecurityToken
(05) ValueType="...#X509v3"
(06) wsu:Id="TheX509Token"
(07) EncodingType="...#Base64Binary">
(08) ME34K9CgAiemt0rqJ...
(09) <wsse:BinarySecurityToken>
(10) <wsse:Signature>
(11) <ds:SignedInfo>
(12) <ds:CanonicalizationMethod
(13) Algorithm="http://www.w3.org/2001/10/xml-enc-c14n#"/>
(14) <ds:SignatureMethod
(15) Algorithm="http://www.w3.org/2001/09/xmldsig#hmac-sha1"/>
(16) </sd:SignedInfo>
(17) <ds:Reference URI="Body">
(18) <ds:DigestMethod
(19) Algorithm="http://www.w3.org/2001/09/xmldsig#sha1"/>
(20) <ds:DigestValue>LcLsF9i4spY...</ds:DigestValue>
(21) </ds:Reference>
(22) <ds:SignatureValue>MC3bc4rL...</ds:SignatureValue>
(23) <ds:KeyInfo>
(24) <wsse:SecurityTokenReference>
(25) <wsse:Reference URI="TheX509Token"/>
(26) </wsse:SecurityTokenReference>
(27) </ds:KeyInfo>
(28) </wsse:Signature>
(29) </wsse:Security>
(30) </env:Header>
(31) <env:Body wsu:Id="Body">
(32) <msp:PurchaseOrder> ... </msp:PurchaseOrder>
(33) </env:Body>
(34) </env:Envelope>

Lines 0409 The X509 binary security token is carried in the Security SOAP header block.

Lines 1028 The Signature element contains all the security information for the message payload.

Lines 1215 The algorithms used for calculating the signature are explicitly provided.

Lines 1721 The reference to the signed information is shown on line 17, followed by the algorithm used to calculate the digest value. The digest value itself is also provided.

Line 22 This line specifies the signature value of the canonicalized form of the data.

Lines 2327 These lines indicate where the security token used to sign the message is located. In this case, it is the element with the xml ID value of TheX509Token.


Encryption


In addition to adding digital signatures to SOAP messages, the messages can be further secured through encryption. This keeps the message contents confidential between the endpoints. Because the examples are intended to show readers what the actual SOAP messages look like on the wire, nearly all of the message fragments in our example show unencrypted text. If we were to put this order-processing solution into production, we would definitely want to encrypt significant portions of the messages, if not their entirety.

The following SOAP message fragment shows what a message with encrypted payload might look like on the wire. Our example uses an X509 certificate token provided by the Microsoft Press order management service.


Encrypted Message Bodies
(01) <env:Envelope ...>
(02) <env:Header>
...
(03) <wsse:Security>
(04) <xenc:EncryptedKey>
(05) <ds:KeyInfo>
(06) <wsse:securityTokenReference>
(07) <ds:X509IssuerSerial>
(08) <ds:X509IssuerName>
(09) DC=mspress.microsoft, DC=com
(10) </ds:X509IssuerName>
(11) <ds:X509SerialNumber>9937482243110</ds:X509SerialNumber>
(12) </ds:X509IssuerSerial>
(13) </wsse:SecurityTokenReference>
(14) </ds:KeyInfo>
(15) <xenc:ReferenceList>
(16) <xenc:DataReference URI="#Body" />
(17) </xenc:ReferenceList>
(18) </xenc:EncryptedKey>
(19) </wsse:Security>
(20) </env:Header>
(21) <env:Body>
(22) <xenc:EncryptedData Id="Body">
(23) <xenc:CipherData>
(24) <xenc:CipherValue>...</xenc:CipherValue>
(25) </xenc:CipherData>
(26) </xenc:EncryptedData>
(27) </env:Body>
(28) </env:Envelope>

/ 130