Top 10 SOA Pitfalls: #8 – Security

Top 10 SOA Pitfalls: #8 – Security
Posted by Viktor Grgic in the early evening: May 5th, 2008

Last week Rik de Groot published the #9: Versioning. This week it's time for #8.

SOA security is like having a well-protected Middle Ages city, but at the same time asking citizens to permit many more people from inside and outside the city into their homes. They would really have hard time properly securing their belongings.
Introduction of SOA should be accompanied by at least SPRINT business impact assessment of security vulnerabilities (confidentiality, data integrity and availability) and definition of required measures. Introduction of SOA also requires rethinking your security architecture.

The following security problems have been introduced with SOA:

Authentication of end-users is delegated to consumer applications or MOM (Message Oriented Middleware). Applications which expose services can easily authenticate direct consumers or MOM. They are not aware of end-user's identity, their permissions and intentions
Security measures depend on the environment in which the application is being used. Unfortunately, the environment of a service changes with each new consumer. There is a tendency to introduce extreme security measures. This makes service a very expensive one, sometimes jeopardizing the business case for SOA altogether.
One of the security aspects is the availability (other two are confidentiality and integrity). Although we practice maximum loose coupling, there is certain amount of interdependency between consumers and services. If a crucial service goes down, then all consumers will also be unavailable. The irony of SOA is that the promise of reusability introduces this problem.

There is not one answer for these problems and there are many security technologies (WS-Security stack, XML Encryption, XML Signatures, SAML, and so on) and security patterns for solving them. The technologies are also very new and not yet mature enough in products like Enterprise Service Busses.

But before making your architecture very complex with all these technologies, there are few other interesting considerations:

Introduce a trust model where a service trusts its consumers within the organization or department context. It is the consumer’s responsibility to enforce most of the security measures (e.g. authentication, data integrity). This is against one of the general security principles, but often acceptable.
Propagate end-user context in each message received by service. This enables services or MOM to enforce traceability measures.
Services should always be stateless for easier implementation of fail-over and load balancing.
Prevent “doSomething” service definitions with query-like input, but define services for one purpose and task. This makes data integrity checks easier to implement and prevents exposure of functionality not required by all consumers.
Consider use of hardware appliances to secure communication between consumers and services. They have little impact on consumer's and service's architecture.

Security is often overlooked area. With introduction of SOA, it is advisable to rethink the security architecture (confidentiality, integrity and availability). One of the principles of SOA is that traditional barriers to reuse must be lowered. Traditional security approaches assumed and took advantage of these barriers. It is easier to secure an application when it's not open for reuse. This is one of the reasons why security in some situations makes SOA too expensive or even impossible to implement. It is a trade-off between interoperability and security.

Next week, Gero Vermaas will continue with pitfall #7.

Filed under SOA, Security | 2 Comments »

2 Responses to “Top 10 SOA Pitfalls: #8 – Security”

Top 10 SOA Pitfalls: #7 - Incorrect granularity of services | Xebia Blog Says:

Posted at: May 12, 2008 at 9:58 pm

[...] by Gero Vermaas at around evening time: May 12, 2008 After discussing #8: Security, let’s move on to [...]

Blog Xebia France - Les 10 pièges de la SOA : 08 - La sécurité Says:

Posted at: May 27, 2008 at 8:26 am

[...] Traduction libre du billet “Top 10 SOA Pitfalls: #8 – Security” publié par Viktor [...]