1 / 19

A Pattern for WS-Security

A Pattern for WS-Security. Presented by Keiko Hashizume. Outline. Introduction A Pattern for WS-Security Conclusion. Introduction.

lonato
Download Presentation

A Pattern for WS-Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. A Pattern for WS-Security Presented by Keiko Hashizume

  2. Outline • Introduction • A Pattern for WS-Security • Conclusion

  3. Introduction • Web services standards are confusing which makes it difficult for vendors to develop products that comply with standards and for users to decide what product to use. • That is why we need to develop patterns for these standards. • Patterns embody the knowledge and experience of software developers about a recurrent problem. A pattern solves a specific problem in a given context and can be tailored to fit different situations.

  4. WS-Security Standard • Originally developed by IBM, Microsoft, VeriSign, and Forum Systems. • OASIS Specification • Latest Version: WS-Security 1.1 • Approved on February 2006

  5. A Pattern for WS-Security • WS-Security standard describes how to embed existing security mechanism such as encryption, and digital signature into SOAP messages in order to provide message confidentiality, message integrity, message authentication, and non-repudiation. • Context • Users of web services send and receive SOAP messages through insecure channel such as the Internet.

  6. Problem • These SOAP messages that travel through insecure transports can be exposed to the following threats: • The message can be read by attackers. • An antagonist can modify messages. • Anyone could send messages that later he would deny having sent the messages.

  7. Problem • Forces: • We need a common format in SOAP messages in order to add security features, so both senders and receivers can be able to process messages that contain security features. • SOAP messages may travel in a network environment with many intermediaries, an end-to-end security solution is needed. For example, SOAP messages pass through multiple applications between companies. • Messages may be captured in transit, so we need to prevent unauthorized users from reading this data. • Messages may be not only captured but modified, so we need to protect this data in order to provide message integrity. • Messages may be intercepted and resent; thus we need to prevent message replay and to prove the freshness of a message.

  8. Solution • Define areas in the message format that specify parameters for security mechanisms such as encryption and digital signatures. • WS-Security specifies how to add security information into SOAP messages. Also, WS-Security leverages existing security standards such as XML Encryption and XML Signature.

  9. Structure - Class Diagram

  10. Dynamics • Sequence Diagram for the UC: Encrypt an element using an encrypted key

  11. Dynamics • Sequence Diagram for the UC: Sign an element using a security token

  12. Implementation • To implement WS-Security standard, the following tasks need to be done: • Client applications must be able to add and read security elements from SOAP messages. • Clients need to have knowledge of cryptographic algorithms such as security token formats, signature formats and encryption technologies.

  13. Example 1 <soap:Envelope> <soap:Header> <wsse:Security> <xenc:EncryptedKey> <xenc:EncryptionMethod Algorithm=”…” /> <ds: KeyInfo> <wsse:SecurityTokenReference> <wsse:KeyIdentifier EncodingType=”…” ValueType=”…”> </ wsse:KeyIdentifier > </wsse:SecurityTokenReference> </ds:KeyInfo> <xenc:CipherData> <xenc:CipherValue> JHJHVKJXCKVMNLXKJ… </xenc:CipherValue> </xenc:CipherData> <xenc:ReferenceList> <xenc:DataReference URI=”Ref1” /> </xenc:ReferenceList> </xenc:EncryptedKey> </wsse:Security> </soap:Header> <soap:Body> <xenc:EncryptedData Type=”…” wsu:Id=”Ref1”> <xenc:EncryptionMethod Algorithm=”…” /> <xenc:CipherData> <xenc:CipherValue> FGLKJDKLFGJLDFG… </xenc:CipherValue> </xenc:CipherData> </xenc:EncryptedData> </soap:Body> </soap:Envelope> This example shows the structure of an encrypted data using an encrypted key.

  14. Example 2 <soap:Envelope> <soap:Header> <wsse:Security> <xenc:BinarySecurityToken ValueType=”…” EncodingType=”…” wsu:Id=”ST1”> </ xenc:BinarySecurityToken > <ds:Signature> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm=”…”> <ds:SignatureMethod Algorithm=”…”> <ds:Reference URI=”Ref1”> <ds:Transforms > <ds:Transform Algorithm=”…”/> </ ds:Transforms > <ds:DigestMethod Algorithm=”…”/> <ds:DigestValue> LJHDFKHASDJAS… </ds:Reference> </ds:SignedInfo> <ds:SignatureValue> LKSMFKDFOPSDF … </ds:SignatureValue> <ds:KeyInfo> <wsse:SecurityTokenReference> <wsse:Reference URI=”ST1”/> </wsse:SecurityTokenReference> </ds:KeyInfo> </ds:Signature> </wsse:Security> </soap:Header> <soap:Body> <wsu:Id=”Ref1”> </soap:Body> </soap:Envelope> The following example shows the syntax of a signed data using a security token.

  15. Consequences • This pattern presents the following advantages: • The header of a SOAP message can carry security features such as encryption and signature information. • Adding security features into the SOAP messages provides end-to-end level security because these messages can be protected during transmission through many intermediaries. • XML Encryption ensures that no unauthorized users can access or disclose the information in the message. Only users that know the key can decrypt and read the message. The encryption may reference a security token. • XML Digital signature is used to verify whether a message was modified in transit. If a message is digitally signed, any changes in the message will invalidate the signature. The signature may also reference a security token. • Security tokens such as username/password, Kerberos tickets and X.509 certificates can be used in order to prove the sender’s identity. • We can prevent message replay using timestamps. Timestamps express the creation and the expiration (optional) times of the message. Knowing the expiration time, the receiver can discard the message if it is expired. Also, timestamps can be referenced by any other element in the message such as signatures.

  16. Consequences • The pattern also has some (possible) liabilities: • This pattern does not describe fixed security protocols. • This pattern does not provide total security solution. • WS-Security is an immature specification.

  17. Known Uses Several vendors have developed products that support WS-Security. • Xtradyne’s WS-DBC (Web Service Domain Boundary Controller) http://www.xtradyne.com/products/ws-dbc/WSDBCfeatures.htm • IONA Artixwww.iona.com/info/aboutus/collateral/Artix%20and%20Security.pdf • Forum Sentry™ http://forumsys.com/products_sentry_specs.htm • Microsoft Trust Bridge http://www.microsoft.com/presspass/press/2002/Jun02/06-06TrustbridgePR.mspx

  18. Related Patterns WS-Security uses XML Signature and XML Encryption. Secure Channel contains a set of security protocols that provide identity authentication and secure, private communication through encryption.

  19. Conclusion • We need to develop related patterns such as XML Encryption and XML Signature. • We need to develop patterns for the WS – family such as WS-Policy, WS-Privacy, WS-SecureConversation, WS-Federation, and WS-Authorization.

More Related