SOAP messages are set to a high level in XML, but most SOAP applications use Web Services Definition Language (WSDL), which is created in XML. SOAP`s XML structure makes it convenient for applications that expect their information to be provided in XML form, and the fact that SOAP can run on a variety of network protocols, including HTTP, means it can be easily routed through firewalls where other protocols may require special customizations. It is imperative to allow some services of an SOA to operate in the freemium model, as it provides a pathway to a paid business model. However, the practical aspect is more complex. The model requires an SOA security framework that detects excessive usage and forces payment for the use of premium services. The use must be authenticated so that the excessive use of the service by a particular user is detected and the user is asked to pay the premium fee. Typically, this is achieved with so-called „developer tokens.“ These are tokens embedded in Web service calls that are sent to the proposed service. For example, a user can use a search service up to a certain point, but they can`t extract data from search terms without being detected, and then has to pay the premium fee. X.509 certificates are used as part of SSL authentication, where a web service can prove its identity to a client, or in the case of two-way SSL, the client also proves its identity to the service.
In this case, „identity“ is amorphous because web service interactions often involve applications communicating with applications without human intervention. The „identity“ is therefore the identity of an application. And as with the use of X.509 certificates, the trust relationship is based on the issuer of the X.509 certificate (a certificate authority, often abbreviated as „CA“). Consider the following scenario: A service in an SOA is protected by a policy that ensures that service requests are digitally signed. That sounds certain, but is it? The answer is that this system is vulnerable to a replay attack that simply reads a valid signed message and thus gains unauthorized access. XML encryption is a standard that, as you can imagine, defines how XML data can be encrypted. You may be wondering, „What`s different about encrypting XML data compared to encrypting other types of data?“ The answer is that XML data can be selectively encrypted, allowing for scenarios such as selectively encrypting a patient`s name in a medical record. Because the messages in an SOA are primarily XML (with the exception of REST and JSON services for web 2.0), XML encryption is very useful for enforcing privacy rules. An XML signature contains a Reference element that references the signed data. The crawl application must „dereference“ (i.e., retrieve) the reference URI.
The XML signing standard states: „XML signing applications MUST be able to parse uri syntax. We RECOMMEND that they can dereference URIs in the HTTP schema. [RFC3075 – Syntax and Processing of XML Signatures]. However, this results in a vulnerability if the referenced data is spoofed, or simply a way to waste the recipient`s system resources by extracting a large file. SOAP is an integral part of the service-oriented architecture (SOA) and Web services specifications associated with SOA. Because it allows the sender to create a message route based on the logical services that must be applied to the message on the path to its destination, it is suitable for providing secure and compliant connections, controlling access, reliably delivering and retrieving errors, and supporting dynamic service detection. SOA without SOAP is hard to imagine. SOAP is a protocol that is almost always used in the context of a Web/SOA services infrastructure.
Therefore, the application programming interface (API) is typically hidden from the parent interface for SOA. There are SOA API middleware tools for almost every modern programming language, and Microsoft offers a variety of .NET SOAP/SOA tools. With so-called „freemium“ web services, basic services are offered for free, while a premium is charged for advanced or special features. The word „freemium“ itself is a portmanteau that combines the two aspects of the business model: free and premium. WS-Security is a newer technology that was standardized in 2004. It builds on what happened before. It defines how XML encryption and XML signature are applied to SOAP so that a SOAP message can be encrypted and/or signed. It also defines where X.509 passwords and certificates are placed in a SOAP message and how SOAP can work with Kerberos. This allows interoperability between different applications that use WS-Security. It`s tempting to get into a description of SOA security without first asking, „Why?“ Why should you impose certainty on SOA? An obvious answer is to protect the SOA infrastructure from attacks.