如何在RESTful WCF API中实现HMAC身份验证

我们正在使用WCF构建一个RESTful API(目前.Net 3.5,但很快将转向.Net 4).我们有一个功能框架,但目前没有安全保障.它需要可以从.Net应用程序以及iOS,Android和Web应用程序访问.

我们想使用此处和此处描述的HMAC身份验证方案,但在描述如何验证哈希时,这两个示例似乎都分崩离析.第一个示例无法描述UserKeys对象(哈希表？),第二个示例缺少客户端和服务器端的GetUserKey方法.

任何人都可以解释如何在这些示例中生成/存储/检索/使用"用户密钥"/令牌,或者提供如何在RESTful WCF服务中使用HMAC授权的更好示例(如果可能的话,还有源代码)？

编辑: 经过更多的研究,我们确定我们需要更多的" 授权 "技术而不是" 身份验证 "技术(语义？).我们实施了基本授权并保护了SSL背后的API.基本授权使用与Web请求相同的"授权"标头作为HMAC 身份验证方案,但传递用Base64编码的用户名:密码字符串而不是令牌.这允许我们针对我们的数据库自定义验证用户,以确定用户是否获得许可并具有访问所需API方法的适当安全权限.

我们当然愿意听取有关如何完成自定义用户名/密码验证的其他选项以及其他保护API的方法.

检索用户密钥只是您可以以任何方式执行的实现细节,但在服务器上,它通常与用户名一起存储在数据库中.

基本方法非常简单.

不知何故,服务器和客户端交换共享密钥供用户使用.这可以通过您喜欢的任何方式完成,包括发送旧式死树样式字母.这通常只是用户输入的密码.

当客户端想要发送请求时,他构建完整的请求,然后使用密钥计算完整消息体上的哈希值(如果需要,还可以选择一些消息头)

接下来,客户端将计算出的哈希值和用户名添加到其中一个标头中的消息中,然后将其发送给服务.

该服务从邮件头中检索用户名,并在其自己的数据库中搜索该用户的私有keu.

接下来,他使用密钥计算消息体(和选定的标头)上的哈希值以生成其哈希值.

如果客户端发送的散列与服务器计算的散列匹配,则服务器知道消息是由真实客户端发送的,并且没有以任何方式更改.

真正唯一棘手的部分是与用户共享密钥并保持安全.这就是为什么某些服务允许在有限的生命周期内生成共享密钥的原因,因此您可以将密钥提供给第三方以代表您临时工作.