This week's giveaway is in the EJB and other Java EE Technologies forum. We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line! See this thread for details.
I am not well versed in SOA, but one of the chief arguments I hear, especially from .net proponents, is that SOA represent high security risk. Is there a concern here and what is available to mitigate the risk?
Well i think by nature Web Services should be more concerned with security since they are a publicly available service that developers can utilize to get info from the company who wrote the web service.
Web servers/sites are different in the fact that they aren't publicly transmitting data for developers, they are more targeted towards a user who is using a browser. Also the html that is generated by a web server is static, it can't be changed by the browser or a developer who is directly accessing the html. There is no way for that developer to manipulate the content on the site and therefore there isn't as much of a risk.
On the other hand web services are meant to be used and developers can do many things with the functionality that is available. i.e. you give a developer the ability to place an order via a web service, you need to check to make sure the developer has the authority to place that order, etc.
I would also be curious at some other arguments to this topic, keep em coming!
SCJP 1.4, SCJD 1.4, SCWCD 1.3, SCBCD 1.3, IBM Certified Solution Developer -WebSphere Studio V5.0
I really don't think .NET proponents are the only ones who would say Web Services are insecure. Micrsoft along with BEA, IBM and numerous others created the security specifications like WS-Security and the WS-I Security specification. I think everyone would agree Web Services can be insecure.
Microsoft is supporting secure web services with WSE 2.0 (Micrsoft's current implementation of WS-Security, WS-Policy, etc) which shipped a few weeks ago.
Yes, Security should be a concern when using Web Services. This is primarialy because Web Services are different in that when you send a message to an endpoint, you have no guarantees. If you do not control both sides of the pipe security needs to be implemented on the message.
This is not a .NET or J2EE issue. It is a web services issue and it is being addressed.
Joined: Jan 23, 2002
I acknowledge that web services security standards aren't mainstream yet (i.e. most secured web services I've seen seem to rely on proprietary encryption methods), but SOA != web services. When someone claims that SOA is insecure, I'm inclined to think that that someone doesn't know what SOA is. The services in a service-oriented architecture need not be distributed, even.
As with any other application or technology, security is as much a concern as is required by the user. That is to say, if you're building a Wiki, security is much less important than if you're developing a financial interchange. Not every web site you visit uses https as its protocol. Web services will be the same way once the security standards are accepted and widely implemented.
In the mean time... If you really need security in your web service, the cool part is that, because the message can contain text, you can apply something like a public-key architecture to a section of message!
"Write beautiful code; then profile that beautiful code and make little bits of it uglier but faster." --The JavaPerformanceTuning.com team, Newsletter 039.
Web services security is a huge topic that is being addressed primarily through the WS-Security Framework specification. If you�re interested in a brief overview of this framework, you may want to read through an article I posted some time ago (http://www.ws-standards.com/WS-Security.asp). This article was later incorporated into the book.
One important aspect to understanding Web services security is the difference between transport and message-level security. The former relies on securing the entire transport channel, as we've been doing so far with SSL. Message-level security, however, implements security measures within the SOAP message that accompany the message to wherever it is going. This protects the message contents from intermediary services that may otherwise be able to access and process these contents. It can also improve performance, as only those parts of the message that are actually deemed sensitive can be secured.
Joined: Aug 28, 2002
Lasse, Thanks for catching me there. I must have misread the first post. I responded to 3 or 4 web service related post and had it stuck in my head. You are correct regarding SOA != Web Services. I did not mean to imply that they were.
WS-Security represents a framework consisting of a family of specifications. As a framework, it is still evolving, but some of the individual standards within the framework are, more or less, established. Several vendors have released products that deal with the uncertainty of this framework by providing server and client components that control the processing of authorization, authentication, and other security measures on both ends of a Web Service's message path. This, of course, is only useful if you've pre-arranged the distribution of this software with your messaging partner.