本文主要是介绍ES Xpack Kerberos认证流程优化，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
小序
ES官方Xpack在服务端已经实现了Kerberos认证，会玩的小伙伴配置成功后，可以使用curl命令成功的发起认证请求；然而，由于RestClient客户端并没有默认集成Kerberos认证的能力，如果要使用Kerberos认证功能，必然要自己实现客户端传递认证token到服务端的逻辑，也可以把这段逻辑固化到RestClient.java或者RestClientBuilder.java中（笔者之前的文章中关于这块有大概的介绍）。
然而，还有一个问题，经过系统的测试，笔者发现Kerberos开启之后的性能几乎只有非安全模式的20%-50%（实测，如果测试用例不一样，可能结果和我这个也不一致），其实这个问题原因很简单，经过验证，发现每一次请求在ES的服务端都会验证Kerberos token的有效性，这样做固然安全，但是也就是这么个几乎不到ms级别的逻辑，导致了压测数据令人非常不满意。虽然我拥有了安全，但是性能也太低了吧，好吧，怪不得很多做过Kerberos认证的小伙伴那么讨厌它。
其实这个可以优化，其中一个优化逻辑就是使用Cookie机制，这也不是什么新玩意儿，如果有人接触过HW或者其他厂家的大数据平台，假如你使用过安全模式，又恰好注意到他们的请求Header的话，也许都会发现Cookie的蛛丝马迹。
说白了就是：既然你Kerberos认证慢，那我用Cookie打辅助，Kerberos认证通过的客户端可以不再验证Kerberos token，而是使用Cookie来简单的验证即可。
思路
- 客户端
- 客户端向服务端发送请求，假如是第一次认证（没有收到过服务端Response），那么采用Kerberos认证的方式发送Kerberos ticket到服务端去认证
- 假如不是第一次认证（服务端Response消息中有不能伪造的Set-Cookie），那么解析并判断Cookie的有效性，判断是否过期，是否符合格式等，如果一切正常，那么将Set-Cookie的信息转化为Cookie发送给服务端
- 服务端
- 判断请求中是否有Authorization的Header，是的话路由给Kerberos realm处理，再判断是否有Cookie，有的话走Cookie判断流程（仿伪验证），验证通过直接处理请求
- 假如没有Cookie，验证Kerberos token的有效性，如果验证成功，生成Set-Cookie的Header，并返回给客户端
- 注意：
- 为了防止伪造Cookie，服务端需要利用一定的方式对Cookie验证，最大可能降低非安全性（其实如果对业务逻辑完全了解，笔者认为也许Cookie就像一张白纸一样透明。。。）
- Cookie中最好必须携带认证通过的user信息，认证域信息，以及timestamp信息
- 设计良好的验证算法，保证Cookie验证的速度
实践
笔者阅读了源码后尝试的抛砖引玉的方案，注意，Kerberos不是ES官方的免费特性，小伙伴们在使用的时候注意不要引起不必要误会哦～～
- AuthenticationService类是ES官方所有认证域的入口类，在这个类中RestRequest以及ThreadContent会师，方便我们把请求中的Cookie信息传递给ThreadContent，即如果Header中存在Cookie Header，我们就put到ThreadContent的后续Header中，如果是Kerberos的请求，就会路由到KerberosRealm类去处理
- KerberosRealm类是Kerberos认证的入口类，关键的Kerberos认证逻辑都在这个类里面进行，必要的功能会分解到其他辅助类，在token方法中，负责解析ThreadContent，这个时候如果收到携带Cookie Header的请求，那么解析Cookie Header的内容作为认证Token，否则仍然解析Kerberos ticket作为认证的token；另外，authenticate方法负责在Kerberos认证成功的前提下生成Set-Cookie，假如不是第一次认证，每次都转发Set-Cookie给Response消息
- KerberosAuthenticationToken类负责真正的解析token，把token的本质面目揭示出来，发送给KerberosTicketValidator去验证
- KerberosTicketValidator类验证token是不是cookie格式的请求以及正确性，是的话直接认证，否则继续走Kerberos ticket的认证
- RestClient以及RestClientBuilder负责处理客户端Cookie响应逻辑，并且在Cookie即将超时、Kerberos subject即将超时、或者意外导致Cookie清空的情况下，刷新认证信息
经过笔者尝试，新的认证逻辑仍然比非安全模式（开箱即用的ES）性能上慢了10%左右，毕竟有所进步吧，记录以留念。
这篇关于ES Xpack Kerberos认证流程优化的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
