事实上直到1995年的时候,SUN的研究人员才提出了一种满足以上需求的方案,这就是可插拔认证模块(Pluggable Authentication Module--PAM)机制,并首次在其操作系统 Solaris 2.3上部分实现。
可插拔认证模块(PAM)机制采用模块化设计和插件功能,使用户可以轻易地在应用程序中插入新的认证模块或替换原先的组件,同时不必对应用程序做任何修改,从而使软件的定制、维持和升级更加轻松。因为认证和鉴别机制与应用程序之间相对独立。所以应用程序可以通PAM API来方便地使用PAM提供的各种鉴别功能而不必了解太多的底层细节。此外PAM的易用性也较强,主要表现在它对上层屏蔽了鉴别和认证的具体细节,所以用户不必被迫学习各种各样的鉴别方式,也不必记住多个口令;又由于它实现了多鉴别认证机制的集成问题,所以单个程序可以轻易集成多种鉴别机制,如Kerberos和Diffie - Hellman等认证机制,但用户仍可以用同一个口令登录而且感觉不到采取了各种不同的鉴别方法。
在广大开发人员的努力下,各版本的UNIX系统陆续增加和提供了对PAM应用的支持。其中Linux-PAM是专门为Linux操作系统实现的,众多的Linux操作系统包括Caldera、Debian、Turbo、Red Hat、SuSE 及它们的后续版本都提供对PAM的支持。而FreeBSD从3.1版本也开始支持PAM。而且除了具体实现方法上多少有些不同外,各种版本Unix系统上PAM的框架是相同的。所以我们在这里介绍的Linux的PAM框架知识具有相当的普遍性,而且在下文介绍其框架过程中可以看到,我们并没有刻意区分Unix PAM与Linux PAM这两个技术术语。
PAM 为了实现其插件功能和易用性,采取了分层设计思想。就是让各鉴别模块从应用程序中独立出来,然后通过PAM API作为两者联系的纽带,这样应用程序就可以根据需要灵活地在其中"插入"所需要的鉴别功能模块,从而真正实现了在认证和鉴别基础上的随需应变。实际上,这一思路也非常符合软件设计中的"高内聚,低耦合"这一重要思想。
PAM 的体系如下简图所示:
从上面的结构图可以看出,PAM 的API起着承上启下的作用,它是应用程序和认证鉴别模块之间联系的纽带和桥梁:当应用程序调用PAM API 时,应用接口层按照PAM配置文件的定义来加载相应的认证鉴别模块。然后把请求(即从应用程序那里得到的参数)传递给底层的认证鉴别模块,这时认证鉴别模块就可以根据要求执行具体的认证鉴别操作了。当认证鉴别模块执行完相应的操作后,再将结果返回给应用接口层,然后由接口层根据配置的具体情况将来自认证鉴别模块的应答返回给应用程序。
上面描述了PAM的各个组成部分以及整体的运作机理。下面将对PAM中的每一层分别加以介绍。
第一层:模块层。模块层处于整个PAM体系结构中的最底层,它向上为接口层提供用户认证鉴别等服务。也就是说所有具体的认证鉴别工作都是由该层的模块来完成的。对于应用程序,有些不但需要验证用户的口令,还可能要求验证用户的帐户是否已经过期。此外有些应用程序也许还会要求记录和更改当前所产生的会话类的相关信息或改变用户口令等。所以PAM在模块层除了提供鉴别模块外,同时也提供了支持帐户管理、会话管理以及口令管理功能的模块。当然,这四种模块并不是所有应用程序都必需的,而是根据需要灵活取舍。比如虽然login可能要求访问上述所有的四种模块,但是su可能仅仅需要使用到鉴别模块的功能即可。至于如何取舍则涉及到接口层的PAM API和配置文件,这部分内容将在后文中加以介绍。
第二层:应用接口层。应用接口层位于PAM结构的中间部分,它向上为应用程序屏蔽了用户鉴别等过程的具体细节,向下则调用模块层中的具体模块所提供的特定服务。由上图可以看出,它主要由PAM API和配置文件两部分组成,下面将逐一介绍。
PAM API可以分为两类:一类是用于调用下层特定模块的接口,这类接口与底层的模块相对应,包括:
第二类接口通常并不与底层模块一一对应,它们的作用是对底层模块提供支持以及实现应用程序与模块之间的通信等。具体如下:
由于 PAM 模块随需加载,所以各模块始化任务在第一次调用时完成。如果某些模块的清除任务必须在鉴别会话结束时完成,则它们应该使用 pam_set_data()规定清除函数,这些执行清除任务的函数将在应用程序调用 pam_end()接口时被调用。
以上介绍了Linux可插拔认证模块PAM的基本概念和分层体系结构,在后续文章里,将会介绍常见的PAM模块应用以及相关实例。
学习资料来源于:
http://www.infoq.com/cn/articles/wjl-linux-pluggable-authentication-module
http://www.infoq.com/cn/articles/linux-pam-one