authentication - Spring Security-安全的远程密码协议(protocol)-SRP-身份验证提供程序

Question

当问这个问题时，我正在寻找有关实现自己的AuthenticationProvider的指导。我的意思是：

到目前为止，我了解到Spring Security会询问AuthenticationProvider对象，是否对用户进行了身份验证。目前我正在使用
DaoAuthenticationProvider将处理我自己的自定义UserDetailService返回的用户名和密码。一切都很好！
Spring支持许多不同的AuthenticationProvider，例如，有一个用于LDAP，Jdbc，DAO（如上所述），我什至能够为Kerberos找到一个。但是，SRP没有身份验证提供程序，因此需要编写一个。

我的问题如下：

当我们使用DaoAuthenticationProvider（即用户/密码身份验证）时，我们使用html表单，其中输入了用户名和密码，然后有一个按钮负责提交这两个参数。所购买的晴雨表通过某些传输通道传输到服务器，即一键即可将所有数据发送到同一http请求中，即身份验证所需的所有数据。可以在UsernamePasswordAuthenticationFilter中看到。这里的方法“ attemptAuthentication”采用“ HttpServletRequest request”，其中包括用户名和密码。到现在一切都很好。

 public Authentication attemptAuthentication(HttpServletRequest request, HttpServletResponse response) throws AuthenticationException {
        ...
        }

好吧，在简单的SRP中，我们还有一个包含用户名和密码的表单，除了密码!!!必须！不能通过网络传输。为了实现该限制，必须在客户端和服务器之间进行“讨论”，即必须交换以下参数。

1）用户名（I），

2）称为“ A”的值

3）称为“ B”的值

4）称为“ M1”的值

5）称为“ M2”的值

好吧，让我们假设有一个名为“ SrpAuthenticationProcessingFilter”的过滤器，如果新的身份验证协议更像是RFC 5054中的对话，那么该过滤器应该是什么样子。

   Client                                            Server

   Client Hello (I)        -------->
                                               Server Hello
                                               Certificate*
                                        Server Key Exchange (N, g, s, B)
                           <--------      Server Hello Done
   Client Key Exchange (A) -------->
   [Change cipher spec]
   Finished                -------->
                                       [Change cipher spec]
                           <--------               Finished

   Application Data        <------->       Application Data

在这里，我们有一个客户需要


a）首先发送他的用户名（I）
b）然后服务器需要使用值B进行响应。（在这种情况下，N，g，s并不是必须的）
c）客户端发送它的“值A”
d）客户端使用来自服务器的值B，并基于该值计算密钥。
e）服务器也根据值A计算密钥。
f）客户端将值M1发送到服务器。
g）服务器获取M1值，并基于具有M1值作为参数的公式，他能够验证密钥
匹配，如果购买方的计算键匹配，则
用户已通过身份验证，并且产品（即共享密钥）可以
进一步用于其他处理。


与用户名和密码身份验证相反，这是7个步骤，而不是一个步骤。其中3个需要在SrpAuthenticationProcessingFilter之前发生。现在，我知道可以将用户名与“值A”一起发送，从而缩短了步骤数，但我想严格遵循RFC。永远不要采取简单的方法吧？

问题实际上是我将负责客户端和服务器之间的乒乓（对话）的代码放在哪里，即上面提到的前三个步骤a，b和c。应该将它们放置在SrpEntryPoint对象还是其他地方。否则是否在SpringSecurity的上下文中？

我可以解决此问题的一种方法是使用websockets，但我也想使该身份验证独立于任何5-7层协议，例如websockets，http，spdy等。这意味着第一个实现应该是通过简单的http请求/响应，然后是任何其他协议。

因此，当前可能适合实施SRP的结构是：


SRPAuthenticationEntryPoint实现org.springframework.security.web.AuthenticationEntryPoint-这基本上表示如果对受保护资源的请求进入但该用户尚未通过身份验证，应该怎么做。在这里，我们可以在资源未经身份验证的情况下放置重定向。也许这也是负责步骤a，b，c的地方，不确定是否正确。要求指导和信息！！
SrpAuthenticationProcessingFilter扩展了GenericFilterBean。存在SrpAuthenticationProcessingFilter可以进行部分验证，例如检查srp参数是否收到正确且与服务器设置的srp参数对应。这里重要的是要提到SrpAuthenticationProcessingFilter并没有执行任何用户名验证，即需要在调用SrpAuthenticationProcessingFilter之前的一个步骤中进行，可能是SrpEntryPoint或我不知道如何调用它的其他步骤。 SrpAuthenticationProcessingFilter具有方法“ doFilter”，在其中创建第二个结构，即SrpAuthenticationToken。
SrpAuthenticationToken扩展了org.springframework.security.authentication.AbstractAuthenticationToken。在我的理解中，该令牌类似于DAO对象，该令牌映射了成功身份验证所需的所有字段。当将部分验证的参数填充到SrpAuthenticationToken中时，会将SrpAuthenticationToken传递到org.springframework.security.authentication.AuthenticationManager接口的authenticat方法中

myAuthentication = authenticationManager.authenticate（SrpAuthenticationToken）;


根据Spring Security配置中配置的身份验证提供程序，在我们的情况下将调用SrpAuthentication提供程序，即：

@Autowired
public void registerAuthentication(AuthenticationManagerBuilder auth) throws Exception {
        auth
          .authenticationProvider(sRPAuthenticationProvider);
}

SRPAuthenticationProvider-实现org.springframework.security.authentication.AuthenticationProvider。在此，对步骤d，e，f和g进行验证和比较。如果发生错误，则抛出新的BadCredentialsException（“ Invalid username / password / Verifiere”）异常。
SrpSessionValidator-这仅负责验证Srp会话的特定参数，将从SrpAuthenticationProcessingFilter以及在SrpAuthenticationProcessingFilter之前的一个步骤中调用，以验证用户名是否存在于数据库中。


我只对如何实现Srp身份验证有一个一般性的想法，因此，如果这一切有意义，并且SRPAuthenticationEntryPoint是步骤a，b和c的正确位置，我希望提出一些意见。对我来说，这感觉不合适。

任何反馈，不胜感激。

问候，

铁托

Addition1（2014年11月21日）->作为一个问题“在哪里放置负责客户端和服务器之间的乒乓（对话）的代码，即前三个步骤a，b和c”的答案那很可能是一个可以完成这项工作的标准（我称之为协商）过滤器。

现在，我想改一下这个问题，即在身份验证完成之前以及在接收M1和M2消息之前（即步骤1 2和3）。即它应该是该对象应生存的地方，例如60秒钟，然后在未收到M1和M2消息的情况下将其自动删除。我的意思是“ SecurityContextHolder”对象之前的某个对象。我只是不知道与Spring Security相关的对象/上下文的名称是什么，我也不知道这种构造是否存在？

Answer 1

我的方法是使用AJAX来运行协议的第一部分，直到在客户端创建A和M1，然后将其作为登录凭据发布到服务器，并使用Spring Security进行检查。

要查看它是如何工作的，有一个junit-js测试可以在Thinbus上使用TestSRP6JavascriptClientSessionSHA256.js在javascript客户端对象和java服务器对象之间运行相互认证（请注意，maven构建使用JDK javascript运行时运行此单元测试） ：

    // note the following exchange is written in javascript calling client js and invoking server java which is run by JUnit-JS using the JDK javascript runtime so it shows both sides of the full authentication in one unit test method

    // normal login flow step1a client: browser starts with username and password given by user at the browser
    client.step1(username,password);

    // normal login flow step1b server: server starts with username from browser plus salt and verifier saved to database on user registration. 
    var B = server.step1(username, salt, v);

    // normal login flow step2a client: server sends users salt from user registration and the server ephemeral number
    var credentials = client.step2(salt, B);

    // normal login flow step2b server: client sends its client ephemeral number and proof of a shared session key derived from both ephermal numbers and the password
    var M2 = server.step2(credentials.A, credentials.M1);

    // normal login flow step3 client: client verifies that the server shows proof of the shared session key which demonstrates that it knows actual verifier
    client.step3(M2);

显然，javascript客户端仅以 username和 password开头。服务器使用 username解析 salt并生成随机的 B。从服务器给客户端 salt和 B并生成其随机 A和 M1作为密码证明。以 step2作为参数的服务器 M1是检查用户密码证明的服务器，如果证明不正确，它将抛出异常。然后，服务器发送 M2，这是服务器证明它具有用户验证程序 v的作用，该操作是为了防止伪造的服务器欺骗真实服务器。

有一个浏览器的演示，该浏览器使用 Thinbus上的 thinbus-srp-js-demo通过AJAX对Java服务器执行SRP。您可以重新使用带有AJAX的JAX RS方法（例如Spring MVC AJAX）来执行在客户端创建 A + M1的第一步，然后使用登录表单post将其发布到Spring Security并具有Spring Security通过在服务器对象上运行 A来验证 M1 + step2，如junit-js测试所示。然后，您的 AuthenticationManager可以从由用户名键入的并发映射中解析AJAX创建的服务器对象。

一个小小的注意事项是，如果您对服务器使用HTTPS，我将考虑检查服务器证明 M2是否为可选。如果您不使用HTTPS，则服务器欺骗意味着他们可以为用户提供一个页面，该页面发送密码并忽略错误的M2。因此，M2证明不能在网页上下文中提供安全性。使用手机间隙等将html / js打包为本地应用程序的移动应用程序将受益于M2检查；可以在用户登录后将其添加到页面中以通过受信任的代码进行检查。