0db0c646d3d2577894385b9984b8ca9e.ppt
- Количество слайдов: 41
Promoting Web services interoperability across platforms, applications and programming languages 1 Paul Cotton, Microsoft June, 2004
Outline 2 Introduction WS-I goals WS-I organization and deliverables Web services security standards OASIS WS-Security TC WS-I Basic Security Profile Working Group WS-I Security Scenarios WS-I Basic Security Profile 1. 0 Questions
THE CONTEXT The shift to Web services is underway 4 An Internet-native distributed computing model based on XML standards has emerged 4 Early implementations are solving problems today and generating new requirements 4 The Web services standards stack is increasing in size and complexity to meet these requirements The fundamental characteristic of Web services is interoperability 3
THE CHALLENGE “[the] architecture of Web services is not fully crystallized. Without guidance, standards may fragment” Gartner “Inevitably, companies involved with Web services will define them in their own way. The term Web services will be a messy catchall phrase. ” Intelligent Enterprise “standards…allow Web services to overcome the barriers of different programming languages, operating systems, and vendor platforms so multiple applications can interact. ” e. Week 4
THE OPPORTUNITY Market Impact 1997 HTTP, HTML 5 XML Web Services 1999 2001 2003 WS-I formed 1995 2005
WHAT IS NEEDED? Guidance 4 A common definition for Web services 4 Implementation guidance and support for Web services adoption Interoperability 4 Across platforms, applications, and languages 4 Consistent, reliable interoperability between Web services technologies from multiple vendors 4 A standards integrator to help Web services advance in a structured, coherent manner 6
GOALS Achieve Web services interoperability 4 Across platforms, applications and languages Encourage Web services adoption 4 Among customers, industries and end users Accelerate Web services deployment 7
ACHIEVE INTEROPERABILITY Promote a common, clear definition for Web services Integrate specifications from various standards bodies Provide a visible representation of conformance through use of WS-I logo 8
ENCOURAGE ADOPTION Build industry consensus to reduce early adopter risks Provide a forum for end users to communicate requirements Act as a customer advocate to raise awareness of business requirements 9
ACCELERATE DEPLOYMENT Offer implementation guidance and best practices Deliver tools and sample applications Provide a forum for Web services developers to collaborate and share expertise 10
ORGANIZATION Board of directors 4 Management and administration body 4 Ensure the organization and its working groups adhere to their defined scope Working groups 4 Develop materials and other deliverables to aid Web services interoperability Membership 4 Vote to approve adoption and distribution of any materials developed by the working groups 11
TECHNICAL WORKING GROUPS Basic Profile 4 Chris Ferris, IBM Scenarios and Sample Applications 4 Marc Goodner, SAP Testing Tools and Materials 4 Narendra Patil, Optimyz Software Basic Security Profile 4 Paul Cotton, Microsoft Requirements Gathering 4 Rimas Rekasius, IBM 12
WORKING GROUP DELIVERABLES Profiles 4 Named groups of specifications at given version levels with conventions about how they work together Use cases and usage scenarios 4 Solution scenarios based on customer requirements Sample code and applications Test suites and supporting materials 4 Conformance testing tools 4 Supporting documentation and white papers 13
SAMPLE DELIVERABLES scenarios and sample use cases usage scenarios applications web services profiles basic profile testing tools and materials 14 testing tools other test materials sample applications
PROFILES Provide guidance on general purpose Web services functionality Address interoperability at a level above specification-byspecification Supporting specifications and standards will be considered from multiple industry sources Profile development will reflect market needs and requirements 15
USE OF DELIVERABLES The public is free (and encouraged) to 4 Download, use, and review each Profile 4 Download and use test tools and material to test their applications 4 Download, use, modify, and redistribute WS-I sample applications Adopters may (in addition to the above) 4 Reproduce and redistribute specifications with their products Members may (in addition to all of the above) 4 Ship test tools and material (as is or modified) within their products 19
KEY MILESTONES Delivered Basic Profile 1. 0 (Aug, 2003) 4 Profile of SOAP 1. 1, WSDL 1. 1, UDDI 2. 0 Delivered Sample Applications 1. 0 (Dec, 2003) Delivered Basic Profile 1. 1, Attachments Profile 1. 0 and Simple SOAP Binding Profile 1. 0 Working Group Drafts (Dec, 2003) 4 Reorganization of Basic Profile 1. 0 4 Profile of SOAP with Attachments Delivered Security Scenarios Working Group Draft (Feb, 2004) Delivered Testing Tools 1. 0 (Mar, 2004) Delivered Basic Security Profile Working Draft (May, 2004) Future 4 Final materials on BP 1. 1, AP 1. 0, SSBP 1. 0 4 Final materials on BSP 1. 0 4 More Testing and Sample Apps materials 22
WS-I AND STANDARDS BODIES Web services standards come from a variety of bodies 4 W 3 C, OASIS, IETF, ISO, ECMA, etc. WS-I is a standards integrator 4 Downstream from standards organizations 4 Upstream from industry and industry consortia 4 Ensure interoperability of implementations Collaboration with other bodies is a requirement 23
WS-I, STANDARDS AND INDUSTRY Standards and Specifications Requirements Implementation Guidance Businesses, Industry Consortia, Developers, End-Users 24
WS-I AND STANDARDS BODIES Support relationships with standards bodies who own specifications referenced by WS-I profiles 4 Ensure consistency 4 Minimize redundancy Foster communication and cooperation with industry consortia and other organizations 25
WEB SERVICES SECURITY STANDARDS WSSecure. Conversation WS-Policy WS-Federation WS-Trust WS-Security SOAP Foundation 27 WS-Authorization WS-Privacy XKMS SAML XACML XML Encryption SPML XML Digital Signature
OASIS WS SECURITY TC OASIS Web Services Security TC created September, 2002 Interoperability testing Summer 2003 Voted Committee Draft September, 2003 4 Core specification plus Username and X. 509 tokens Public Review completed October, 2003 Adopted as OASIS standard in January, 2004 REL (XRML) token type voted CD June, 2004 Other token types under interoperability testing 4 Kerberos, SAML, etc. 28
OASIS WSS Security Header 4 Can contain must. Understand 4 Can be addressed to Role Tokens 4 Associated with signature or encryption or otherwise used to identify party to message exchange 4 Binary Token - encapsulates binary object 4 X. 509 certificate – defined by ITU/IETF 4 Kerberos ticket – defined by IETF/Microsoft 4 XML Token – inserted as is 4 Username Token – defined by OASIS WSS TC 4 SAML Assertion – defined by OASIS SS TC 4 REL (Xr. ML License) – defined by Content. Guard 29
OASIS WSS Security Token Reference 4 Points to or encapsulates a token 4 Four types 4 Direct – URI or URI fragment 4 Key Identifier – specific to token type – identifies key, certificate, ticket, assertion, etc. 4 Key Name – identifies token by content, e. g. Subject. Name 4 Embedded – encapsulates token, allows association of additional information with token Signature element 4 New transform - STR Dereference Transform Encryption Reference. List or Encrypted. Key elements Timestamp element 4 Only applies to security mechanisms 4 Created and/or Expires 30
WS-I BASIC SECURITY PROFILE WG BSP WG chartered in March, 2003 Two initial deliverables 4 Security Scenarios 4 Basic Security Profile 1. 0 4 Based of Basic Profile 1. 0 and the following technologies: – HTTP over TLS – SOAP with Attachments – WSS and X. 509, username & Kerberos tokens 4 Complete by 9 months after WSS is Committee Draft (Sep, 2003) Large WG with over 20 active member companies 31
SECURITY SCENARIOS WORKING DRAFT Security Challenges Threats Security Solutions and Mechanisms 4 Transport Layer & Message (SOAP) Layer Scenarios 4 Generic Requirements (no scenario-specific ones yet) 4 Scenarios (From WS-I Sample Applications) 4 One-way 4 Synchronous Request/Response 4 Basic Callback 4 Others? Feb 2004 draft for public comment 4 http: //ws-i. org/Profiles/Basic. Security/2004 -02/Security. Scenarios-0. 15 -WGD. pdf 32
SECURITY SCENARIO SECTIONS Challenges Threats 33 Scenarios Mechanisms
THREATS – IN SCOPE In scope 4 Message Alteration 4 Attachment Alteration 4 Confidentiality 4 Falsified Messages 4 Man in the Middle 4 Principal Spoofing 4 Repudiation 4 Forged Claims 4 Replay of Message Parts 4 Replay 4 Denial of Service - Amplifier 34
THREATS – OUT OF SCOPE Out of Scope 4 Key Attack / Weak Algorithm 4 Traffic Analysis 4 Host Penetration / Access 4 Network Penetration / Access 4 Timing 4 Covert Channels 4 Message Archives 4 Network Spoofing 4 Trojan Horse 4 Virus 4 Tunneling 4 Denial of Service - Other 35
SECURITY SOLUTIONS AND MECHANISMS Integrity, Confidentiality, Authentication, Attributes Transport Layer (HTTP/HTTPS) 4 HTTP & SSL/TLS mechanisms Message Layer 4 WSS mechanisms Combinations 4 Large number of theoretically possible combinations 4 Identified nine believed to be of practical utility Security Considerations 4 Properties, Threats addressed, Limitations 36
SECURITY CHALLENGES Peer Identification and Authentication Data Origin Identification and Authentication Data Integrity 4 Transport Data Integrity 4 SOAP Message Integrity Data Confidentiality 4 Transport Data Confidentiality 4 SOAP Message Confidentiality Message Uniqueness Out of Scope 4 Credentials Issuance 37
SCENARIOS Notations and conventions Generic requirements 4 Peer Authentication 4 Integrity 4 Confidentiality 4 Origin Authentication Scenario descriptions 4 One-Way 4 Synchronous Request / Response 4 Basic Callback 4 Others? 38
SECURITY SCENARIOS - CURRENT WORK How to secure SOAP with Attachments used by Attachment Profile 1. 0? WG Charter originally proposed S/MIME WG has decided that it is better to extend Web Services Security to handle AP 1. 0 OASIS WSS TC now working on a proposed solution Final Security Scenarios expected in Aug, 2004 39
WS-I BASIC SECURITY PROFILE (BSP) 1. 0 Guiding principles of profile design 4 No guarantee of interoperability 4 Focus profiling effort 4 Application semantics 4 Testability 4 Strength of requirements 4 Restriction vs. relaxation 4 Multiple mechanisms 4 Future compatibility 4 Compatibility with deployed services 4 Focus on interoperability 4 Conformance targets 4 Do no harm 40
WS-I BASIC SECURITY PROFILE (BSP) 1. 0 Methodology 4 Reviewed WSS Documents (WSS core, username, X. 509) 4 Comments to WSS TC 4 Generated potential profiling points (captured as issues) 4 Reviewed underlying documents 4 IETF RFCs covering TLS 4 XML Signature, XML Encryption Identified 90+ potential profiling points by looking for anything other than MUST (e. g. optionality in spec) Many have since been dropped First public WD published May, 2004 4 http: //ws-i. org/Profiles/Basic. Security. Profile-1. 0 -2004 -05 -12. html 41
BSP 1. 0 QUESTIONS AND ANSWERS Cover SSL? 4 Yes, mentioned in WS-I Basic Profile 1. 0 Address SOAP Intermediaries? 4 Yes, must be considered because of security implications What will document look like? 4 Identify constraints by category, as in Basic Profile If and how to handle security considerations? 4 Added security considerations section even though it is not testable One profile or several? 4 BSP 1. 0 will be one document 4 Subsequent token profiles can be published separately How to secure Attachment Profile 1. 0? 4 Decided to use WSS and to request OASIS TC to do this work 42
EXAMPLE REQUIREMENT 4. Transport Layer Security This section of the Profile incorporates the following specifications by reference, and defines extensibility points within them: 4 HTTP over TLS Extensibility points: 4 E 0001 - Ciphersuites - Additional ciphersuites may be specified. 4. 1 SSL and TLS The following specifications (or sections thereof) are referred to in this section of the Profile; HTTP over TLS: Section 2. 2. 1 SSL and TLS are both used as underlying protocols for HTTP/S. This profile places the following constraints on those protocols: 4. 1. 1 Use of SSL 2. 0 has known security issues and all current implementations of HTTP/S support more recent protocols. Therefore this profile prohibits use of SSL 2. 0. R 2001 A SENDER MUST NOT use SSL 2. 0 as the underlying protocol for HTTP/S R 2002 A RECEIVER MUST NOT use SSL 2. 0 as the underlying protocol for HTTP/S 43
OTHER BSP 1. 0 DELIVERABLES scenarios and sample use cases usage scenarios applications web services profile basic security profile testing tools and materials 44 testing tools other test materials sample applications
TESTING AND DEMONSTRATING BSP 1. 0 How to test Basic Security Profile 1. 0? 4 BP 1. 0 Testing Tools used a man in the middle testing strategy 4 Will this work for BSP 1. 0 since one of its objectives is to stop man in the middle attacks? 4 What level does the testing take place at? 4 Highest level message syntax? 4 After parts of the message have been decrypted? BSP sample applications and usage scenarios 4 Based on sample application for BP 1. 0 adding security aspects 45
FUTURE WORK PLANS Security Scenarios 4 Add text for attachments using WSS 4 Final material ETA: Aug, 2004 Basic Security Profile 1. 0 4 Small number of issues pending work by OASIS TC 4 Add text for attachments using WSS pending work by OASIS TC 4 Final material ETA: Sep, 2004 Additional token profiles 4 Candidates include Kerberos, REL, SAML 4 Depends on progress by OASIS TC 4 Final material ETA: Nov, 2004 46
QUESTIONS Today Later 4 mailto: pcotton@microsoft. com Comments on BSP documents 4 mailto: wsi_secprofile_comment@lists. ws-i. org Security Scenarios published Feb, 2004 4 http: //ws-i. org/Profiles/Basic. Security/2004 -02/Security. Scenarios 0. 15 -WGD. pdf BSP 1. 0 WD published May, 2004 4 http: //ws-i. org/Profiles/Basic. Security. Profile-1. 0 -2004 -05 -12. html 47
0db0c646d3d2577894385b9984b8ca9e.ppt