7

I'm designing a Service Oriented Architecture, and I also do need an authentication service in order to recognize clients and allow them to access resources.

Actually I found two possible solutions:

  • sign each single request using a pubkey and privatekey
  • token-based authentication using pubkey and privatekey

I'm not assuming an oauth2 service since it would add too many overhead designing the system for my needs, instead I do prefer to adopt a simpler (but also strong) authentication solution.

So here I come with my AuthenticationService, that can either be queried by the client making the API request (obtaining a token to pass alongside the request) or be queried by each single API endpoint to perform a reverse check of the HMAC that signed the request to see if it matches (checking if the private key used to produce the HMAC was valid).

I can see the latest to be simpler for the final developer performing several operations, but it would also require more checks to validate the token and handle it's expiration...

What potential security issues could the token solution raise that the single-request HMAC doesn't? What do you prefer and, possibly, why?

  • what do you mean with _SOA authentication_?? are you building your own SOA suite?? SOA is compound of many technologies (Messaging, Web Services, BPEL, etc.), the SOA suite you'll be using should provide you with already-made means for authenticating your users on each request whether they come from outside the ESB or inside of it. – Alonso Dominguez Oct 03 '12 at 10:27
  • I mean that the whole architecture is built service oriented. All services do need to recognize who the user is in order to allow/deny the request, so I do need authentication, that will also be an independent service itself. –  Oct 03 '12 at 10:49
  • @AlonsoDominguez I edited the post body, you're right, maybe it could not be clear as "SOA Authentication". –  Oct 03 '12 at 10:51

1 Answers1

7

At the end I finally designed an authentication service based on the same Amazon solution. It requires users to sign each request using the private key. So the request will send an Authorization header with the value "PUBKEY:SIGNATURE", where the signature is a HMAC composed of any request data (it could be the request body itself) plus a timestamp, to be passed inside the Date header. This implementation is strong enough to avoid MITM and replay attacks.

For more info about this solution here is a great explanation that helped me a lot to understand the real implementation.

Hope this really help someone else in the world facing the same problem.

  • 3
    I've been very surprised over the course of the last 6 months that few people are talking about this exact issue. There's of course a ton of discussion around authentication and authorization of single apps and their web services, as well as federated identity using heavyweight stuff like Kerberos, CAS, SAML, etc. I keep coming back to forcing OAuth into service for this type of thing. Did you consider OAuth? What led you to implement your own solution instead? – Brendten Eickstaedt Jan 19 '13 at 15:35