A truly great question. I'm here at Oracle HQ presenting to a set of very smart architects, discussing message level security, and this is the question.
"Why go through the trouble of message level security if the service is behind the firewall?"
"The service is just accessed using HTTPS and Basic Authentication. What's wrong with that?"
The topic of message-level security vs. transport level/network level security is interesting (and not new). So here's my two cents:
Simpler is better - if you can get away with SSL or network level security - good for you.
So, this begs the question, what use cases require message level security. This is not an exhaustive list but, a few simple guidelines:
Asynchronous - especially long running transactions - having security in the message makes sense. Things like SSO cookies and SSL sessions will timeout.
Multi Party - transport is typically point to point, so you can encrypt something for one person - but not many parties. WS-Security supports the encryption of parts of the message.
"Truly Loosely Coupled" - In SOA, if you want to be able to send the message to any service, you can't count on what security controls other parties may provide, so if there is confidential information, best to encrypt it in the message.
Federated - When the message is going to change security domains (read: networks), conveying who the user and the calling service can easily be contained in the message using SAML. This use case is extended to include attributes. This use case assumes that in the other network it may be hard/impossible to validate the user's credentials, so trusting the message is the best bet.
So, if you're doing simple REST style services (stateless/synchronous) or RPC style API calls, look at the transport level - its probably sufficient and it is simple. Message level security introduces some additional complexity and effort, but is absolutely required to address many real-world use cases.
Wednesday, September 23, 2009
Subscribe to:
Post Comments (Atom)
This comment has been removed by a blog administrator.
ReplyDelete