Enhanced Interoperability for Security of XML Web Services

1
Enhanced Interoperability for Security of XML Web
Services

• Paula Austel, Michael McIntosh, Anthony Nadalin
• IBM

2
Introduction

• Enterprises are adopting Web Services for
  application integration across heterogeneous
  environments within and across domain boundaries
• Security technologies used with Web Services must
  not expose resources to unauthorized use
• Technologies must integrate with and leverage
  existing security infrastructure
• Web Services Security and HTTP Over TLS provide
  extensible and flexible mechanisms which suit
  these purposes
• This same extensibility and flexibility combine
  to make interoperability difficult
• Some set of guidelines are needed in order to
  limit the variety of possibilities that
  applications must implement and test in order to
  interoperate

3
WS-I Overview

• The Web Services Interoperability Organization
  (WS-I) is an open industry organization committed
  to promoting interoperability of Web Services
• based on common industry-accepted specifications
• The WS-I promotes interoperability by providing
  guidance and making recommendations for Web
  services implementations
• across platforms, applications, and programming
  languages
• Through these recommendations they hope to lower
  the technical obstacles to adoption of Web
  Services technologies
• ensuring the continued evolution of Web Services
  technologies
• More information on the mission of the WS-I and
  its membership is available at the web site
  (www.ws-i.org)

4
WS-I Process
SIG
SIG
Output

• Draft Field Interoperability Reports

RGWG
Output

• Field Interoperability Reports
• Draft Profile WG Charters
• Draft Usage Patterns

Profile WG
Output
Board

• Profiles
• Usage Patterns
• Sample Applications
• Conformance Validation Tools

Output
Application WG

• Profile WG Charters

Validation WG
5
WS-I Process

• WS-I Working Groups produce the following
  deliverables
• Use Cases capture the business requirements for
  a Web Service application
• Usage Scenarios demonstrate how specific Web
  Service message exchange patterns (MEPs) are
  constrained by a Profile
• Profiles comprised of a set of named and
  versioned Web services specifications together
  with a set of implementation and interoperability
  guidelines
• recommending how the specifications may be used
  to develop interoperable Web services
• Sample Applications demonstrate the
  implementation of applications that are built
  from WS-I compliant Web services
• utilize the usage scenarios and use cases that
  conform to a given set of profiles
• built on multiple platforms, languages, and
  development tools, to demonstrate
  interoperability in action
• application code which is available from several
  vendors, provides the Web Services practitioner
  with an example of a complete application that is
  conformant to the various profiles
• Testing Tools used to monitor and analyze
  messages generated and consumed by Web Services
  and analyze the descriptions and behavior of Web
  Services
• determine whether or not they conform to the WS-I
  Profiles
• available for developers to test compliance of
  the applications they are building

6
WS-I Profiles

• Basic Profile
• The Basic Profile 1.0 and 1.1 address
  interoperability of implementation of core Web
  Services standards including SOAP 1.1, WSDL 1.1,
  and UDDI 2.0
• Simple SOAP Binding Profile 1.0
• The Simple SOAP Binding Profile extends the Basic
  Profile to address HTTP 1.1
• Attachments Profile 1.0
• The Attachments Profile extends the Basic Profile
  to address the W3C Note on SOAP Messages with
  Attachments
• Basic Security Profile 1.0
• The Basic Security Profile extends the Basic,
  Simple SOAP, and Attachments Profiles to address
  security with the HTTP Over TLS and Web Services
  Security 1.0 standards

7
Security Scenarios

• Currently available as a public Working Group
  Draft
• Guides the development of the Basic Security
  Profile
• Targets Web Services architects and developers
• Explains how security applies to the Usage
  Scenarios defined for the Basic Profile
• Identifies
• security challenges and threats
• technologies to address the security challenges
• countermeasures to mitigate the threats
• which security challenges and threats are outside
  the scope of the BSP WG at this time

8
Message Exchange Patterns

• The following 3 basic message exchange patterns
  (MEPs) are adapted from the scenarios defined for
  the Basic Profile
• One-Way
• a SOAP message is sent, potentially through
  intermediaries, to a SOAP receiver. No response
  message is returned.
• Synchronous Request/Response
• a SOAP message (the request) is sent, potentially
  through intermediaries, to an ultimate SOAP
  receiver. A SOAP message (the response) is sent
  by the requests ultimate SOAP receiver through
  the reverse path followed by the request to the
  requests initial SOAP sender
• Basic Callback
• a SOAP message (the request) is sent, potentially
  through intermediaries, to an ultimate SOAP
  receiver, and an acknowledgement message is
  returned in the manner of synchronous
  request/response. The request contains
  information that indicates an endpoint for a SOAP
  node where the response should be sent. The
  requests ultimate SOAP receiver sends the
  response to that SOAP node, which returns an
  acknowledgement message in the manner of
  synchronous request/response

9
Security Challenges

• The Security Scenarios document discusses the
  challenges of
• data integrity
• data confidentiality
• peer authentication
• data origin authentication
• in the context of both transport and message
  level security
• Describes how the mechanisms available can be
  used alone or in combination to secure messages
• Incorrectly combining security mechanisms may not
  result in a more secure solution but may
  introduce vulnerabilities that were not present
  previously

10
Message Level Security

• SOAP messages are composed of xml elements
• Elements may be signed and/or encrypted by being
  referenced from a Signature and/or Reference List
• Individual elements within a message may be
  referenced from multiple Signatures and/or
  Reference Lists
• Messages may be composed of previously signed
  and/or encrypted elements
• As intermediaries process messages, they
  potentially
• sign and encrypt new and pre-existing data
• consume signed and encrypted data targeted at a
  SOAP actor that they portray
• It is important to preserve the security context
  of the message as it undergoes these
  transformations by intermediaries

11
SOAP Message Security

• Defines a "wsseSecurity" SOAP Header and
  associated processing
• Security headers may contain
• Security Tokens, Security Token References,
  Timestamps, Nonces, Signatures, Encrypted Keys,
  Encryption Reference Lists and Encrypted Data
• Each Security header is targeted to a specific
  SOAP actor
• A SOAP message may contain multiple Security
  headers
• however each must be targeted to a different SOAP
  actor

12
Basic Security Profile

• Provides clarifications and amplifications to a
  set of standards available to secure the
  transmission of web services messages
• Extends the profiles created by the WS-I Basic
  Profile Working Group adding interoperability
  guidelines for security
• Basic Profile 1.0
• Basic Profile 1.0 Errata
• Basic Profile 1.1
• Simple SOAP Binding Profile 1.0
• Attachments Profile 1.0

13
Security Specifications

• The interoperability guidelines are created by
  adding constraints to existing standards
• The following standards are profiled by the BSP
• HTTP Security
• HTTP over TLS (HTTPS)
• OASIS Web Service Security
• SOAP Message Security v1.0
• Username Token Profile v1.0
• X.509 Certificate Token Profile v1.0
• SOAP With Attachments Profile (currently draft)
• Please note that work is progressing in parallel
  on Profiles that extend the BSP to address
• REL Token Profile (currently Committee Draft)
• SAML Token Profile (currently Committee Draft)
• Kerberos Token Profile (currently draft)

14
Underlying Security Specifications

• Additionally, each of the profiled standards
  builds on existing standards such as
• XML Encryption
• XML Signature
• HTTP
• TLS / SSL
• XML Canonicalization
• etc.
• bringing them into scope for the profile
• These standards are only in scope where used by
  the higher level standards

15
Flexibility and Extensibility

• The framework defined in the profiled standards
  is extensible and can accommodate a wide range
  of
• security models
• security tokens
• signature formats
• encryption technologies
• Flexibility and extensibility is a challenge for
  interoperability
• The BSP focuses on improving interoperability by
• strengthening requirements when possible (making
  SHOULDs into MUSTs)
• reducing some of the flexibility (picking one
  right way when there are several alternatives)
  and extensibility
• This limits the set of common functionality that
  vendors must implement and test for
  interoperability

16
XML Signature Extensibility

• ltdsSignaturegt
• ltdsSignedInfogt
• ltdsCanonicalizationMethod
  Algorithm"http//www.w3.org/2001/10/xml-exc-c14n
  "/gt
• ltdsSignatureMethod Algorithm"http//www.w3
  .org/2000/09/xmldsigrsa-sha1"/gt
• ltdsReference URI"MsgBody"gt
• ltdsTransformsgt
• ltdsTransform Algorithmhttp//www.w3
  .org/2001/10/xml-exc-c14n/gt
• lt/dsTransformsgt
• ltdsDigestMethod Algorithm"http//www.w3
  .org/2000/09/xmldsigsha1"/gt
• ltdsDigestValuegtLyLsF0Pi4wPU...lt/dsDiges
  tValuegt
• lt/dsReferencegt
• lt/dsSignedInfogt
• ltdsSignatureValuegtDJbchm5gK...lt/dsSignatureVa
  luegt
• ltdsKeyInfogt
• ltwsseSecurityTokenReferencegt
• ltwsseReference URI"MyID"/gt
• lt/wsseSecurityTokenReferencegt
• lt/dsKeyInfogt
• lt/dsSignaturegt

17
Profile Statements

• The BSP includes statements that are
• Interoperability requirements
• Clarifying
• Security considerations
• Normative requirement statements
• Identified by numbers prefixed with the letter
  R, i.e. R1234
• Clarifying statements
• Eliminate confusion about the intended
  interpretation of a requirement from an
  underlying specification
• Identified by adding a suffix of a subscript
  letter c, i.e. R1234c
• Non-normative consideration statements
• Identified by numbers prefixed by the letter C,
  i.e. C2345

18
Profile Statement Examples

• For each group of related statements there are
  examples to demonstrate correct and incorrect use
  of the constructs that are addressed
• A statement and associated example
• R5420 Any dsDigestMethod/_at_Algorithm element in a
  SIGNATURE MUST have the value http//www.w3.org/2
  000/09/xmldsigsha1
• INCORRECT
• ltdsDigestMethod Algorithm'http//www.w3.org/2000
  /09/xmldsigmd5' /gt
• CORRECT
• ltdsDigestMethod Algorithm'http//www.w3.org/2000
  /09/xmldsigsha1' /gt
• A clarifying requirement
• R3060c A wsseEmbedded element in a
  SECURITY_TOKEN_REFERENCE MUST contain a single
  child element for a security token from an
  appropriate token profile
• A security consideration
• C4210 A wsseUsernameToken in a SECURITY_HEADER
  which contains a wsseNonce element SHOULD be
  referenced by a dsReference in a dsSignedInfo
  element in order to prevent replay

19
External Dependencies

• Completion of the BSP depends on
• Completion of the OASIS WSS SOAP With
  Attachments Profile
• This profile is being developed by the OASIS Web
  Services Security TC at the request of the BSP WG
• Completion of the WS-I Sample Applications and
  the Test Tools Working Groups
• These deliverables along with the BSP provide a
  complete package for improving interoperability

20
Summary

• Enhanced interoperability for secure web services
  will be achieved through conformance to the Basic
  Security Profile
• Preliminary testing of draft BSP-based sample
  applications has benefited the interoperability
  of products currently under development
• Vendors have already experienced enhanced
  interoperability for core web services through
  conformance to the Basic Profile
• The Basic Security Profile and Security Scenarios
  are available today as public working group
  drafts
• The Basic Security Profile Working Group welcomes
  comments from the public on the Security
  Scenarios and Basic Security Profile
• Comments should be sent to wsi_secprofile_comment_at_
  lists.ws-i.org

21
Useful Links

• WS-I
• Basic Security Profile 1.0 (http//www.ws-i.org/Pr
  ofiles/BasicSecurityProfile-1.0.html)
• Security Scenarios 1.0 (http//www.ws-i.org/Profil
  es/BasicSecurity/2004-02/SecurityScenarios-0.15-WG
  D.pdf)
• Basic Profile 1.0 (http//www.ws-i.org/Profiles/Ba
  sicProfile-1.0-2004-04-16.html)
• Basic Profile 1.0 Errata (http//www.ws-i.org/Prof
  iles/BasicProfile-1.0-errata-2004-03-17.html)
• Basic Profile 1.1 (http//www.ws-i.org/Profiles/Ba
  sicProfile-1.1-2004-08-24.html)
• Attachments Profile 1.0 (http//www.ws-i.org/Profi
  les/AttachmentsProfile-1.0-2004-08-24.html)
• Simple SOAP Binding Profile 1.0
  (http//www.ws-i.org/Profiles/SimpleSoapBindingPro
  file-1.0-2004-08-24.html)
• Usage Scenarios (http//www.ws-i.org/SampleApplica
  tions/SupplyChainManagement/2003-12/UsageScenarios
  -1.01.pdf)
• Web Services Security
• SOAP Message Security 1.0 (http//docs.oasis-open.
  org/wss/2004/01/oasis-200401-wss-soap-message-secu
  rity-1.0)
• SOAP Message Security 1.0 Errata 1.0
  (http//www.oasis-open.org/committees/download.php
  /7488/oasis-200401-wss-soap-message-security-1.0-e
  rrata-001.pdf)
• Username Token Profile 1.0 (http//docs.oasis-open
  .org/wss/2004/01/oasis-200401-wss-username-token-p
  rofile-1.0)
• Username Token Profile 1.0 Errata 1.0
  (http//www.oasis-open.org/committees/download.php
  /7486/oasis-200401-wss-username-token-profile-1.0-
  errata-001.pdf)
• X.509 Certificate Token Profile 1.0
  (http//docs.oasis-open.org/wss/2004/01/oasis-2004
  01-wss-x509-token-profile-1.0)
• X.509 Certificate Token Profile 1.0 Errata 1.0
  (http//www.oasis-open.org/committees/download.php
  /7487/oasis-200401-x509-token-profile-1.0-errata-0
  01.pdf)
• XML-Signature Syntax and Processing
  (http//www.w3.org/TR/xmldsig-core/)
• W3C XML Encryption Syntax and Processing
  (http//www.w3.org/TR/xmlenc-core/)
• SOAP Messages with Attachments, W3C Note, Dec
  2000, (http//www.w3.org/TR/SOAP-attachments)

22
Acknowledgements

• This paper describes the work of the WS-I Basic
  Security Profile Working Group
• Chair Paul Cotton, Microsoft Corporation
• Co-Chair Eve Maler, Sun Microsystems
• We wish to acknowledge the work of all the
  members of that group along with the
  collaborations with members of the WS-I Basic
  Profile Working Group, WS-I Sample Applications
  Working Group and WS-I Testing Tools Working Group

23
Contacts

• Paula Austel
• Senior Software Engineer
• IBM T.J. Watson Research Center
• pka_at_us.ibm.com
• Michael McIntosh
• Senior Software Engineer
• IBM T.J. Watson Research Center
• mikemci_at_us.ibm.com
• Anthony Nadalin
• Distinguished Engineer, Chief Security Architect
• IBM SWG/Tivoli
• drsecure_at_us.ibm.com

24
Any Questions?