如何实现HMAC认证以RESTful API WCF [英] How to implement HMAC Authentication in a RESTful WCF API

查看:172
本文介绍了如何实现HMAC认证以RESTful API WCF的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们正在建设使用WCF一个RESTful API(目前的.Net 3.5,但会移动很快.NET 4)。我们有一个适当的功能框架,但它是目前不安全。这将需要从.Net应用程序,以及iOS版,Android和Web应用程序进行访问。

We are building a RESTful API using WCF (currently .Net 3.5, but will be moving to .Net 4 soon). We have a functional framework in place, but it is currently unsecured. It will need to be accessible from .Net applications as well as iOS, Android, and web applications.

我们想使用HMAC认证方案为这里和<一个描述 href=\"http://blogs.microsoft.co.il/blogs/itai/archive/2009/02/22/how-to-implement-hmac-authentication-on-a-restful-wcf-service.aspx\">here,但两个例子似乎说明如何验证哈希时土崩瓦解。第一个例子失败来形容的 UserKeys 对象(哈希表?),第二个例子是缺少 GetUserKey 在客户端和服务器端方法。

We would like to use an HMAC Authentication scheme as described here and here, but both examples seem to fall apart when describing how to validate the hash. The first example fails to describe the UserKeys object (hashtable?) and the second example is missing the GetUserKey methods on the client- and server-side.

任何人都可以提供一个解释如何用户键/令牌生成/存储/检索/在这些例子中如何使用使用或提供一个更好的例子(附源$ C ​​$ C,如果可能的话)HMAC授权在一个RESTful的WCF服务?

Can anyone provide an explanation of how the "User Key"/token is generated/stored/retrieved/used in those examples or provide a better example (with source code, if possible) of how to use HMAC Authorization in a RESTful WCF service?

编辑:
更多的研究后,我们决定了我们需要更多的授权技术,而不是一个的验证技术(语义?)。我们实现了基本的授权的保护和SSL背后的API。基本的授权的使用相同的授权头从Web请求的HMAC的验证的方案,但通过用户名:以Base64密码字符串连接codeD,而不是一个令牌。这使我们能够自定义验证对我们的数据库中的用户来确定用户是否许可,并有权访问所需的API方法适当的安全权限。

After more research, we determined that we needed more of an "Authorization" technique rather than an "Authentication" technique (semantics?). We implemented Basic Authorization and secured the API behind SSL. The Basic Authorization uses the same "Authorization" header from the web Request as the HMAC Authentication scheme, but passes a username:password string encoded in Base64 instead of a token. This allowed us to custom-validate a user against our database to determine if the user is licensed for and has appropriate security rights to access the desired API method.

我们肯定是开放的听力如何实现自定义的用户名/密码验证等方法进行固定API的其他选项。

We're certainly open to hearing other options on how to accomplish custom username/password validation and other methods for securing the API.

推荐答案

检索用户密钥仅仅是一个实现细节,你可以做你喜欢的,但是在服务器上它与用户名一起通常存储在一个数据库中的任何方式。

Retrieving the user key is just an implementation detail you can do any way you like but on the server it is often stored in a database along with the user name.

的基本方法是真正的简单。

The basic approach is real simple.


  1. 不知何故,服务器和客户端换取用户的共享密钥使用。这是可以做到你喜欢的任何方式,包括发送一个老式死树风格的信。很多时候这仅仅是用户输入的密码。

  2. 当客户要发送一个请求,他建立了完整的请求,然后使用密钥在整个邮件正文计算哈希值(和可选部分如果需要的邮件标题)

  3. 接着在客户端所计算的散列和他的用户名添加到该消息中的报头中的一个,并将其发送给服务。

  4. 服务检索邮件标题中的用户名和搜索私人KEU在自己的数据库中的用户。

  5. 接着,他又用密钥来生成其散列计算在邮件正文(和选定的头)哈希值。

  6. 如果客户端发送的哈希散列相匹配的服务器计算服务器知道消息被真正的客户端发送以任何方式没有改变。

真的是唯一棘手的部分是分享与用户密钥,并保持固定。这就是为什么一些服务允许生成具有有限的生命时间共享密钥,所以你可以钥匙交给第三方来代表您暂时无法工作。

Really the only tricky part is sharing a secret key with the user and keeping that secure. That is why some services allow for generation of shared keys with a limited life time so you can give the key to a third party to temporarily work on your behalf.

这篇关于如何实现HMAC认证以RESTful API WCF的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆