在传统的C/S架构系统中，关于用户的安全机制主要围绕认证&授权进行。认证是指识别发起请求的用户(用户A)是否是合法的；授权是指发起请求的用户(用户B)是否具有发起该请求的权限。

通常对于特定的某次请求来说，被认证的主体即是需要被检查权限的主体，即用户A与用户B是同一个用户。这种模式对于直接的C/S访问来说并不存在什么问题，例如用户通过http访问web后台，那么登录的用户与检查权限的用户是同一个；又比如说，通过jdbc客户端直接访问mysql数据库，登录的用户与被检查权限的用户也是同一个。这种传统的架构是最为简单的：

但是在实践中，直接的C/S访问通常只出现在较为简单的服务架构中，更多的系统是更为复杂的C/S+模式，即服务器同时也作为更底层服务的客户端。比如在通常的web后台应用中，用户浏览器是最终端的用户(Client)，http服务器是最外层的服务器(Server)，而同时http服务器也是作为底层数据库的一个客户端(Client)，数据库则是第二层的服务器(Server)。架构如下：

但是在实践中，直接的C/S访问通常只出现在较为简单的服务架构中，更多的系统是更为复杂的C/S+模式，即服务器同时也作为更底层服务的客户端。比如在通常的web后台应用中，用户浏览器是最终端的用户(Client)，http服务器是最外层的服务器(Server)，而同时http服务器也是作为底层数据库的一个客户端(Client)，数据库则是第二层的服务器(Server)。架构如下：

  一般来说，这种架构足以应付大多数的场景，但对一些需要终端用户与更底层系统之间进行直接关联的场景来说，还是存在一些无法避免的问题，类似，底层系统无法感知到终端用户，导致无法对用户进行个性化的定制等；

方案三：impersonation(doAs)机制

       在目前hadoop生态中，用户可以通过多种方式对底层服务发起请求，比如可以通过jdbc直接操作hive服务、通过rpc直接操作hdfs，或者通过spark客户端直接提交spark任务等。同时，出于开发效率和规范化的考虑，各大企业也会在外层构建更为易用的各类统一数据分析工作台，比如cloudera推出的hue、以及apache的zeppelin notebook等。因此hadoop逐渐成为了一个既包含直接的C/S架构、又包含复杂的C/S+架构的复杂生态系统，如下图：

在这种架构中，由于既存在直接的终端访问(通道1)、又存在代理的终端访问(通道2)，hadoop服务需要同时兼容对这两种访问通道的安全控制，同时也需要保持行为的一致性(防止权限判断出错)。

       为了避免方案二中的问题，添加一种补充机制，hadoop生态中采用了impersonation(doAs)机制。简单来说，就是在方案二的基础之上增加了一种场景：当外层服务器(如web后台)需要对用户进行个性化的服务定制时，底层服务器(如hive服务)允许外层服务器将终端用户的信息附加在请求中，并以该用户的身份进行权限判断。

        举个例子来说，企业中的可视化数据分析工作台如hue等，通常是作为最外层的web服务器为用户提供直接的访问界面，在访问底层的大数据服务如hive时，以预定义的特定用户(如proxy用户)进行认证，同时将业务用户(如张三)的个人信息附加在请求信息中，传递到底层的hive服务器。hive服务器会以proxy用户的身份进行账号认证，然后又以张三的身份进行权限判断。

       在这种方案中，由于存在可以以其它用户的身份发起请求的“特殊用户”(非超级用户，因为本身不一定拥有所有权限)，也会存在一定的安全风险。因此在hadoop中，此类特殊用户一般都是服务级别的核心静态参数(hadoop.proxyuser.admin.*)所设置的，同时也会对可代理的范围进行限制，如限制用户发起请求的IP、以及用户自身所拥有的角色等，以防止潜在的账号被盗导致系统完全暴露的风险。