hey all, I'm interested in implementing a secure thrift service based on an HMAC approach.
Here's my use case: I have registered API accounts with secret keys. I want to wrap each message sent with an account-id, expiration time stamp, a nonce, and SHA1 hmac using the account's assigned secret key. I've used similar schemes for HTTP web service calls in the past. Thrift is a bit of a different beast though. I'm still trying to learn the roles, responsibilities and out of the box implementations of each layer to best determine where (and even if) something like this makes sense. I would like to utilize as much of the plumbing as possible in existing thrift code (cross language stuff). My gut tells me the "right way" to do this is to implement a new transport similar to the FramedTransport, that does the same buffering as the Framed Transport, but in addition to the frame size, adds the "security context metadata" (account id, expires, nonce, and hmac) to the stream. Clearly this will have performance and bandwidth issues. Another possible approach would be to move closer to the application layer and add the security context as an optional parameter to my methods that need authorization (request context). For HMAC to work, I would need a way to generate a deterministic SHA1 from the input request (other parameters). It be great to utilize the existing protocols (Binary / Compact Binary), but I don't think any of them are deterministic (e.g. the same data will produce the same exact binary each time on each language). Fields would need to be ordered (including hashes) and looking at the protocol API, I don't believe this is guaranteed (rather Message/Field begin and end markers are used). Not to mention that map is implemented as a hash in all languages. I would either need a new protocol that is deterministic, or an out-of-band application utility for generating HMacs for parameters. I wanted to bounce this off others to see I'm crazy, missing something that already exists, or if there is something else exists that can be leveraged. In the interim, i'm backing off message content based security and looking to leverage a simpler authentication mechanism over SSL and/or explore SASL some more. Related - has anyone had any success with SASL sockets between C, Java and Ruby? Cheers, ... Mike
