Hide Notes 

Slide 1: Service Oriented Architecture SOA Workshop Starter Kit Web Services Security Last Updated: July, 2006
Slide 2: SOA Workshop Starter Kit – Web Services Security SOA Workshop Starter Kit Sponsor: Last Updated: Version: Intent of Section: Intended Audience: Master Document: David L. Nichols July, 2006 2.0 This document lays describes key concepts and considerations for implementation of a web services security architecture For internal and external use (Unless otherwise documented) 7-SOA_Workshop_WS-Security v0.2.ppt 10/05/05 https://kx.accenture.com/_layouts/kx/dispcontributionform.a SOA for Senior IT Executives Workshop – Securing Service Oriented Architectures – Anthony Robinson, London, February, 2006 (no link provided) To Find Additional SOA content: Copyright © 2006 Accenture All Rights Reserved. https://technology.accenture.com/SOA SOA Workshop – V2.0 2
Slide 3: Contents • Security and Web Services Industry Standards WS* In Detail Platform Support Recommendations • • • • Copyright © 2006 Accenture All Rights Reserved. SOA Workshop – V2.0 3
Slide 4: Business Opportunities Significant opportunities exist for organizations to drive revenue growth, create new business models, realize cost savings, and improve the user experience leveraging Security concepts • • • • New business models • Service providers that provide Identity related services • Service providers that provide “traditional” value-added services (e.g., HR or payroll) which can be more easily integrated into a customer’s enterprise Drive revenue growth • Improve and streamline the process for identifying and acquiring new customers • Streamline ability for collaboration with business partners Cost savings • Reduce user administration costs through automation • Reduce application development/integration costs through reusability Improve user experience • Have a single identity that can be used globally • Improve the overall security through the reduction of data sources and duplicate data SOA Workshop – V2.0 4 Copyright © 2006 Accenture All Rights Reserved.
Slide 5: Security Concerns Limits Use Security concerns have historically been one of the key reasons that businesses have not taken advantage of the benefits that Web Services and Service Oriented Architectures have to offer: “…the prospect of software from different companies communicating together, while powerful, is fraught with security concerns.” (Source: “Web Services Security”, Mark O’Neil, 2003) “...unless security and management issues are addressed effectively they will hold Web Services back from becoming a truly mainstream technology within enterprise application integration projects.” (Source: SC Magazine, January 2004) “Conflicting standards make Web Services security decisions complex and difficult. (Companies should) begin with simple Web Services deployments that support only your current business needs.” (Source: “Making Sense of Web Services Security Standards”, Gartner Aug ‘03) Copyright © 2006 Accenture All Rights Reserved. This is not just a technology issue. SOA Workshop – V2.0 5
Slide 6: Business Challenges Key factors for widespread adoption of web services include the identification of sound business models and more experience with the contractual frameworks that define trust relationships. Most current implementations are internal though this is changing Mutual Confidence (Trust) • Risk • Mitigating risk and ensuring quality between parties in the circle of trust can be performed through: • Definition of business standards • Definition of minimum requirements • Enforcement through certification and audits • • • Pooled knowledge: sharing of customer/identity information (e.g. # of customers, customer names, etc...) between or within enterprises – data privacy Revocation procedures: increased reliance on third parties for authentication Fraud protection: broadened potential for fraud if an identity is ever compromised Security incident procedures: coordinated effort for analysis and correlation of audit logs among parties involved Liability • Compliance • Who is at fault if a critical transaction failed due to failure? To what extent? • Definition of liability • Definition of dispute resolution process • Privacy legislation: ensure privacy terms are not violated when federating an identity between enterprises Who initiated each transaction – audit trail back to initiating user. 6 Copyright © 2006 Accenture All Rights Reserved. SOA Workshop – V2.0
Slide 7: What are YOUR Security Requirements? There are several new business challenges that must be addressed before Web Services can be securely deployed Can I ensure that there will be adequate controls/records to guarantee the results of a processed transaction? Can I ensure that transactions are only being performed by trusted parties (send or receive)? Identification Authentication Non-Repudiation Can I quickly deploy new services without compromising my internal business processes? Administration Accountability Authorization Can I ensure privacy of the transactions (sensitive business/client data regulatory compliance, etc..)? Confidentiality Integrity Can I ensure that only authorized transactions are being performed on the system? Can I guarantee that transactions are not tampered with? Copyright © 2006 Accenture All Rights Reserved. SOA Workshop – V2.0 7
Slide 8: Overcoming the Security Barriers Accenture has proven that new standards and new products are now able to provide customized solutions to overcome the security challenges Federated Identity Web Services Access Control Web Services Development Platforms Auditing Identification Authentication Non-Repudiation Administration Accountability Authorization Electronic Signature Confidentiality Integrity Encryption Copyright © 2006 Accenture All Rights Reserved. XML Firewalls SOA Workshop – V2.0 8
Slide 9: What is Web Service Security? The W3C defines a Web Service as the following: • “A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAPmessages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.” Web Service Security encompasses the following areas: • Transportation Layer Security: providing confidentiality and integrity in transit. • Message Layer Security: ensuring that messages are according to specification. • Identity and Access Management: providing authentication, authorization and identification. • Security Administration of Web Services: enabling audit trails and security administration. • Intrusion Detection and Prevention: protecting against common WS threats. Copyright © 2006 Accenture All Rights Reserved. SOA Workshop – V2.0 9
Slide 10: Without Proper Controls Web Services can be Vulnerable One of the most enticing aspects of Web Services is that a large degree of complexity is abstracted away from the view of the developer, making the services very easy (and cheap) to develop. • • • Adding a [WebMethod] parameter to a method allows for almost instant publishing (.NET, similar possibilities in Java). Processing of HTTP requests, serialization of XML and parsing of SOAP message is totally invisible to the developer. SOAP layer will take care of data serialization and de-serialization. Easy is dangerous! Making a web service is so easy that you easily forget that security is not a part of the SOAP stack: • • • • No Authentication or Authorization. Out of the box anyone with access to your web server can execute your web methods! Input data not cleansed – but neatly packed in complex class structures… A lot of processing is done before reaching the developer. Protecting the underlying stack cannot be done from within the code. Rich functionality is once more provided for access from outside of the firewall. SOA Workshop – V2.0 10 Copyright © 2006 Accenture All Rights Reserved.
Slide 11: How To Secure Web Services To secure web services we have to ensure that… • only properly authenticated and authorized users are allowed to execute our web methods. • messages are protected both with regards to integrity and confidentiality, during transport and storage, so that third parties cannot alter messages or read confidential contents of messages. • application servers are protected against the common threats to SOAP/XML stacks. • web service applications are written with security in mind to prevent common security threats to network aware applications. To meet the above requirements we will have to deploy protection along two main axes: • • Technical Security Functional Security SOA Workshop – V2.0 11 Copyright © 2006 Accenture All Rights Reserved.
Slide 12: Technical Security Overview What do we mean by Technical Security for Web Services? • Protection against malicious message formats that may lead to a compromise of security in the SOAP and XML layers of the application server. • Protection against malicious contents that does not conform to the defined messaging standard for the web service. • Protection against different forms of denial of service attacks. There are three main avenues of attack that can be used when attacking a web service application stack: • Application – any exposed business logic is prone to errors, either by design or by coding error. Web services are as vulnerable as other applications. • SOAP – the messaging protocol has ambiguities that can be challenged by an attacker. • XML – parsing of complex XML messages can create security vulnerabilities. Copyright © 2006 Accenture All Rights Reserved. SOA Workshop – V2.0 12
Slide 13: Application Attacks The Open Web Application Security Project lists the top ten threats against web applications. Most are equally valid against Web Service applications. Four are specific to the application level: • Unvalidated Input • Buffer Overflows • Injection Flaws • Improper Error Handling SQL Injection • • • Unvalidated input used directly in an SQL query might lead to a compromise of security. Almost all web service applications are built on top of a database – everyone is a potential target. XML provide means to obfuscate malicious characters. Unvalidated input used directly to access the file system might lead to a compromise of security. A very common attack strategy against IIS using URLs prefixed with ../../ sequences. Sandboxing in Java and .NET provides a fair level of protection. Exposing internal application errors to users will enable attackers to gain more information about the underlying system. The more information about the underlying system you have the easier it is to craft a successful attack. SOA Workshop – V2.0 13 Path Traversal • • • Improper Error Handling • • Copyright © 2006 Accenture All Rights Reserved.
Slide 14: SOAP Attacks The SOAP protocol which is the underlying protocol for most Web Services today has no built-in security: • • • All method calls are unprotected. API is publicly available through dynamically created WSDL files. SOAP is stateless. • • Protocol weaknesses Unprotected WSDL enables easy harvesting of information about a system, it’s accessible methods and potential design vulnerabilities. The protocol is poorly defined in some areas and implementations vary. SOAP HTTP headers are processed differently across different systems, and may be used to thwart handling of requests on the transport level. Parsing large SOAP requests is processor and memory heavy. XML needs to be converted to object collections and the validity of the request must be verified. Poorly coded methods might accept arbitrarily large input parameters. SOAP headers can be added at will due to a flexible standard. An attacker can easily send multiple XML text file over an HTTP link, which will lead to a depletion of server resources. Denial of Service • • • • The SOAP protocol is stateless – the developer has to implement statefullness separately, either using HTTP cookies or inline session IDs. • If session IDs are predictable it is vulnerable to session spoofing. • Vulnerable to replay attacks. SOA Workshop – V2.0 Copyright © 2006 Accenture All Rights Reserved. • Replay Attacks 14
Slide 15: XML Attacks XML is the basis of Web Services: • • Successful attacks on web services generally means crafting a valid XML file that is misinterpreted by either parser or developer. Invalid XML dropped by parser early on. XML documents are validated against their published schema. Tampering with the schema is a common approach. • External Schema • • XML documents contain links to external schemas that are used to define namespace of elements, as well as to define the structure of each element. Some XML parsers will try to download schema via a published URL to validate document. Enables tracking of schema usage. Will reveal if server performs schema validation. It will also allow the attacker to dictate the schema to validate against. The CDATA-tag allows any data to be stored in an XML element. It can be used to thwart input validation. XML injection is based on inserting XML elements as part of user controllable input into an XML parser. This could possibly be used to override non-user controllable data in the same document. If a text document is read using an XML stream design features of the XML parser might override information in the document. The lightweight SAX parser is known to be vulnerable. SOA Workshop – V2.0 15 Obfuscation XML Injection • • • • Copyright © 2006 Accenture All Rights Reserved.
Slide 16: Solution Strategy Validate your input! • Most attacks against a web service are based on poorly validated input. Well controlled input will enable you to gain full control over the data that is passed onto the application layer. • Due to the obfuscation possibilities it is highly recommended to validate using an XML aware validator. • Enable strict schema validation, and utilize only schemas that are defined by you and that are stored locally on your device. • XML schemas can define detailed requirements per field. This allows you to define allowed characters and field lengths. Challenges • Schema validation is processor intensive and requires a large amount of memory. Leaves application server vulnerable to denial of service attacks. • Validation will become a part of the application server stack. Introduces manageability issues. Copyright © 2006 Accenture All Rights Reserved. SOA Workshop – V2.0 16
Slide 17: Solution Products XML Security Gateways • Either server deployed software or appliance. • Functions as a SOAP proxy/firewall between client and application server. • Main features include: • XML Schema Validation • SSL Connection Termination • State aware routing of XML messages. • Denial of service protection. • Centralized security auditing for web services. • Most products support being clustered for increase performance. • Some products include hardware security modules for improved SSL and WS-Security performance. SOAP Stack Enhancements • Vendors provide some of the same functionality as extensions to their basic SOAP stack. Copyright © 2006 Accenture All Rights Reserved. SOA Workshop – V2.0 17
Slide 18: Functional Security Overview We have talked about security threats against an unprotected SOAP web service. • Protecting against SOAP attacks with an XML gateway or similar products will protect against malicious messages and denial of service attacks. • It will not give you access control, confidentiality or message integrity. • It will not give you easy security administration of your web services. What are the challenges? • Native SOAP does not include any security features. • Early adopters used transportation layer protection mechanisms, either HTTP or SSL. This does not protect messages when transported over other mediums (e.g. SMTP). Copyright © 2006 Accenture All Rights Reserved. SOA Workshop – V2.0 18
Slide 19: Solution Availability Matrix Transport Layer Identification / Authentication Authorization Confidentiality Integrity Accountability / Non-repudiation Administration HTTP Authentication SSL/TLS Authentication (using authenticated identity against directory or similar) SSL/TLS Encryption SSL/TLS Encryption Message Layer WS-Security SAML / XKMS WS-Authorization SAML / XACML XML-Encryption XML-Signature XML Schema Validation XML-Signature WS-Security / XKMS Copyright © 2006 Accenture All Rights Reserved. Transport Layer Security • Works only peer-to-peer. Will have to be re-established if message is relayed. • Protects entire conversation – session awareness available. Message Layer Security • Protects message and contents of message. • Protection persists across multiple hops – no session awareness SOA Workshop – V2.0 19
Slide 20: Security Recommendations Web Services Standards are still emerging, however preparation and implementation of basic federated building blocks should be considered now Preparation • Access control - Identify who you want in your circle of trust and how much you trust them. • Maintain identity – who initiated the transaction. • Audit – connected trail of activities important for compliance efforts. • Identity and Access Management (I&AM) – integrated into your Service Oriented Architecture to support the above. • Other technology controls – integrity and confidentiality as required. Implementation • Consumer portals should look to areas like Liberty and SAML to see if there are gains to be achieved from supporting some of the existing federated solutions • In areas where portal-to-portal single sign-on has already been custom-built, replace these with point to point SAML solutions • Use SAML for all new single sign-on initiatives that cross organizational boundaries Copyright © 2006 Accenture All Rights Reserved. SOA Workshop – V2.0 20
Slide 21: Contents • Security and Web Services Industry Standards WS* In Detail Platform Support Recommendations • • • • Copyright © 2006 Accenture All Rights Reserved. SOA Workshop – V2.0 21
Slide 22: WS* vs. Liberty Alliance WS* More generic framework Developed by Microsoft, IBM and selected vendors (e.g. Verisign, Oblix (now Oracle), SAP, RSA, etc) Subject to a somewhat ambiguous Royalty Free (RF) process • • • Liberty Alliance • • • • More purpose-specific solutions (identity federation) instead of a generic framework Developed by Industry, less vendor-centric: SUN, Vodaphone, IBM, Fidelity Investments America Online, Nokia, Ericson More open process  Competing and somewhat overlapping standards  Expect dust to settle in OASIS and WS-I Copyright © 2006 Accenture All Rights Reserved. SOA Workshop – V2.0 22
Slide 23: Standards: WS-Security The WS-Security initiative is driven by the OASIS standards organization, and led by Microsoft, IBM and Verisign. The goal of WS-Security is to construct secure SOAP message exchanges Initial Specifications WS-Security • Follow-on Specifications WS-Secure Conversation • • How to attach signature and encryption headers to SOAP messages. How to attach security tokens, including binary security tokens such as X.509 certificates and Kerberos tickets, to messages. The capabilities and constraints of the security (and other business) policies on intermediaries and endpoints (e.g. required security tokens, supported encryption algorithms, privacy rules). Framework for trust models that enables Web services to securely interoperate. Model for how Web services and requesters state privacy preferences and organizational privacy practice statements. How to manage and authenticate message exchanges between parties including security context exchange and establishing and deriving session keys. How to manage and broker the trust relationships in a heterogeneous federated environment including support for federated identities. How to manage authorization data and authorization policies. WS-Federation • WS-Policy • WSAuthorization • WS-Trust • WS-Privacy • Copyright © 2006 Accenture All Rights Reserved. SOA Workshop – V2.0 23
Slide 24: Liberty Alliance Project • • • • Federated Network Identity and Identitybased Services ID – FF 1.2 (Final:November 2003) Cross-Domain Single Sign-On Account Linking Mainly Browser Based Interactions ID- WSF 1.1 (Final: May 2004) Discovery Service Interaction Service Authentication Service ID-SIS 1.1 Personal Profile Employee Profile Contact Book GeoLocation Service Presence Service  Purpose-specific, deeply defined specifications Copyright © 2006 Accenture All Rights Reserved. SOA Workshop – V2.0 24
Slide 25: Standards lifecycle Developing (Not a Standard) Early Adopters Mature XML-Encryption XML-Signature Dec 2002* SAML 1.1 August 2003* WS-Security March 2004* WS-Security Extensions SSL/TLS Usage SAML 2.0 March 2005* Acceptance Copyright © 2006 Accenture All Rights Reserved. * Indicates the date that a Specification became an official Standard. 25 SOA Workshop – V2.0
Slide 26: Contents • Security and Web Services Industry Standards WS* In Detail Platform Support Recommendations • • • • Copyright © 2006 Accenture All Rights Reserved. SOA Workshop – V2.0 26
Slide 27: Interaction Model © 2001-2002 International Business Machines Corporation, Microsoft Corporation. Copyright © 2006 Accenture All Rights Reserved. SOA Workshop – V2.0 27
Slide 28: Standards: WS* Royalty Free specs under development Possible move to OASIS in the future WS-Secure Conversation WS-Policy WS-Federation WS-Authorization Undeveloped and Unpublished WS-Trust WS-Privacy WS-Security OASIS Standard Widely Supported W3C Foundation Standard Widely Supported SOA Workshop – V2.0 28 SOAP Copyright © 2006 Accenture All Rights Reserved.
Slide 29: Standards: WS-Security  SOAP Security Envelope  Message Integrity, Confidentiality,  Authentication of end points at message level WS-Secure Conversation WS-Policy WS-Federation  Multiple tokens supported: X509 Certs, SAML, Kerberos, etc WS-Trust WS-Security SOAP Copyright © 2006 Accenture All Rights Reserved. SOA Workshop – V2.0 29
Slide 30: Standards: WS-Secure Conversation  Provides Security Context for Series of SOAP msgs WS-Secure Conversation WS-Policy WS-Federation  Security Context establishment  Session Key Negotiation WS-Trust WS-Security SOAP Copyright © 2006 Accenture All Rights Reserved. SOA Workshop – V2.0 30
Slide 31: Standards: WS-Policy  Provides mechanisms for communicating policy requirements (confidentiality, WS-Secure Conversation WS-Policy WS-Federation authentication, etc) WS-Trust WS-Security SOAP Copyright © 2006 Accenture All Rights Reserved. SOA Workshop – V2.0 31
Slide 32: Standards: WS-Trust  Provides methods for issuing and exchanging security tokens  Supports ability to issue, renew, WS-Secure Conversation WS-Policy WS-Federation validate and delegate tokens  Independent of token format WS-Trust WS-Security SOAP Copyright © 2006 Accenture All Rights Reserved. SOA Workshop – V2.0 32
Slide 33: Standards: WS-Federation  leverages WS-Trust, enabling SSO  Includes own single log-out message  Profiles for front channel (Browser) WS-Secure Conversation WS-Policy WS-Federation and back channel (WS) use  Attribute and Pseudonym services WS-Trust WS-Security SOAP Copyright © 2006 Accenture All Rights Reserved. SOA Workshop – V2.0 33
Slide 34: Web Services Security Standards Technology / Standard SSL / HTTPS Security Benefit Confidentiality Integrity Authentication Non-repudiation Confidentiality Integrity Integrity Authentication Non-Repudiation Management Description SSL is an existing TCP/IP security protocol used to secure web communication at the transport layer. Expected Usage SSL can be used to encapsulate and protect Web Services communications from point to point. Parts of an XML document can be encrypted. Parts of an XML document can be digitally signed. Thin clients (can obtain key information (values, certs) to enable secure end-toend communications. SAML defines assertions that authorize an entity to perform actions on part of documents. XACML defines extensions to SAML that allow complex authorization rules. WS-Security defines a standard for including signature, Key Security Concepts: Authorization - verify that an entity is allowed to perform a requested action. Authentication - verify that an entity is who they claim that they are. Integrity - verify that the contents of a message have not been tampered with. Confidentiality - hide the content of a message from everyone except the intended recipient. Non-repudiation - the ability to correlate a message back to a specific person or entity without deniability. Administration and Management - the ability to centrally manage security services for users and applications. XMLEncryption XML-Signature Standard for encrypting the payload of XML SOAP messages. Standard that for generating a hash and signing XML SOAP messages. XML Key Management Standard – a specification that enables Web services to register and manage cryptographic keys used for digital signatures and encryption. SAML (Security Assertion Markup Language) is a standard for that enables the exchange of authentication and authorization information. XACML ( Access Control Markup Language) is a developing standard for defining Authorization Policy processing for SOAP Web Services request. Web Services Security is a burgeoning standard developed by major industry players that defines how to use XMLencryption and XML-Signature standards with Web Services SOAP messages.. XKMS SAML Authentication Authorization XACML Authorization WS-Security Confidentiality Integrity Authentication Non-Repudiation All WS-Security Extensions: WS-Security extensions are being developed to add improved security functionality to the WS-security standard SOA Workshop – V2.0 Copyright © 2006 Accenture All Rights Reserved. 34
Slide 35: Web Services Security Architecture Security Architecture Layer: How might all of the available security features fit together Web Services Consumers Web service communications can be secured at the transport layer using SSL . Wireless Apps Client Apps Web Browser Applications Enterprise ASP Business Partners HTTP Communication Channel – SSL Protected Web Services Security Layers XKMS is used to distribute keys to thin client applications. WS-Security Standards Encryption Signatures WS-Security Extensions PKI XKMS Algorithms RSA SHA 1 HMA C W3C XML Standards XML –Digital Signature XML –Encryption WS-security leverages XMLSIG and XML-ENC to sign and encrypt part of the SOAP messages. SAML and XACML are use to define authorization rules for the processing of SOAP messages Management systems are used to control the data that is used by the Web Service Security standards. These management systems may be in-house or out-sourced. Access Control SAML XACML Internal Administration and Provisioning Externally Managed Services Supporting Services Identity Management Policy Store Stores Authorization Stores Authentication Stores Enterprise Provisioning Solution Identity Managemen t Access Managemen t SOA Workshop – V2.0 Provisionin g PKI Copyright © 2006 Accenture All Rights Reserved. 35
Slide 36: Web Services Security Architecture Enterprise Security Architecture: A sample diagram of how security would fit into a typical web services application architecture Transport layer security through SSL Transport layer security through WS-security (extensions) and SSL HTTP SSL Business Partner Enterprise Partner Sites Web Service Client application Employees Internal policy enforcement and access control Protected Enterprise Data W Internet SSL Web Enterprise Customer Web Servers ( IIS, Apache) XK M S e AP atur S O ign S LXM XML-S SAML / X ig AC ML L ri t SS ecu S Sy Enterprise Data Application Servers (WebSphere, BEA, .NET) (Oracle, SQL Server, DB2) Lightweight PKI and Key distribution to a mobile user XKMS Wireless Application User Enterprise application servers Management and administration Certificate Management Server Copyright © 2006 Accenture All Rights Reserved. SOA Workshop – V2.0 36
Slide 37: Contents • Security and Web Services Industry Standards WS* In Detail Platform Support Recommendations • • • • Copyright © 2006 Accenture All Rights Reserved. SOA Workshop – V2.0 37
Slide 38: Vendor Landscape Accenture has divided vendors into three product categories • • Products from different categories can overlap in functionality Products can be combined to provide more complete security solutions Hardware Appliances Web Access Management Web Services Development Tools Copyright © 2006 Accenture All Rights Reserved. SOA Workshop – V2.0 38
Slide 39: Vendor Support WSS Username WSS -X509 WSS SAML WSS Kerberos WS-Trust WS-SC Copyright © 2006 Accenture All Rights Reserved. Hardware Appliances Web Access Management Web Services Development Platforms SOA Workshop – V2.0 WSE 2 WSE 2 Tivoli FIM 39
Slide 40: Contents • Security and Web Services Industry Standards WS* In Detail Platform Support Recommendations • • • • Copyright © 2006 Accenture All Rights Reserved. SOA Workshop – V2.0 40
Slide 41: Security Recommendations 1/2 • • • Check your requirements; Do not over-engineer Check WS-I recommendations in this Stick with well-defined specifications: • • ratified in OASIS, with profiling done in WS-I (e.g. WS-Security Username, X509, SAML) Large vendor support Username: requires directory X509: requires PKI; organizational authentication SAML: rich token, statements about individual users Kerberos: generally not suitable for cross-organizational authentication • Choose your token well • • • • Copyright © 2006 Accenture All Rights Reserved. SOA Workshop – V2.0 41
Slide 42: Recommendations 2/2 • • • Check and Double Check Vendor Claims There is great promise in the WS* specs that are still to be handed over to OASIS, but they can currently only be considered in closed PoC deployment scenarios Take an incremental approach to securing web services: • • do what is cost-effective and possible now: WS-Security add other features later when the dust has settled: WS-Trust, WS-Policy, etc. Copyright © 2006 Accenture All Rights Reserved. SOA Workshop – V2.0 42
Slide 43: Resources • Accenture Offerings • • Security Solutions home page – http://www.accenture.com/xd/xd.asp?it=enweb&xd=services\secsol\secsol_home.xml Web Services Offering – https://publishing.accenture.com/CIOAgenda/CIOAgendaOfferings/WebSvcs/WebServices.htm Web Service Interoperability Organization – http://www.ws-i.org Organization for the Advancement of Structured Information Standards http://www.oasis-open.org World Wide Consortium – http://www.w3.org Reactivity – http://www.reactivity.com Netegrity – http://www.netegrity.com Datapower Technology – http://www.datapower.com Layer 7 Technology – http://www.layer7tech.com • Standards Bodies • • • • Vendors • • • • Copyright © 2006 Accenture All Rights Reserved. SOA Workshop – V2.0 43
Slide 44: Contacts Security Practice Leadership Alastair MacWillson Stephen A. Barlock alastair.macwillson@accenture.com stephen.a.barlock@accenture.com +44 20 7844 6131 +1 650 213 2135 Global Lead U.S. Lead Securing Web Services Offering Dillon Boyer Christopher P. Miller dillon.boyer@accenture.com christopher.p.miller@accenture.com +1 312 693 9162 +1 312 693 0077 Copyright © 2006 Accenture All Rights Reserved. SOA Workshop – V2.0 44