的ASP.NET Web API认证选项

哪些选项可用于要由来自另一个域jQuery的应用程序所消耗的MVC3的Web API应用的认证？的ASP.NET Web API认证选项

这里有约束/事到目前为止，我已经试过： -

我不想使用OAuth;与有限的用户群的专用应用我不能指望最终用户对现有供应商的账户，也没有范围，以实现自己的
我有一个全功能的HMAC-SHA256 FPGA实现使用中传递的数据就好了工作头;但是，这并不在IE工作，因为在CORS IE8/9坏了，不允许你送头
我需要跨域的消费应用程序是在不同的域的API，但不能使用JSONP监守它不允许你使用页眉
我想避免令牌（只）为基础的方法，因为这是开放给重播并且通过状态

在这一点违反了REST我辞去了HMAC-SHA256方法，它使用URL或querystring/post来提供哈希和其他变量。

在URL中把这些变量似乎只是脏了，并把它们在查询字符串/后是一种痛苦。

我成功使用JQuery $ .ajaxSetup beforeSend选项来生成哈希并将其附加到标头，但正如我所提到的，您不能在IE8/9中使用标头。

现在我不得不求助于$ .ajaxPrefilter，因为我无法更改beforeSend中的ajax数据，也无法只扩展$ .ajaxSetup中的数据，因为我需要基于ajax查询的类型。 $ .ajaxPrefilter也是一个问题，因为没有干净/简单的方法来添加所需的变量，这是方法不可知的方式...即它必须是查询字符串的GET和formdata的POST

我必须失去了一些东西，因为我无法找到一个解决方案： - 一）支持跨域一）不能同时在MVC和JQuery双方下的大规模黑客攻击）实际上安全 d）与IE8的工作/ 9

有有是有人在那里做这个正确...

编辑

为了澄清，在API方面的认证机制是好的...不管我验证请求哪种方式我产生的GenericPrincipal并使用该API中（这样做的优点是另一个职位，但它确实让我使用MVC的标准授权机制，这是我喜欢我自己的滚动...少对其他开发人员对我的API来学习和维护）

问题在于primarly在认证信息从客户端传输到API： - - 它不能依赖于服务器/ API状态。所以我不能在一次调用中传递用户名/密码，取回令牌，然后继续使用该令牌（打开重播攻击） - 任何需要使用请求头的东西都没有了，因为IE使用XDR而不是XHR其余的浏览器，它不支持自定义标题（我知道IE10支持XHR，但实际上我需要IE8 +支持） - 我想我坚持生成一个HMAC并将它传递到URL的某处（路径或查询字符串）但这看起来像一个黑客，因为我使用的请求的部分不是为此设计的 - 如果我使用路径有很多混乱的解析，因为至少我必须传递用户名，时间戳和散列与每个请求;这些需要以某种方式进行分隔，我几乎不能控制在其他地方使用的分隔符 - 如果我使用数据（querystring/formdata），我需要根据方法I更改我发送认证详细信息的位置使用（formdata POST/PUT/etc和查询字符串GET），我也用这些变量来应用层数据空间

尽管它不好，querystring/formdata似乎是最好的选择;但是现在我必须弄清楚如何在每个请求上捕获这些信息。我可以使用MessageHandler或Filter，但既不能提供便捷的方式来访问formdata。

我知道我可以只写所有的分析和处理自己的东西（它看起来像我这样），但关键是我不相信有没有一个解决方案了。这就像我有（1）对IE的支持，（2）安全和（3）干净的代码，我只能选择两个。

来源

2013-02-23 Aleks

你我的要求似乎有点不合理。你不可能同时拥有所有的东西，你必须愿意放弃某些东西。几句话：

OAuth似乎是你想在这里，至少有一些修改。您可以使用Azure的访问控制服务，以便您不必实现自己的令牌提供程序。这样，您就“外包”了安全令牌提供程序的实现。最后，我检查了Azure ACS仍然是免费的。当你寻找ACS文档时，有很多混乱因为人们大多使用它来插入Facebook或Google之类的另一个提供商，但是你可以调整它来成为你自己服务的一个令牌提供商。
你似乎很担心重播攻击。重播攻击几乎总是有可能的。我必须只听通过线路的数据并将其发送到您的服务器，即使通过SSL。无论如何，重播攻击都是你需要处理的。通常，我所做的就是跟踪即将到来的请求的缓存并将哈希签名添加到我的缓存中。如果我在5分钟内看到另一个具有相同散列的请求，我会忽略它。为此，我添加请求的时间戳（毫秒粒度）和URL的一些派生作为我的哈希参数。这允许每毫秒对同一客户端的相同地址执行一次操作，而不会将该请求标记为重放攻击。
你提到了jQuery，如果你使用散列方法，它会让我困惑。这意味着你实际上在你的客户端有你的散列算法和你的签名逻辑。这是一个严重的缺陷，因为通过检查javascript，我现在可以确切地知道如何签署请求并将其发送到您的服务器。

来源

2013-02-23 21:15:55 Ameen

Ameen，我同意你的评估，即某些要求似乎不合理，而且“不能拥有一切”。所有这些要求*一起*只会提供很少的选择，可能没有？ @Aleks - 为什么不只是ASP.NET表单身份验证？除了是一个令牌之外，它满足您的所有其他要求。至于重播攻击，我不确定其他方法如何更好地防止这种攻击？例如基本身份验证将更容易重播（或彻底的数据包嗅探）。 – Snixtor 2013-02-23 21:37:02

+1作为关于客户端签名的评论。这个问题确实意味着执行哈希的秘密实际上是在JavaScript中。 – 2013-02-23 21:43:59

所有的有效积分... ...回复： - 回复OAuth ...虽然我确实可以使用Azure之类的东西，但它增加了另一个我无法控制的外部系统。我有一些非常关注安全性的客户，这增加了不必要的复杂性; OAuth似乎对我想要达到的目标有点矫枉过正;但它是一个有效的选项 – Aleks 2013-02-23 23:46:59

简单地说;在涉及到身份验证时，ASP.NET WebAPI没有太多特殊之处。

我可以说的是，如果你正在主持这里面ASP.NET，您将通过ASP.NET得到认证和授权支持。如果您选择自托管，您可以选择启用WCF绑定安全选项。

当主办ASP.NET你的WebAPI，你将有几个身份验证选项：

基本身份验证
窗体身份验证 - 例如从任何ASP.Net项目可以以表单验证
Windows身份验证使Authentication_JSON_AppService.axd - 的HttpClient/WebHttpRequest/WebClient的
或明确允许您的WebAPI的方法匿名访问

来源

2013-02-23 18:06:18

感谢您的回复。回复您提出的选项： - 1）不能使用基本认证;正如我在我的问题中提到的，IE中的CORS支持不允许任何额外的头文件，身份验证就是其中之一。 2）表单不是一个选项，因为它是一个API，不会托管它自己的页面。这种机制也是有状态的，所以不适用于REST，并且它（似乎）以明文形式传递授权细节，并以确定性方式传递，这种方式对重播攻击是开放的。 – Aleks 2013-02-23 20:34:41

和... 3）尽管Windows身份验证并不是一个真正的选项（auth需要在应用程序内部处理），但这并不能解决将身份验证值获取到API的问题。4）整体观点是确保API，因此不允许匿名访问 – Aleks 2013-02-23 20:34:59

的ASP.NET Web API认证选项

回答

相关问题