Creating Oauth-like MD2 Hash Keys for IBM Lotus Notes Domino Web Applications

01/25/2010 12:15 AM by Chris Toohey

Since my drivetime thoughts on mobile device authentication to SOTU -- my Remote Console Command Utility for IBM Lotus Notes Domino -- I've been giving the architecture some serious thought. I think, at this time, I've got it! To recap, I don't want each of the mobile devices to require authentication per se to SOTU, but rather create an Oauth-like, MD2 Hash Key that a Lotus Notes Domino Administrator could enter into their device. The more I think about it, the more excited I am to see this in practice... so while this write-up discusses the overall idea and keeps to architecture, be certain that I'll have a proof of concept of this technique hopefully as quickly as early this week.

As I am a firm believer in that old adage about pictures, so I thought the easiest way for me to explain the concept would be to give you a visual representation of the overall architecture of it:

SOTU sits on our Domino Server. A local client -- represented by the laptop in the above diagram -- authenticates either via Lotus Domino HTTP Authentication or Lotus Notes Client Authentication. Basically, we're just going to confirm that the authenticating party is who they purport they are... and once that's confirmed, we're going to do two things:

1. A key profile will be generated, tracking who made the request, and marry the requester with their randomly-generated MD2 Hashed Key.
2. Return the same MD2 Hash Key to the requestor, for use in their mobile devices.

(The more I think about it, I should simply create the whole thing from the mobile device client UX - an initial mobile device client browser authentication to the Lotus Domino HTTP server and there's no hassle.)

The requester can now share that MD2 Hash Key with any number of their devices (which have the SOTU mobile client installed, of course).

Now, that part is easy... and so is the next quite frankly.

Each and every HTTP Request that is submitted to SOTU is non-authenticated. Anonymous FTW! See, unless you supply a valid MD2 Hash Key as part of the HTTP Request, nothing happens. Without that key, the request is ignored!

To pull this off, ideally you'll want SOTU to have an HTTP Request Consumer Proxy to... well, quite frankly consume the HTTP Request and proxy that request (once we have a valid, active Key) to SOTU.

Like I said, easy.

This approach gives you the added bonus of being able to kill a given user's access to the system by killing the Key!

So... thoughts on this approach? Like I mentioned the other day, I'm going to keep this whole process pretty open and out there, so feedback rocks. Think this will work, or blow up in my face, or couldn't care less either way? Let me know via the comments on this post!

Tomorrow (when I wake up), I'll get started with the aforementioned proof of concept and test my theories!