Security in an SOA environment must primarily address access control. It must be 'baked in.' In this interview,...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Gartner research VP Ross Altman explains the common security token approach to securing Web services.
In your view, what are the principal security concerns for SOA?
ALTMAN: You need to authenticate the source of a service request and for the service requester you need to authenticate the source – both are of equal concern. The other related challenge is authorization. Typically that would be authorizing access to the services for a service requester. It is not typically a symmetrical relationship because the service owner wants to protect access to the service.
There is also the concept of non-repudiation. Basically, you want to make sure that the source of the message can’t repudiate the sending of the message and, symmetrically, if you send a message you want to make sure the recipient can’t repudiate receipt of the message. I send a message in order to place an order. I want to prove I sent it and prove you received it.
Are there techniques or standards to help ensure security?
ALTMAN: There are some security standards. There is WS-Security, which is a standard way to authenticate and to provide for privacy and message security and it is used in association with something called Security Assertion Markup Language (SAML). Used together, WS-Security and SAML allow you to authenticate source and target. This allows you to secure a message by applying a security token, which is like signing the message. This token is something that no one else has. When you receive that message you can look at the token and verify that this message came from “me.” The other thing you can do is use that security code to encrypt the message so you end up with three capabilities:
1. You know it came from me if you use the code
2. The token can be used to verify the message has not been changed.
3. You can use it to encrypt the entire message, which will ensure that no one has been able to look at the message.
What’s happening now in SOA security or what are the biggest concerns?
ALTMAN: There is nothing massively new occurring but there are two observations you could make. One is about the “heavy duty” applications. That might be using SOAP as a way to form the message and WS Standards in order to guide implementation of those services and then applying WS security and SAML. Many people prefer to avoid these more formal, heavier weight web services, because it is difficult and challenging. It requires a great deal of additional cooperation between the service provider and the user. This can require money, and involve risk, time to market issues, etc. But if it is critical, for instance if there is money changing hands, the implications of a particular message being received or not are substantial and can justify the effort.
Then there is what some might call “lightweight” SOA. That is alternatively referred to as RESTful Web services. RESTful or Web–oriented architecture, which we see as a subset of SOA, is more Web-like, operating by taking advantage of Web principles, because you are directly leveraging the most fundamental aspects of the Web, like URLs and HTTP. And in the case of security you are using Secure Socket Layer (SSL) [or HTTPS]. That is another way of implementing security.
The interesting thing about SSL is that SSL implements security from one point to another, typically from a browser to a Web server – but not exclusively. It could be one server to another. And in many cases that is acceptable because of a number of reasons – predominantly that people think the major security issue is when stuff is passing over the open internet (from behind one firewall to behind another). But the ultimate arbiter is what is acceptable to the other parties.
How do you translate those observations into advice?
ALTMAN: People should understand all the security issues related to building their application and consider the strengths and weaknesses of different approaches to addressing security issues. Security isn’t cheap. SOA security requires a lot of collaboration between sender and receiver and in many cases a trusted third party, someone who can vouch for both of you.
SOA security isn’t something you can add on, it really has to be baked in. Of course, it is something you can “do yourself” but it requires foundational knowledge of security. Security for SOA can be a very messy subject. It is not simple and straightforward. You can’t simply inoculate and make it “done.”