Hadoop服務以及服務之間繼續使用原先的Kerberos的認證機制；
在叢集部署的時候可以把節點使用的Keytab放到可靠的節點上, 叢集運作時，叢集内的節點隻有通過認證後才能正常使用。企圖冒充的節點由于沒有事先得到的密鑰資訊，無法與叢集内部的節點通信， 進而防止了惡意的使用或篡改Hadoop叢集的問題，確定了Hadoop叢集的可靠安全；
Hadoop的使用者也可以繼續使用熟悉的認證方式登入；
HAS相容MIT Kerberos協定，使用者還是可以用password或Keytab這種方式進行認證；
在新的認證機制中可以定制實作自己插件與已經存在的認證系統結合；
HAS中的新的認證機制采用plugin已有的認證系統，具有高可定制性；
基于新的認證機制安全管理人員不需同步使用者賬戶資訊到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的基礎性工作，以較少的開發成本實作了一種全新的針對開源大資料生态系統的認證方案。Apache Kerby是Apache Directory的一個子項目，是一個Java版本的Kerberos，具有以下幾方面的功能和特點：
提供了全面的Kerberos用戶端Library和工具;
提供了Kerby KDC: 高效、高可用;
強大的ASN-1支援;
TokenPreauth: 一個全新的token認證機制;
SimpleKDC 已在Hadoop的MiniKdc中使用(HADOOP-12911)
Kerby Developers List: [email protected]([email protected])
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
如果你是網際網路公司或者雲廠商，是否想把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中提供的新的認證機制(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