Web services (WS) have been the subject of much talk and not without reason. With standards-based interoperability, potentially steep learning curves for adoption and use, and the opportunity to reliably communicate utilizing the low cost infrastructure of the Internet, WS hold considerable potential to bring about the long awaited flexibility and cost effectiveness to IT investments.
As with most other things in real life, however, things work when the necessary complementary conditions are there. For Web services a very important complement and an adoption driver is security. Security, or the guarantee that Web service communication can readily become confidential, with guaranteed integrity, available and accounted for, is a domain driven requirement that is heavily demanded in transforming a WS into a true business service. Combining WS and security not only meets the domain requirements of existing IT driven business models, however, but also opens up new opportunities for automated interactions between business partners. Adding WS and security together enables business models utilizing multiple known or unknown intermediaries, such as the one shown on the figure a paragraph down.
Before discussing the picture with a real life scenario, let’s look at the conceptual how-its-done from a WS point of view. Security in WS doesn’t make an exception from the other WS supporting technologies – it is based on standards, which makes it portable to various platforms. The standards are negotiated in the marketplace and in a broad outline describe the guidelines for the XML syntax to include security information to the XML documents that SOAP envelops actually are at a more technical level. The pre-eminent standards include WS-Security, username token and X.509 certificate token profiles for carrying authentication information in a WS message, as well as, XML encryption and XML signatures for integrity and confidentiality. Among these standards, the last two describe the value added functions to enable this scenario:
For example, following the communication patterns shown on the diagram and utilizing WS Security mechanisms empowered employees can log on to your ordering system to place orders from a WS provided by a Supplier’s system. With the help of the WS Security mechanisms, the empowered employees can also shorten the order cycle by adding payment information with the order for the Supplier to use with a WS provided by your Bank. also speeding up the receivables cycle of the Supplier.
To secure the payment information against the Supplier and/or other third parties the services involved would use XML encryption and a Public Key Infrastructure (PKI), supported by a Certification Authority (CA) shared with the payment service providing Bank, ultimately giving you end-to-end support for the ordering cycle. At the same time, by requiring XML signatures on all transactions, you can have an auditing trail, based on machine and human readable XML syntax, to audit transactions whenever necessary.
WS Security in SAP NetWeaver 04s
SAP NetWeaver 04s supports the use of WS Security at the application server level, thus making it easily available as a commodity to all enterprise applications that run on the server.
The online documentation provides ample information how to enable the WS Security framework provided by the AS ABAP and AS Java technology stacks. The configuration is template and wizard based and supported by the development infrastructure. Here are links to the documents with information how to enable the security settings for SAP NetWeaver systems acting as WS clients and/or WS providers:
WS Security for the AS ABAP stack
WS Security for the AS Java stack
Although there are some limitations, support for the WS Security standards username token profiles and XML signatures with X.509 token profiles lays the groundwork for leaving an auditing trail when using business transactions based on WS.
XML Encryption in SAP NetWeaver 04s and enabling the intermediary scenario
A read of the documentation links above will tell you that the WS Security framework of SAP NetWeaver 04s supports XML encryption the AS Java with the AS Java stack and only for a username token profile in a SOAP envelop. So it seems that if you were to go for an intermediary scenario, you’d have to entrust the intermediary partner with the security information to log on to your bank and carry out the credit check or payment information on your behalf – that is a lot of trust to lay on a partner in any case.
Using the Secure Store and Forward libraries of SAP NetWeaver, however, you can encrypt the payment document in compliance with the XML encryption specification. You do this programatically from the code of the application logic for the interface for the user interaction – be it a JSP web page, servlet, a Web Dynpro, portal application or a Java Bean – by placing the user input (the payment info to be read by the bank) in a XML document, encrypting it by retrieving a key from the SAP NetWeaver system’s keystore and sending the payment document as a string to avoid serialization constraints. For higher security requirements, you would also bundle timestamps and sign the encrypted document (again compliant to the XML signature specification and by retrieving a key from the SAP NetWeaver AS keystore). The WS provider would then follow the same programmatic approach to parse the string back in an XML document, readand verify the signature, verify the timestamp (or a one-time password nonce element) and ultimately decrypt the payment information with the SSF libraries, and approve and send the payment or credit info to the supplier.
Putting it all together
Before you start using such seamless, intermediary based transactions there are some things that require further consideration.
First and foremost, a consideration for return on investment is support for this solution in future versions. Fortunately, the decoupled nature of WS technology comes to the rescue here. That is, once an XML document is sent over the network in a standard compliant way, all the ultimate recipient needs to know to read it is that the document was written in a standard way. In other words, to ensure that your investment in taking the programmatic approach to using XML encryption in SAP NetWeaver will reap returns over a period of time is to programatically “compose” the document according to the OASIS specification for the XML encryption syntax and processing.
Adding XML encryption programatically is an advanced case of using WS Security in SAP NetWeaver 04s and it requires investment in development time and effort in adding the XML encryption functionality to the WS consumer and at the WS provider applications. So when making effort allocation decisions you should take into consideration the additional benefits (expanding partner network, cost cutting, etc) that result from enabling you to use blind WS intermediaries against the cost of the effort.
Another concern is the trade-off between speed and performance. Using XML encryption in your application utilizes cryptographic functions and they’re traditionally not easy on performance requirements. In addition, XML documents and the concept of structured information in general, although convenient for us people is not first nature to computing technology. Thereby, structuring the information in a document can add additional requirements to system performance and the time it takes to perform the whole end-to-end process – especially when encrypting larger documents. Of course, when talking about time here you’d refer to milliseconds or seconds and not days, which is what we would refer to for the whole order and payment cycle when executed on foot, or only with partial system support. In addition, the milliseconds can be expected to go down with enhanced and improved support of WS support in future versions of SAP NetWeaver.
The SAP NetWeaver 04s WS Security framework supported by the server lays the groundwork for having a document auditing trail with XML signatures for WS communications.
XML encryption and XML signatures are the real value added WS security mechanisms to enable harnessing WS Security mechanisms to implement advanced IT and service driven business models.
This year’s SAP TechEd includes a number of sessions that you can attend for more information on this topic, as well as current support and future trends in SAP NetWeaver. For more in-depth information about WS Security and a live demo you may want to look into AGS 215 XML Signatures and XML Encryption with the Web Services Framework, CD255 Developing Secure Web Services among others.