Secure Systems Research Group - FAU A Pattern for WS-Security Presented by Keiko Hashizume

Secure Systems Research Group - FAU

A Pattern for WS-SecurityPresented by Keiko Hashizume


Outline

• Introduction• A Pattern for WS-Security• Conclusion


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.


WS-Security Standard

• Originally developed by IBM, Microsoft, VeriSign, and Forum Systems.

• OASIS Specification• Latest Version: WS-Security 1.1• Approved on February 2006


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.


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.


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.


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.


– Structure - Class Diagram


– Dynamics

Sequence Diagram for the UC: Encrypt an element using an encrypted key


– Dynamics

Sequence Diagram for the UC: Sign an element using a security token


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.


Example 1

This example shows the structure of an encrypted data using an encrypted key.


Example 2

The following example shows the syntax of a signed data using a security token.


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.


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.


Known UsesSeveral 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 Artix www.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


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.


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.

Documents

Secure Systems Research Group - FAU A Pattern for WS-Security Presented by Keiko Hashizume