HAS解决方案要点
- Hadoop服务以及服务之间继续使用原先的Kerberos的认证机制；
- 在集群部署的时候可以把节点使用的Keytab放到可靠的节点上, 集群运行时，集群内的节点只有通过认证后才能正常使用。企图冒充的节点由于没有事先得到的密钥信息，无法与集群内部的节点通信， 从而防止了恶意的使用或篡改Hadoop集群的问题，确保了Hadoop集群的可靠安全；
- Hadoop的用户也可以继续使用熟悉的认证方式登录；
- HAS兼容MIT Kerberos协议，用户还是可以用password或Keytab这种方式进行认证；
- 在新的认证机制中可以定制实现自己插件与已经存在的认证系统结合；
- HAS中的新的认证机制采用plugin已有的认证系统，具有高可定制性；
- 基于新的认证机制安全管理人员不需同步用户账户信息到Kerberos的数据库；
- 没有用户账户信息的拷贝，降低了维护成本和信息泄露的威胁。
HAS协议流程：对Kerberos进行扩展
HAS兼容MIT Kerberos并对Kerberos的进行了扩展，使其能够利用token进行认证。HAS中提出的新的认证机制，我们命名为”Kerberos-based token authentication”, 流程图如图5所示。
图1
假设UserA想要访问HDFS，详细的步骤如下：
用户在命令行下面输入hadoop fs –ls 这条命令，Hadoop的shell会去调用HasClient
然后HasClient会去调用配置的好client 端plugin;
Client plugin负责搜集用户的认证信息，如password(建议不用)或已有的认证系统提供的一些临时的token等信息，把用户信息包装到AuthToken；
HasClient通过HTTPS将AuthToken发送给HasServer；
HasServer收到HasClient发过来的Authtoken后会去调用server 端对应的plugin;
Server plugin去已有的认证系统验证包裹在AuthToken中的用户身份信息；
如果验证通过返回给KDC一个验证通过的AuthToken；
KDC拿到这个AuthToken后会颁发一个Kerberos ticket
HasServer负责把Kerberos ticket通过HTTPs 发送给HasClient
上面的步骤相当于kinit userA的过程，但是相比于kinit有两个好处：
KDC可以不用预先存任何用户的信息
多个用户在同一时刻在同一台机器可以同时运行命令
HAS不依赖于Hadoop中的其他认证方法，所以对Hadoop的改动很少，并且Kerberos以及Kerberos在Hadoop中的使用已经经历了长时间测试和运用，HAS是基于它们实现的，大大减少了实现上的风险。
这里需要提到的一点是，Hadoop如果是使用Kerberos的password方法进行认证的时候，Hadoop只能从认证结果中拿到用户名的信息，然后通过其他方法拿到用户组等信息后再进行授权操作，但是 HAS中的新的认证机制”Kerberos-based token authentication” 在拿到KDC 颁发Kerberos ticket的时候，JWT token 会被封装到Authorization Data， Token中含有丰富的身份属性，当Hadoop的服务拿到这个ticket之后，可以通过解封这个token进一步使用token里面的信息进行细粒度的授权。
HAS核心和基础：Apache Kerby
HAS受益于Apache Kerby的基础性工作，以较少的开发成本实现了一种全新的针对开源大数据生态系统的认证方案。Apache Kerby是Apache Directory的一个子项目，是一个Java版本的Kerberos，具有以下几方面的功能和特点：
提供了全面的Kerberos客户端Library和工具;
提供了Kerby KDC: 高效、高可用;
强大的ASN-1支持;
TokenPreauth: 一个全新的token认证机制;
SimpleKDC 已在Hadoop的MiniKdc中使用(HADOOP-12911)
The Apache site: http://directory.apache.org/kerby/
Github project site: https://github.com/apache/directory-kerby
Apache Directory: http://directory.apache.org/
Kerby Developers List: kerby@directory.apache.org(subscribe@directory.apache.org)
HAS协议基础：TokenPreauth 机制
Token和OAuth被广泛地使用在互联网、云和移动端中，TokenPreauth机制在于寻求Kerberos身份认证和与基于token的系统相结合, 帮助Kerberos在云和大数据平台上发展。 Hadoop中也引入了各种token, 包括Delegation Token, Block Access Token和Job Token，但是这些token只是在用户通过外部Kerberos认证的之后供Hadoop内部使用的，不同于这里提到的token，这里的token是供外部认证使用的。目前TokenPreauth已经在Apache Kerby中实现，它允许用户使用第三方颁发的token来代替password向KDC进行身份验证。
图2
管理人员(Admin)配置Kerberos KDC信任的第三方Token Authority, Token Authority用于颁发JWT token, TokenPreauth的流程如图6所示：
在通过Kerberos访问服务之前，用户需要向token authority提供自己的证书，让后拿到一个JWT token；
用户可以把这个JWT token存在cache或者其他地方，然后用户JWT token向Kerberos KDC 申请Kerberos ticket；
拿到Kerberos ticket之后就可以访问Hadoop的服务。
高可用性
多个HAS Server共用一个数据库，建议选择具有HA的数据库，如ZooKeeper和MySQL；
在Client配置多个HAS Server；
如果Client连接Server超时或者拒绝连接，则选择另外的HAS Server重新发送请求。
图3
性能测试
考虑到性能的瓶颈在集群启动的时候，假设我们有一个1000个节点的集群，每个节点有5个服务，则在启动的时候会有5000次的服务认证操作。我们选取了两台普通的机器分别作为HAS的Server节点和Client节点，节点的配置如图7所示。我们选取了Mysql作为HAS的backend数据库，性能如图8所示，大概每个login的花费时间是几毫秒。
图4
图5
为什么选择HAS？
如果你是互联网公司或者云厂商，是否想把Hadoop集群的认证与自身的认证系统相结合？
云服务提供商或者互联网公司可以自己实现plugin来对接公司内部提供的用户认证系统。所选取的已经存在的用户认证系统需要提供能够验证用户身份信息的接口。
是否希望简化Kerberos的部署？
HAS提供了一系列的REST API和工具帮助简化部署。
是否希望定制自己的后台数据库？
目前HAS支持ZooKeeper，MySql等数据库, 同时HAS也提供了接口来方便用户自己实现其他数据库。
用户自定义认证插件接口
用户想要使用自己的plugin需要完成以下几步，如图10所示：
- 分别实现client和server的plugin, 接口如图11所示；
- 将client端的plugin jar部署到HAS的client端，将server端的plugin jar 部署到HAS的server端
- 在has-client.conf 配置好相应的plugin type；
图6
图7
HAS现状
目前HAS中提供的新的认证机制(Kerberos-based token authentication)可以支持大数据生态系统中的大部分组件，并且对组件的改动很少或者没有改动;
所有组件都可以使用HAS提供的原有Kerberos的认证机制;
使用HAS提供的工具可以简化部署;
目前已经有两个Release version: 1.0.0, 1.1.0
1.1.0版本增加了HAS系统跨域认证和互信支持，这个功能指的是用户和服务属于不同的realm，但是它们所属的realm有信任关系，那么就可以通过认证。另一个增加的功能是去除client端配置，方便client端的部署和使用。
下一阶段的工作
虽然目前已经能够支持大数据生态系统的大部分组件，但是仍然有些组件的支持并不是很好，特别是跟Web相关的组件，包括WebHDFS, OOzie等，这些组件现阶段只支持原有的Kerberos认证方式；
需要增加一个默认的 plugin实现作为example；
Renew, 这个工作需要依赖于TGT的落地；
授权，现阶段HAS只做了认证，就如前面所说，Token中含有丰富的用户信息，Hadoop可以拿到一些信息进行相应的权限控制;
Store the keytab files and credentials in Intel SGX
参考文献
Kai Zheng, Weihua Jiang ， A Token Authentication Solution for Hadoop Based on Kerberos Pre-Authentication