So-called "Freemium" Web Services involves basic services being offered for free, while charging a premium for advanced or special features. The word "freemium" itself is a portmanteau which combines the two aspects of the business model: free and premium.
Allowing some services in a SOA to operate in the freemium model is compelling, since it offers a path to a paying commercial model. However, the practicality is more complex. The model presupposes a SOA security framework which detects overuse and enforces payment for premium service usage. Usage must be authenticated so that the over-use of the service by a particular user is detected, and results in the user being asked to pay the premium fee. Usually this is achieved using so-called "developer tokens". These are tokens which are embedded into the Web Service invocations sent up to the service which is being offered. So, for example, a user can use a search service up to a certain point, but they cannot data-mine search terms without being detected, and then required to pay the premium fee.
When implementing the freemium model for services in a SOA, an organization has the choice of writing custom code to implement it, or to use an off-the-shelf product such as an XML Gateway. An XML Gateway provides advantages by allowing changes to be made to the parameters in the model without a requirement to change actual code. The XML Gateway also scans for the attacks which we have discussed earlier, such as malicious code injection.
Identity and Standards
It is important to know who is using the services of a SOA, and to use this information to control access and to maintain information within an audit trail. The task of controlling access to the services makes use of a variety of standards, some established such as X.509 certificates, and some new such as SAML and WS-Security. It is important not to be blindsided by the standards, especially when they are composed together in a complex manner.
The old and the new: Passwords, X.509 Certificates, and WS-Security
Passwords have been around since time immemorial. They are still widely used within SOA Security. In many cases, it is simply a case of HTTP Authentication, sent over SSL so that the password is not sent in the clear. Indeed, even if Digest Authentication is used, where the password is not sent in the clear, SSL should still be used in order to block certain capture-replay attacks. Even though HTTP Authentication over SSL is "old" technology, it still is widely used for point-to-point authentication within an SOA.
X.509 certificates are used in the context 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, since Web Services interactions often involve applications talking to applications, without a human being involved. So the "identity" is the identity of an application. And, as is the case in all usage of X.509 certificates, the trust is based on the issuer of the X.509 certificate (a Certificate Authority, often abbreviated to "CA").
As well as SSL, X.509 certificates are often used in the context of digital signatures. XML Signature is a standard which defines how XML data can be digitally signed using the private key which corresponds to an X.509 certificate, so that anyone who holds the signatorys X.509 Certificate can validate the signature.
XML Encryption is a standard which, as you may guess, defines how XML data may be encrypted. You may ask "what is different about encrypting XML data, versus encrypting any other kind of data?" The answer is that XML data can be selectively encrypted, allowing for scenarios such as selectively encrypting a patient name in a medical record. Since the messages in an SOA are mostly XML (with the exception of REST and JSON for Web 2.0 services), XML Encryption is very useful in order to apply privacy rules.
Kerberos is also a mature technology, which continues to be used within SOA Security. In particular, Kerberos is often used in a Windows environment, since it continues to underpin authentication and single sign-on in Windows networking.
All of these pre-existing security technologies continue to be used for SOA security.