It's Friday for me, so here's your installment of Friday Morning Thoughts. Worse, I really only have two thought this morning: Weatherwise, its going to be a lovely day and man, Wheatfields makes some darn good Pain Perdu
I mentioned in Take Outs last night the need to write about protecting a Web Service. I came up with a fairly simple technique for doing this that suits specific pretty needs OK. Our goal was to avoid using SSL if possible (hard dollar cost) and to have our authetication self-contained.
The basic idea is that the Web Service "knows" a list of GUIDs, preferably the GUIDs of the consumer application. When a consumer wants to use the service, it must pass this GUID. But it isn't that simple: the GUID is combined into a delimited string prefaced by some random amount of salt characters. The resultant string is then encrypted before being send. The key used for encryption? The Web Service's GUID.
When the Web Service gets the request, it starts by decrypting this value, then parses it by the delimiter. The salt is discarded and the consumer's GUID is validated against a list of known consumer GUIDs. When matched, the web service proceeds.
As the Web Service completes it's work, the process is repeated into the response, except the service's GUID in encrypted into the responding string and the consumer's GUID is used as the key.
The consumer would then validate the response against the GUID it expected to get back. If the service doesn't answer back with the proper GUID, something wicked from that way came.
So its obviously not the most secure solution we could achieve. Obviously sending the data over the wire naked makes easy to ignore our security. But this isn't about data protection - its about consumer authentication.
Strengths
- Combats unauthorized use of services as well as man-in-the-middle and redirection attacks
- Enables the Web Service administrators to know what applications are consuming their services, so in the event of change, notifications are possible
- Easy to code, simple to implement
- Reasonably self-encapsulated
- Host change tolerant
- Regenerable but non-repeating credential
- GUIDs are easy to generate but hard to forge
- Could be used for versioning (assuming the signatures stayed constant)
Weakness
- Adds complexity to generating and parsing requests and responses (security is never free)
- Requires mutual registration
- Uses a shared-secret approach that may be communicated in an insecure way thus leading to compromise
- Doesn't change when service moves to a new host
So, is this good article material? Would you read it? If you are interested in seeing it as an article someplace (likely DotNetJunkies), please let me know.