创建WCF服务应用程序时，我已经实现了UserNamePassValidator以进行自定义身份验证，这可以按预期工作。
但是由于服务上的大量功能，我将其解耦为不同的服务合同，例如库存管理服务，位置管理服务，任务管理服务等，然后我在不同的端点上公开了这些服务合同。在同一服务内。
这似乎工作正常，但我更喜欢的是对一个端点进行身份验证，并在所有端点上维护此会话状态。目前发生的事情是我对一个人进行身份验证，然后我可以访问该服务合同的功能，但如果我要连接到另一个端点，则需要我再次进行身份验证。
我目前的crutch解决方案是在客户端的表单之间传递ClientCredentials以进行身份验证，虽然它使用Message安全性，因此它们通过线路加密，但这显然不是理想的解决方案。
第一部分有解决方案吗？如果没有，那么在客户端将用户输入的凭证存储在内存中（在运行时）的最佳做法是什么。
答案 0 :(得分：3)
您可以实现类似于WS-Federation的方案。它是服务级别的联邦安全。
首先，您的身份验证端点应称为STS（安全性 令牌服务）。它的作用是验证并返回安全性 令牌给客户。
其次，所有服务端点都应该信任STS。什么时候 调用您应该传递STS安全令牌的端点 提供，以便端点能够读取该令牌和 认识到令牌是由受信任的STS发出的。
我已经在https://github.com/khoanguyen/Test-WS-Federation用Thinktecture实现了一个，但很抱歉我没有给出解释，你需要研究一下WS-Federation和Thinktecture以及WIF。但你应该知道这是可能的。
我用于移动项目的REST服务的轻量级解决方案如下：
我设置了身份验证端点。该端点拥有DSA私钥/公钥对。对客户端进行身份验证时，此端点会生成令牌并使用DSA私钥对其进行签名。然后我将签名和令牌组合在一起，并将其作为安全令牌返回给客户端。
在服务端点，我给了他们DSA公钥（来自身份验证端点的密钥对）。 DSA公钥用于验证安全令牌。
当客户端调用服务端点时，它会将安全性令牌作为HTTP消息的Header附加。然后，服务端点读取标头以检索安全令牌 - ＆gt;从安全令牌中提取令牌和签名 - ＆gt;使用DSA公开进行验证。
生成令牌的策略取决于您的需要。就我而言，我的令牌包含客户端的用户名，到期时间戳。通过使用DSA，黑客可以提取所有令牌的数据，但是他们无法改变它，因为他们必须拥有DSA私钥才能签署更改后的令牌。我们的工作就是保密私钥，不要在令牌中留下任何敏感信息（例如密码）。
这是非常便宜的方式。我不需要访问DB来验证用户，只需确保获得有效的安全令牌，令牌的数据仅用于额外需要，您甚至可以生成随机令牌并对其进行签名。不需要会话状态。