What is Web Services Security?
After briefly explaining what a web service is and why this will become more and more important in B2B/collaborative scenarios and especially in Enterprise Services Architectures, this Weblog post will explain what the main concepts and pain points of web services security are and what configurations SAP offers.
What is a web service?
Web Services became very popular when businesses tried to connect their systems to do collaboration. However, a company that wanted to do business in an electronically supported way with another company had to start a big integration project connecting the different business systems (sometimes from well-known vendors, sometimes own-developed legacy systems) with each other. APIs had to be written that allowed for the exchange of business data. When one side changed their data definition due to further development or system upgrades, both sides had to adapt the API. Usually you did not only integrate one system with another (might or might not be from a different company), but many systems with each other that resulted in many different point-to-point connections that all had to be well maintained and be up-to-date in terms of API definitions but also security administration. This resulted in a huge integration project with a high load of ongoing administration and sometimes security weaknesses. How did you know that employee Miller left your business partner and was no longer supposed to get access to YOUR OWN business systems?
Standardization for collaborative business scenarios is now pushed by standards bodies like WS-Security, OASIS, etc.
One of the mechanisms supporting business integration is web services. A web service encapsulates the access of business functionality via for example http connections. It can be found, published and accessed using standards. The standards that are used to execute the web service are the most widespread standards available: HTTP and XML. The web services can be accessed via the http protocol and executed via xml. To communicate sender and receiver information SOAP (Simple Object Access Protocol) is used. SOAP works as the envelope holding the actual web service and communicating sender and receiver information. The web service is comprised of a SOAP header holding the users credentials and the body holding the actual web service. So-called WSDL files (Web Services Description Language) describe the standards used for the API. The WSDL files hold the description on how the web service has to be executed. That leads us to the last question: Where and how can web services be found and published? This is done via another standard: UDDI (Universal Description, Discovery and Integration). A business usually referred to as the provider, who wants to offer the execution of business functionality via web services publishes the web service in a UDDI directory. A business that wants to execute this web service (referred to as the consumer) can find the web service in this UDDI directory.
To sum it up, web services and the surrounding standards try to ease integration.
SAP supports the use and implementation of web services with both its Application and Integration Platform SAP NetWeaver. Specifically you can use both: the SAP Web Application Server and the Exchange Infrastructure (XI).
What are the main pain points in Web Services Security and how are they addressed?
One of the pain points is to make sure that the web service cannot be changed during transport from the sender to the recipient and that it cannot be viewed during transport. In addition you want to make sure that you really know who your communication partner is. In computer security these pain points are referred to as: Authenticity, that is you have gotten proper authentication and verified a users identity. Integrity, that is the data cannot be changed during transport. Confidentiality, which means the data cannot be viewed during transport. Non-repudiation, which refers to the fact that you cannot deny you did execute a functionality. To authenticate, users have various options ranging from User ID and password over smart-cards to Secure Tokens. If you also want to digitally sign, it might make sense to use X.509 Certificates as an authentication mechanism, as certificates not only allow for authentication but also for digital signatures and encryption. To ensure integrity and confidentiality web services security standards allow for digitally signing and digitally encrypting of the web service. To do this an XML framework is used in combination with a certificate. The XML framework is called XML signatures and XML encryption. SAP currently allows for XML signatures to digitally sign the web service and XML encryption for the message header that holds the user credentials. SAP will further enhance its features and functions for web service security within future releases.
Well, why dont we encrypt the communication path via SSL so that the whole communication gets encrypted and we do not have to do this XML encryption some could say? Indeed it is not a bad idea to encrypt the communication path via SSL. In web services scenarios this is called transport level security. However, SSL sessions have one drawback. End-to-end security related to SSL means that the communication path is only encrypted from one end to the other. Any intermediary between a sender and a receiver will terminate the SSL session. What is an intermediary? This can be a proxy, a dispatcher, etc. Some products allow for SSL forwarding like SAPs Web Dispatcher, but not all do. So we strongly recommend that you use so-called message level security via XML signatures and XML encryption as well.
Another pain point is the federation of Identities. Before we delve into the details here, what problems does Identity Federation try to solve? If you imagine you are a company and want to give your business partners employees access rights to your systems: Do you yourself want to maintain the business partners users and roll-out and reset passwords etc? Well, of course you dont. You want to FEDERATE identities with your business partners instead. You want to rely on the identities provided by the business partners. One of the technologies related to Identity Federation is SAML (Security Assertion Markup Language) that allows for user authentication and his/her identity federation. SAML an XML dialect will become the upcoming glue to perform Single Sign-On not only within one company but for a trust of companies to allow for intra-company Single Sign-On. The main mechanism is the so-called assertion.
In SAP language this means for example that a user is allowed to logon on to an SAP system PRD to client 100 or to the Enterprise Portal. The SAML standard offers the options to make use of policies (date, time of logon, strength of authentication mechanism), which result in different assertions and thus different access rights. The following example shall illustrate this. At Monday morning at 8:00 am your time zone you log on from an internal IP address. Thus you receive a SAML ticket with an assertion thatll allow you to access your companys productive systems. At 11 pm on a Saturday night from an outside IP address you receive a SAML assertion that only grants you access to your companys internal web page. SAP currently supports SAML in the so-called browser artifact scenario, where SAP accepts a SAML assertion that was externally pulled (created). This runs in the browser either via the Enterprise Portal or the SAP Web Application Server 6.30 or higher.
The last pain point mentioned in this Weblog post is audits. Most of you will be familiar with how time consuming and detail oriented it can be to audit a process performed in one single system. To audit a business process involving more than one system where web services were passed around gets even more burdensome. And now imagine were talking about a business process in an Enterprise Service Architecture, where systems from different companies are accessed. You are the Lordmaster of only some of these systems. Others belong to your business partner. How will you audit this large business process? SAP is working on the development of an audit standard called XaudML, an XML dialect that supports the data extraction of audit relevant data from business systems to a place where the audit can centrally be performed. This is called the Audit Warehouse. Current plan is to finalize the specification, have it approved by a standards body and then enforce its implemention into business systems.
SAP is actively engaged not only in enhancing its features and functions concerning web services security but also on the development and further enhancement of standards that can be used and implemented for integration in Enterprise Services Architectures, Web Services and Web Services Security. SAP has already implemented XML Signatures and SAML (browser-artifact scenario) and plans on further implementing WS-Security.