WebService_Security

8/7/2019 WebService_Security

http://slidepdf.com/reader/full/webservicesecurity 1/8

SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com

© 2008 SAP AG 1

Security for SOA and Web Services

Applies to:Enterprise SOA, Web Services, SAP NetWeaver.

For more information, visit the SOA Management homepage.

Summary

Service oriented architecture (SOA) enables loosely coupled applications to be assembled from a set ofinternal and external services (web services) that are distributed over a connected infrastructure. Thedistributed nature of SOA makes addressing security concerns a critical success factor. The primary concernin SOA is to establish an interoperable framework that enables security for services, applications, and usersin a trusted environment and complies with established corporate policies. The standards and techniques toprovide security in a SOA are evolving rapidly. This article will outline the security concerns and relatedstandards in SOA.

Author: Dipak Chopra

Company: SAP America

Created on: 25 March 2008

Author Bio

Dipak Chopra is a Principal Enterprise Architect in National Competency Center in SAP America.He has extensive experience on SOA platforms, technology and initiatives. Over last sevenyears, he has actively worked with customers, partners and consortia towards enabling criticalcomponents of SOA infrastructure.

https://www.sdn.sap.com/irj/sdn/soa-management








© 2008 SAP AG 2

Table of Contents

Introduction and Approach.................................................................................................................................. 3 Security Issues ................................................................................................................................................... 3

Message Security ............................................................................................................................................ 3 Trust ................................................................................................................................................................ 3 Distributed Policies .......................................................................................................................................... 3 Identity Management....................................................................................................................................... 3 Interoperability ................................................................................................................................................. 4

Security Standards and Technologies ................................................................................................................ 4 Message Security ............................................................................................................................................ 4 Trust ................................................................................................................................................................ 5 Distributed Policies .......................................................................................................................................... 5 Identity Management....................................................................................................................................... 5 Interoperability ................................................................................................................................................. 6

Summary ............................................................................................................................................................. 7 Related Content .................................................................................................................................................. 7 Copyright ............................................................................................................................................................. 8





© 2008 SAP AG 3

Introduction and Approach

It is assumed that the reader has basic knowledge of web services and security.

Web services are characterized by open standards (SOAP, WSDL, UDDI), a variety of implementationplatforms (J2EE, .NET, ABAP), and client devices. The presence of such diverse IT systems makes itnecessary to take an evolutionary approach that complements the existing infrastructure to address aplethora of security concerns, which poses one of the most significant challenges to realize the greatpotential of the integration and interoperability of business applications and systems.

This paper outlines the security issues in an SOA, the need for new security architecture, as well as relatedsecurity standards.

Security Issues

In the conventional enterprise application security realm, there is an underlying concept of a trustedcomputing base (TCB). The TCB provides mechanisms for enforcing a security policy that protects theresources within the controlled environment. This is equivalent to providing a security perimeter that protectsvaluable resources.

Web services don't have a clear notion of a security perimeter. SOA is a new approach to distributedcomputing, where application functionality is abstracted as business services that are location-independentand discoverable on the network. Web services architecture allows service composition, which may engage

many different service providers distributed across different platforms and enterprises. In such an openenvironment, distinguishing legitimate service requests from illegitimate ones becomes a challenge.

A secure SOA should address the following security issues:

Message Security

A message may have to hop through various intermediaries (e.g. Middleware such as the SAP® ProcessInfrastructure) to reach the final destination. It becomes critical to maintain the confidentiality of the sensitiveinformation so that no unauthorized entity can gain access to it. It may also be important to evaluate whetheror not the message was not modified in transit and ensure that the integrity of the message is maintained. Inmost of the B2B scenarios, it becomes important to establish the message authentication , which guaranteesthat the message was created by the claimed identity. In addition, non-repudiation is also an importantrequirement in B2B applications. Non-repudiation is about the guarantee that the sender can not later

repudiate and claim that he never sent the message.

Trust

As mentioned above, the intent of SOA is about the loose coupling of services. This loose coupling makesthe issue of trust quite explicit. The WS-Security specification defines trust as, "the characteristic that oneentity is willing to rely upon another entity to execute a set of actions." The trust issue has two aspects; oneis to specify the trust policies and the second is to broker trust between different security domains (alsoknown as spheres of trust).

Distributed Policies

Corporations want to make sure that any communication with the outside is compliant with the policiesthey've established. Policies are attached to all the related entities, client, service, and discovery. Policies areused to describe a broad range of service requirements and capabilities. For example, an organization mayuse a policy to define security requirement such as encryption. Policies are validated at the time ofinteraction and within the context of the interaction.

Identity Management

A client uses an identity (most of the time it is a user identity) to gain access to the service it needs. A typicalSOA solution is distributed over multiple security domains and there could be several identities attached to asingle user in different security domains. This poses some problems with traditional security approaches.The security infrastructures may vary among the various backend systems, so users may need to be

http://www.w3.org/TR/2000/NOTE-SOAP-20000508/



http://www.w3.org/TR/wsdl



http://www.uddi.org/



http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf











© 2008 SAP AG 4

authenticated for each system. The other problem is related to the SOA service composition layer, whichmight be calling many different atomic services falling under different security domains. The absence ofoverall security context makes it difficult to associate multiple user identities.

Interoperability

Although interoperability is not a security issue per se, it is a very important factor in making a typical SOAsolution work. Most of the web services specifications provide a number of mechanisms to do the samething, which lead to interoperability issues. For example, a sender can encrypt data using Triple DES, AES

128, AES 192, or AES 256 algorithms and the receiver can only decrypt AES 128.

Security Standards and Technologies

Is a web services security layer really required? To answer this question, one needs to look into the securityconcerns and try to address them using existing security technologies. The industry has a set of existing andwidely accepted transport-layer security mechanisms, such as SSL (Secure Sockets Layer), TLS (TransportLayer Security). Despite their popularity, SSL and TLS (which is a minor update of SSL) have somelimitations when it comes to web services.

SSL is designed to provide point-to-point security, which is not enough for web services becauseend-to-end security is required. In a typical web services environment where XML-based businessdocuments are routed through multiple intermediaries, it becomes difficult for those intermediaries toparticipate in security operations in an integrated fashion.

SSL-based communication provides security (confidentiality, integrity) at the transport level ratherthan at the message level. As a result, messages are protected only while in transit on the wire. Forexample, sensitive data received on SSL channel, once persisted, is not generally protected unlessone applies some encryption technology.

Finally, SSL does not provide element-wise signing and encryption. For example, if there is a largepurchase order XML document, and there is a need to sign or encrypt only a credit card element,signing or encrypting only that element with SSL is not possible.

All of these limitations make SSL and TLS unsuitable for most of the security needs of web services. In thelast couple of years, this gap has been identified by the industry and considerable effort has been invested toprovide a new security architecture to address the needs of SOA. It is important to realize that the newservice oriented security architecture must adhere to the essential characteristics of SOA.

Organizations have existing security infrastructures in place, which protect the resources on diverseplatforms. The fundamental goal of SOA is to enable the existing infrastructures to interoperate. The solutionis to enable a security spanning layer over existing security infrastructures with a SOA.

SOA enables organizations to build a set of reusable security services that can be used by businessapplications. The resulting reusability ensures consistent security policies across platform with reduceddevelopment costs. For example, an authentication function can be offered as service. Due to the distributednature of SOA, it is important that the standards-based architecture is adopted, which delivers interoperabilityand lets the infrastructure operate across organizational boundaries. In the last couple of years, much workhas been done to create security standards, which are very promising.

Message Security

Message security is about providing message confidentiality, integrity, non-repudiation, and exchangingsecurity credentials between web service client and web service.

WS-Security is an OASIS standard. WS-Security describes enhancements to SOAP messaging to providemessage integrity, message confidentiality, and message authentication. WS-Security uses XML Signature to provide message integrity and message authentication and uses XML Encryption to provideconfidentiality. WS-Security also provides a general-purpose mechanism for associating security tokens withmessages. Examples of security tokens are X.509 certificate, SAML assertion.

XML Encryption is a W3C recommendation. It ensures confidentiality of XML information transfers. XMLEncryption allows the parts of an XML document to be encrypted while leaving other parts open. WS-

http://wp.netscape.com/eng/ssl3/ssl-toc.html



http://www.ietf.org/rfc/rfc2246.txt



http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss


http://www.oasis-open.org/home/index.php



http://www.w3.org/TR/xmldsig-core/



http://www.w3.org/TR/xmlenc-core/





http://www.w3.org/

http://www.w3.org/

http://www.w3.org/

http://www.w3.org/












© 2008 SAP AG 5

Security provides processing rules for using XML Signature for SOAP messages. JSR 106 (XML DigitalEncryption APIs) defines a standard set of APIs for XML digital encryption services.

XML Signature is a W3C recommendation. It ensures message integrity and authentication. WS-Securityprovides processing rules for using XML Signature for SOAP messages. Signature can be applied over partsof an XML document. JSR 105 (XML Digital Signature APIs) defines a standard set of high-levelimplementation-independent APIs for XML digital signature services.

As mentioned above, in B2B applications, sometimes there is a need for message non-repudiation. Non-repudiation is required due to malicious senders who can later disavow having created and sent a particular

message. Resolving non-repudiation issue requires message authentication and sender authenticationsimultaneously. This can be achieved by using XML Signature for message authentication and SSL-basedsender authentication.

Trust

In a distributed environment like SOA, the two sides (client and service) need to establish trust before theycan interact with each other.

WS-Trust is an OASIS standard. WS-Trust defines extensions to WS-Security to provide mechanisms to getsecurity tokens and to establish trust relationships. For example, a client can send only X.509 security tokensand the web service can accept only SAML security tokens. WS-Trust provides a protocol to get the SAMLsecurity token by presenting the X.509 security token. By doing so, WS-Trust resolves the token formatmismatch; trust between client and web service can be established. This provides a great benefit as different

security infrastructures can interoperate with each other without significant changes.

Distributed Policies

In a typical SOA, where the client and the service may not be in the same security domain, policies enforcesecurity rules on the outgoing (client side) and incoming (service) messages.

WS-Security Policy is an OASIS standard. It describes how senders and receivers can specify their securityrequirements and capabilities. For example, a service can specify that it requires SAML token and signedmessage in the incoming SOAP request. WS-Security Policy is based on WS-Policy (a W3CRecommendation). WS-Policy is fully extensible and does not place limits on the types of requirements andcapabilities that may be described. It also defines a mechanism for attaching or associating service policieswith SOAP messages.

Identity ManagementAs SOA environments are typically highly decentralized in nature, identity management becomes asignificant challenge for web services. Identities can be stored in many directories as well as many differenttypes of directories, including proprietary username/password repositories, LDAP, Active Directory, andX.509 certificate stores. An additional challenge is that SOA may have requests that result in additionalrequests to many different applications at once. An SOA-ready service may be composed of many serviceoperations from many different services that each has their own identity. As part of a single transaction,many different services may be touched whether in parallel or in serial. Being able to authenticate and beauthorized across all of these systems seamlessly improves the user experience as well as performance -driving the need for a federated identity solution for SOA environments.

SAML (Security Assertion Markup Language) is an OASIS Standard. SAML provides a framework for theexchange of security credentials amongst disparate systems and applications in an XML-based format. WS-Security provides a SAML Profile that defines mechanisms to use SAML 1.1 within the context of SOAPmessages. The SAML 2.0, which is now an OASIS Standard, incorporated much of Liberty Alliance's work inan effort to become a unified standard for identity federation, which adds account linking, Single Sign-on/off,and improved facilities for establishing trust between organizations.

WS-Federation is an OASIS initiative. WS-Federation defines mechanisms to allow different securitydomains to federate by brokering trust of identities, attributes, or authentication between participating webservices. It is based on WS-Security, WS-SecurityPolicy, and WS-Trust.

http://jcp.org/en/jsr/detail?id=106








http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.html








http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.html





http://www.w3.org/2002/ws/policy/



http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security









http://www.oasis-open.org/committees/download.php/7837/WSS-SAML-15.pdf



http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsfed

























© 2008 SAP AG 6

Interoperability

In general, wide spread of adoption of security standards increases interoperability, but even differentimplementations of the same specification may not interoperate in some cases. Core specifications (WS-Security, SAML, etc.) are designed in a way to be extensible and provide number of options for doing thesame thing.

WS-I Basic Security Profile is a specification from WS-I to promote interoperability in the context of WebService security. WS-I isn't a standards development organization, but it works closely with a number ofstandards bodies - W3C, OASIS - to promote and utilize the right set of technologies in business scenarios.

The Basic Security Profile provides guidance for the use of web services security standards andtechnologies in the development of interoperable web services. The Basic Security Profile is aninteroperability profile that addresses transport security, SOAP messaging security, and other securityconsiderations. The profile provides specific security requirements, which can be tested on sender as well asreceiver side.

http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.html


http://ws-i.org/

http://ws-i.org/

http://ws-i.org/

http://ws-i.org/






© 2008 SAP AG 7

Summary

Despite the number of complex issues surrounding security in the SOA, the emerging security standardsoffer a lot. A significant amount of work has been done in designing security standards in a modular,complementary, and evolutionary manner. As the domain of security standards is becoming mature, majorweb services platform vendors (SAP, IBM, Microsoft, Sun) have started adopting these technologies. Thefuture of security standards revolve around three major topics: first the standardization of various WS-*specifications (WS-Trust, WS-Policy, WS-Federation) at least at the functional level; second, the

convergence of the identity federation specifications, SAML and WS-Federation; and third, the increasedfocus on interoperability.

Related Content

Getting Started: Web Services Security (WS-Security)

Getting Started with WS-I Basic Security Profile

Getting Started with XML Encryption

Getting Started with XML Signature

Getting Started: Web Services Trust (WS-Trust)

Web Services Security Cookbook: Using Web Services Technology in Mixed IBM & SAP Environments

Web Services Security Interoperability between SAP NetWeaver 7.0 and Microsoft Windows CommunicationFoundation (WCF) – Part I

Web Services Security Interoperability Between SAP NetWeaver 7.0 and Microsoft Windows CommunicationFoundation – Part II

Web Services Security Interoperability Between SAP NetWeaver 7.0 and Microsoft Windows CommunicationFoundation – Part III

For more information, visit the SOA Management homepage.

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/f9aa3d03-0b01-0010-96ad-d81b88c0b65f


https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/d6703c03-0b01-0010-1685-ac30eb4b3a03


https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/73e63e03-0b01-0010-3bb7-9b385e0af14b


https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/55814003-0b01-0010-1ca2-c683a191ebfc


https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/51ef27f0-0b01-0010-b88b-af2343513226


https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/92914af6-0d01-0010-3081-ded3a41be8f2


https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/e0ecb76a-2f70-2a10-8bb6-bf5d4f1fb750





https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/d08b1cb7-3070-2a10-0d8f-b30de80e1925





https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/108539c3-3270-2a10-53b5-cec522e4472a

























© 2008 SAP AG 8

Copyright

© 2008 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG.The information contained herein may be changed without prior notice.

Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.

Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.

IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries,zSeries, System i, System i5, System p, System p5, System x, System z, System z9, z/OS, AFP, Intelligent Miner, WebSphere,Netfinity, Tivoli, Informix, i5/OS, POWER, POWER5, POWER5+, OpenPower and PowerPC are trademarks or registered trademarks ofIBM Corporation.

Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe SystemsIncorporated in the United States and/or other countries.

Oracle is a registered trademark of Oracle Corporation.

UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.

Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks ofCitrix Systems, Inc.

HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, MassachusettsInstitute of Technology.

Java is a registered trademark of Sun Microsystems, Inc.

JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented byNetscape.

MaxDB is a trademark of MySQL AB, Sweden.

SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as theirrespective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. Allother product and service names mentioned are the trademarks of their respective companies. Data contained in this document servesinformational purposes only. National product specifications may vary.

These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAPGroup") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors oromissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in theexpress warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting anadditional warranty.

These materials are provided “as is” without a warranty of any kind, either express or implied, including but not limited to, the implied

warranties of merchantability, fitness for a particular purpose, or non-infringement.SAP shall not be liable for damages of any kind including without limitation direct, special, indirect, or consequential damages that mayresult from the use of these materials.

SAP does not warrant the accuracy or completeness of the information, text, graphics, links or other items contained within thesematerials. SAP has no control over the information that you may access through the use of hot links contained in these materials anddoes not endorse your use of third party web pages nor provide any warranty whatsoever relating to third party web pages.

Any software coding and/or code lines/strings (“Code”) included in this documentation are only examples and are not intended to beused in a productive system environment. The Code is only intended better explain and visualize the syntax and phrasing rules ofcertain coding. SAP does not warrant the correctness and completeness of the Code given herein, and SAP shall not be liable for errorsor damages caused by the usage of the Code, except i f such damages were caused by SAP intentionally or grossly negligent.

Documents

WebService_Security