Patterns for Web Services Security Standards Presented by

Patterns for Web Services Security Standards Presented by Keiko Hashizume Secure Systems Research Group - FAU

Outline • • Introduction Patterns for Web Services Security Standards WS-Security Conclusions Secure Systems Research Group - FAU

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. Secure Systems Research Group - FAU

Existing Patterns for WS Security Standards • XACML (e. Xtensible Access Control Markup Language) Policy Language • XACML Access Control Evaluation • WSPL (Web Service Policy Language) • WS-Policy • SAML (Security Assertion Markup Language) Secure Systems Research Group - FAU

Web Services Security Standards without Patterns • SPML (Service Provisioning Markup Language) • WS-Security • XML digital signature • XML encryption • XKMS (XML Key Management Specification) • Xr. ML (Extensible Rights Management Language) • XCBF (XML Common Biometric Format) Secure Systems Research Group - FAU • • • WS- Authorization WS-Encryption WS-Federation Language WS-Federation: Active Requestor Profile WS-Federation: Passive Requestor Profile WS-Signature WS-Privacy WS-Secure. Conversation WS-Security Kerberos Binding WS-Security. Policy WS-Trust 1. 3

WS-Security Standard • Originally developed by IBM, Microsoft, Veri. Sign, and Forum Systems. • OASIS Specification • Latest Version: WS-Security 1. 1 • Approved on February 2006 Secure Systems Research Group - FAU

WS-Security Standard • Security Header: – The <wsse: Security> header block provides a mechanism for attaching security-related message information. Secure Systems Research Group - FAU

WS-Security Standard • WS-Security Specification provides three main mechanisms: – The ability to send security tokens as part of a message – Message integrity – is provided by XML Signature – Message confidentiality – is provided by XML Encryption Secure Systems Research Group - FAU

Security Tokens • WS-Security defines how security tokens are attached to messages. • There are different types of security tokens: – Username. Token – Binary Security Tokens – XML Tokens Secure Systems Research Group - FAU

Username. Token Profile • The Username. Token propagates a username and a password (optional) Secure Systems Research Group - FAU

Binary Security Tokens • WS-Security provides a <wsse: Binary. Security. Token> element that can be included in the <wsse: Security> header block. • The following is an overview of the syntax: • Examples • X. 509 certificates • Kerberos tickets Secure Systems Research Group - FAU

XML Tokens • XML Tokens are offered in two formats: – Security Assertion Markup Language (SAML) – Extensible rights Markup Language (Xr. ML) • Example of a WS Security with a SAML assertion Token Secure Systems Research Group - FAU

Signatures • Digital signatures provide message integrity and authentication. • WS-Security builds on XML Signature. • This specification describes: – Signing Messages – Signing Tokens Secure Systems Research Group - FAU

Signing Messages • To add signature to a <wsse: Security> block, a <ds: Signature> element conforming to the XML Signature specification must be present in the header block. Secure Systems Research Group - FAU

Signing Tokens • WS-Security allows different tokens to have their own unique reference. Secure Systems Research Group - FAU

Encryption • WS-Security allows encryption of the body and header blocks by either a common symmetric key shared by the producer and the recipient or a symmetric key carried in the message in an encrypted form. • WS-Security leverages the XML Encryption standard. • This specification describes how the two elements <xenc: Reference. List> and <xenc: Encrypted. Key> can be used within the <wsse: Security> header block. Secure Systems Research Group - FAU

Encryption • The element that needs to be encrypted must be replaced by a corresponding <xenc: Encrypted. Data>. Secure Systems Research Group - FAU

Encryption • When the encryption involves encrypting element contents within a SOAP envelope with a symmetric key, that is encrypted and embedded in the message, <xenc: Encrypted. Key> may be used for carrying such an encrypted key. Secure Systems Research Group - FAU

Encryption Secure Systems Research Group - FAU

Class Diagram for WS-Security Secure Systems Research Group - FAU

Conclusion • We need to develop more patterns for web services security standards. • A good catalog of patterns is needed. • We also need pattern classification and selection approaches, e. g. pattern map, policy to pattern mapping. Secure Systems Research Group - FAU