Mat*_*zer 5 .net authentication rest c#-5.0 .net-4.5
我正在为一些开发实现一组RESTful服务,其中一个是身份验证服务.
此身份验证服务验证两种身份:
这些RESTful服务是无状态的.
当客户端应用程序针对身份验证服务进行身份验证时,或者人或机器使用凭据进行身份验证时,两个操作分别生成AppToken和UserToken.
这些令牌是盐渍哈希,因此对RESTful基础架构的后续请求将在不共享AppKeys和凭据的情况下进行身份验证.
从完全无状态方法的角度来看,这些令牌不应存储在服务层中的任何位置,而应存储在某种客户端状态(fe,Web客户端将使用HTTP cookie存储它).这就是我目前的实现方式.
因为使用这些令牌重新验证每个请求并让服务层接收来自客户端的令牌,所以它可以比较来自客户端的令牌,并检查它是否是在服务层重新生成它的有效令牌并与之比较一个客户拥有的太贵了,我已经实现了一个服务层AppToken和UserToken,它们都有一个过期日期和一个所有者(为其创建了令牌的应用程序或用户),以便检查令牌来自客户端的存在于令牌存储中.
客户如何以交互方式取消身份验证？ 只是放弃客户端安全状态.如果它是Web客户端,它会丢弃身份验证cookie并只刷新页面,客户端将检测不到身份验证cookie,并且用户将被重定向到登录页面.
从RESTful服务的角度来看,这是一种无状态的身份验证:客户端不了解具有服务层伪身份验证状态的技巧.它只是一个服务实现细节 - 性能优化 - .
我不打算列出无状态服务的优点,因为我绝对相信这种方法是可行的方法,但我发现了一个问题:无状态身份验证/取消身份验证意味着客户端不会通知服务器他们关闭会话因此安全商店以大量无用的记录结束.
如果服务客户端的会话时间有限(fe,1小时,3小时,一天......),那么这不是一个大问题,但如果用户必须永久验证(8个月,一年)会发生什么)？.你如何区分什么是过期的令牌？
有一些方法可以解决这种情况:
每当服务层收到请求时,它都会更新令牌到期日期,因此自动化进程可能会丢弃那些已过期的令牌,这些令牌定义了令牌的任意到期(24小时制).
妥协体系结构的无状态特性,并让客户端通知服务层他们不再需要进行身份验证,因此服务可以将关联的令牌丢弃到客户端会话(但等等......如果客户端关闭Web客户端会发生什么？用户永远不会主动通知服务必须丢弃令牌......所以......僵尸令牌还没有,所以自动化过程应该放弃它们,但是......什么是僵尸令牌？我不喜欢这种方法).
完全无状态身份验证,无存储,每请求身份验证.
这是个问题!你的建议方法是什么 - 即使它不是1.,2.或3. - 为什么？
感谢这一长篇阅读 - 我真的相信这个问题的结论对任何人都非常有用 - !
无状态身份验证,基于令牌.假设传输级加密.
[X]SS - 由S的公钥签名的X.[X|Y] - 相同信封中的X和Y.Y [M]SY -> S - Y将签名消息M发送给S.目的: 客户C希望与服务S对话.
客户端C将其共享密钥或公钥发送给服务A,其中C知道端点和公钥().PKCPKA
A [now + interval | user-id or PKC]SA -> C
解释:
服务A将当前日期/时间的间隔添加为到期时间.在要发送的缓冲区中现在是到期日期和用户ID,(假设您有一个有效的身份提供者).PKC
[now + interval | user-id or PKC] = T
一个标志;
[T]SA
客户端C希望与后端服务S交谈.
C [[M|[T]SA]SC -> S
C将消息M加上它从A签名的令牌发送到服务S.
S关心C确实发送了它并验证了C 从信封中读取的签名.SC
S验证令牌的签名.失败意味着请求被拒绝.SA
S验证令牌:用户ID/正确和令牌日期> =现在.过期令牌意味着向客户端C发送"令牌过期"消息.如果令牌有错误签名,则权限被拒绝.[T]SAPKC
(可选; S授权C,题外话)
S执行工作并发送回客户端C.[M2]SS
这不会太多开销; 验证签名是一个非常快速的操作.
" C#使用Bouncy Castle使用RSA签名数据 "这一问题显示了如何签署和验证一段字符串,即您要发送的消息.
你需要证书; 如果您正在使用配置管理器(您应该这样做!;)),就像puppet一样,那么您创建一个证书签名请求(CSR),然后使用puppet对其进行签名.
有一种称为证书撤销请求的东西,它基本上是已经撤销且不被信任/使用的公钥的清单.将有和广播撤销,它基本上是要求客户做一套的行为证书签名请求轮.PKC
此外,如果您希望能够使特定令牌过期,请T在创建令牌时为令牌添加唯一ID(UUID/GUID),并且具有令牌撤销列表(类似于更改时广播),以便清除令牌UUID时的令牌UUID到期.因此,如果收到的T在其中,则服务也将检查令牌撤销列表.
看看软件巨头正在做的事情.例如亚马逊的REST接口,它使用共享密钥:
Amazon S3 REST API使用基于密钥HMAC(哈希消息身份验证代码)的自定义HTTP方案进行身份验证.要对请求进行身份验证,首先要连接请求的选定元素以形成字符串.然后,使用AWS Secret Access Key计算该字符串的HMAC.非正式地,我们将此过程称为"签署请求",并且我们将HMAC算法的输出称为"签名",因为它模拟真实签名的安全属性.最后,使用本节中描述的语法将此签名添加为请求的参数.
Mat*_*zer -1
选择的方法：完全无状态的身份验证和取消身份验证
最后，我得到了一个结论和一个协议，以便切换到完全无状态的基于令牌的身份验证和取消身份验证。
如何实现？
首先，这就是您需要对应用程序进行无状态基于令牌的身份验证（但用户身份验证将以相同的方式工作，不包括此清单）：
这是验证应用程序的流程：
客户端向认证服务发送认证请求。此请求必须包含应用程序密钥 (AppKey)。
身份验证服务接收先前发送的请求。
现在，身份验证服务创建一个应用程序令牌（AppToken），它是必要信息的自描述串联，用于跟踪依赖于身份验证服务的服务的具体经过身份验证的客户端。
AppToken是一个复合字符串（该组合可以是使用 JSON 序列化的对象）：
身份验证服务对步骤 #4 结果（JSON 序列化对象）进行加密。**使用 AppKey 作为对称密码的密钥或密码。就我而言，我将使用 Rijndael 来实现这一点。
后续请求将包含此令牌，以避免发送纯文本凭据。这些请求也将始终包含AppKey，因此身份验证服务将能够识别哪个应用程序正在尝试对请求进行身份验证。
一段时间后，令牌过期或无效，客户端请求新的 AppToken。或者客户端被用户关闭，并且没有持久存储来保存安全令牌，因此下一个客户端会话将在需要时请求新的。
有关此类身份验证方法的 .NET 实现的一些提示和详细信息：
我使用System.Security.Cryptography.RijndaelManaged类进行对称加密。AppKey 和 AppToken（在基于令牌的用户身份验证的情况下，它几乎是相同的解决方案）都是使用RijndaelManaged类生成的。
加密文本转换为十六进制字符串。这是与身份验证响应一起发送的。在我们的例子中（RESTFul API），表示AppToken的十六进制字符串将作为响应标头发送。每当请求包含此十六进制字符串时，身份验证过程都会将其重新转换为原始加密文本，然后将其解密以评估令牌是否有效。
感谢亨里克的努力。我在你自己的答案中采纳了一些概念，并将它们与我自己的结论混合在一起。
| 归档时间： |
|
| 查看次数： |
1423 次 |
| 最近记录： |