Encryption with SOPERA ASF
SOA and Security
Security is a very important aspect of the SOA implementation, and one of the distinct features that distinguish an Enterprise-level product from the many ESB implementations you can find on the market today. There are many aspects of security that are relevant for any IT system implementation. Here are the most important items:
| Security Aspect | Purpose |
| Authentication | Identifies the participants. |
| Authorization | Enables the participant with the correct permission set to call an operation. |
| Signature | Ensures that messages sent by participants are not modified by non-authorized agents. |
| Encryption | Ensures that messages sent to a participant can only be read by the participant for whom it was intended. |
You can find more information about software security terminology in Wikipedia.
SOPERA ASF Provides Security Features
In SOPERA ASF, the services cover all of these security aspects. All you need to do is to take care of your business code and then simply annotate your providers with policies. Your business code remains “blissfully unaware” of the associated complexity behind the implementation! This is where SOPERA ASF Infrastructure does all the “behind-the-scenes” work.
Looking Under the Hood
In this blog I would like to show you how things work under the hood. Before we start, take a look at: encryption with asymmetric keys. In short each participant has a key-pair, for example, key A and B. You can use both for encryption and decryption, but once you encrypt something with one key you can only decrypt it with another matching key. For example, once you encrypt a message with key A you can only decrypt it with key B, and vice versa.
Encryption of Service Consumers & Providers
To apply these concepts in a distributed SOA environment we need an infrastructure and protocols for that, and that’s what SOPERA ASF does for you. Picture this: the service consumer and provider exchange messages and one of them (or both) would like to keep the messages encrypted (you can imagine that they are communicating via a public messaging service like Amazon SQS or any other channel that could be compromised). Both the provider and consumer have a key-pair (private and public keys), but they need to exchange the public keys before they can communicate. For example, when a service consumer sends a message to a service provider it should use the public key of the service provider to encrypt the message so that only the service provider (who has an appropriate private key) can decrypt it.
SOPERA ASF: Solving Problems
All these problems are what SOPERA ASF is solving for you. For the public key distribution we use services provided according to the XKMS specification, and this is how it works:
Example
Encryption sequence
- Consumer encrypts a message to a provider using the provider’s public key which it received from the XKMS. Since the consumer trust the XKMS, it can be sure that only the provider is able to decrypt and read message
- Provider decrypts the response using its private key. Later it encrypts the request using the consumer’s public key from the XKMS (we assume that the provider also trusts the XKMS here), so that only the consumer can decrypt it.
- Consumer decrypts the response using its private key.
In the end the business code of both the SOPERA Provider and Consumer remain unaware of all the complexity associated with encryption and the business code can be implemented without any additional effort and it remains blissfully oblivious as to whether it is communicating with an encrypted or unencrypted service provider or consumer.