Extending JAAS
Guosheng Huang, PhD, is a seniorsoftware developer withWysdom Inc. He has over 15years of experience in software engineering and technical architecture. gorsenhuang@yahoo.com
翻译：绿野风烟 2003/10
用户认证和访问控制是大多数java应用的重要安全尺度，特别是J2EE应用。Java认证和权限服务(即JAAS)，J2SE1.4和1.5的核心API，描绘表达了新的安全标准。其提供了一个可插拔的(pluggable)和富有弹性的(flexible)框架(framework)允许开发者混合不同的安全机制和丰富的已经存在各种安全方面的资源。
伴随着即将来临的J2SE1.5版本的发布，它包含了许多诸如加密技术、XML安全性、公钥机制（PKI）、Kerberos （是一个网络附加系统/协议，可以允许用户通过一个安全伺服器的服务来验证 自己。象远端登陆，远端拷贝，系统间的相互档拷贝和另外高风险任务的服务将被变 得相当安全和可控制。）和结盟认证（the federating identity）的增强！，JAAS将会在J2EE实现中扮演一个更加重要的角色。
认证
认证就是校验一个用户拥有使用已经被企业用户注册机构证明了的身份鉴定的权限的处理过程。JAAS的认证机制建立于一整套可插拔的模块（参看图1）基础上。JAAS允许不同的验证模型在运行时可被插拔。客户应用总是通过登陆上下文对象和JAAS交互。
认证处理过程典型的要经过下面的步骤：
1、 生成一个LoginContext对象。这个LoginContext寻找配置文件以决定使用那个LoginModule。同样，可选择的，有可能传递一个CallbackHandler给LoginContext.
2、 通过调用LoginContext的login方法执行认证，它会加载预定义的LoginModule去检验是否用户可以被认证。
3、 如果用户被认证，那么用规则和标识和其所属项进行关联。
4、 或者在登陆失败的情况下跑出一个LoginException
5、 使用LoginContext的logout方法进行注销登陆
在JAAS中，登陆是一个两阶段(two-phase)的处理过程。第一阶段是“登陆（login）”阶段（就像上面2所描述的）。这个阶段唯一的任务是认证。只要处理过程成功通过这个阶段，认证处理过程就进入了“提交(commit)”阶段（如上步骤3），这一阶段LoginModule的commit方法被调用去关联所属子项相关的规则和标识。
在JAAS中一个所属子项表示一个认证实体，比如一个人或者一台设备。它包含了一整套法则和安全相关的属性诸如密码和加密密钥。在JAAS体系结构中，所属子项和其所附属的相关权限，扮演了重要的角色在认证过程当中。所有的认证模块当中，LoginModule是事实上的认证机制的借口。虽然LoginModule决没有得到直接调用客户应用的机会，但是他经由一个可插拔的模块提供了一个认证的具体类型，其实现了认证的算法并且决定实际的认证过程是怎样被执行的。
SUN提供了几个默认的LoginModule 实现，在sun.com.security.auth.module包里有诸如JndiLoginModule,Krb2LoginModule,UnixLoginModule和NTLoginModule等几个LoginModule实现。因为JAAS登录结构体系是可扩展的，所以你只要在配置文件中指定使用哪个LoginModule模块就可以几乎全部插入任何LoginModule模块。
如下即为一个配置文件的例子：
MySample {
com.sample.module.MyLoginModule required debug=true;
};
这里MySample是登录上下文环境(login context)的名字，当你生成一个新的LoginContext开始认证过程时它会被传入LoginContex的构造函数中。依据配置块提示，那个文本块提醒JAAS有关LoginModule在登录过程中应该被用来执行认证。另外，对于LoginModule，任何关于他的选项也可以在这里被指定。在执行登录这一步骤的过程中，CallbackHandler类被LoginModule类用来跟用户通信已便于取得认证信息。CallbackHandler类处理三种类型的回调（Callback）：NameCallback,提示用户输入一个用户名；PasswordCallcack,提示输入密码；TextOutputCallback,报告错误、警告或则发送给用户一些其他信息。
授权是决定是否认证的用户可以执行一些动作的工作，例如访问一处资源。因为JAAS建立于已经存在的Java安全模型的基础上，故这个过程时基于策略的。策略配置文件实质上包含了一系列的入口，诸如“Keystore”和/或“grant”.
grant入口包含了所有的权限，他是通过认证的代码或则法则被授予可以进行安全敏感的操作，例如，访问一个具体的Web页面或则本地的文件。JAAS支持基于法则的策略入口，赋权入口基本格式如下：
grant Codebase “codebase_URL” Signedby “signer_name,”
Principal principal_class_name “principal_name”,
Principal principal_class_name “principal_name”,
… {
permission permission_class_name “target_name”, “action”,
permission permission_class_name “target_name”, “action”,
…
}
上面格式中“动作（action）”可能是必需的或则可能被忽略依赖于权限类型。在JAAS体系结构中，策略对象表达了一个Java应用环境的系统安全策略和在任何时间事实上只有一个策略对象。依据Java2 SDK文档，默认的策略实现是sun.security.provider.PolicyFile,其中策略被指定在一个或多个策略配置文件里。
只要用户被认证，授权经由Subject.doAs方法发生，或者从Subject类的静态方法doAsPrivileged，doAS方法用当前的AccessControlContext动态和子项并且同时调用run方法去执行动作，他导致安全验证。权限验证过程通过下面的步骤在图2:
就像LoginModule,策略也是可插拔的模型。你可以挂上其它的策略实现通过在java.security的属性文件中改变“policy.provider=sun.security.provider.PolicyFile”
到一个你项使用的策略类。
Extend JAAS
JAAS建立于已经存在的Java安全模型的顶端，其基于“CodeSource”和平面文本格式策略文件实现。这可能对企业应用是不够用的，你可能想使用可定制的安全仓库。对于JAAS的其它实现,诸如LDAP(轻型目录访问协议)，数据库或者其他文件系统，它可以通过编写你自己的可定制模块被完成，感谢JAAS的可插拔的特性。然而，这需要对模块和JAAS中的处理过程有完善的理解，同时你必须做许多编码去覆写相关的类，并且处理好配置和策略两种文件。
理想情况下，我们愿意能够扩展JAAS以一个更加容易的方式以便于无论何时一个可定制的安全知识库或者不同的访问控制机制改变或者必须去增加时，你能够只开发和插入这些不同的小模块（即，适配器）去适应这些新的变化和需求，并且在最好的情况下，不必去理解和熟悉JAAS处理过程的细节，同样，我们也愿意能够去做这些变化仅仅通过改变一个配置文件。另一个目标是我们的JAAS扩展组件能够被使用在不同的J2EE应用中—独立的或者Web上的。图3描述了JAAS扩展组件的设计意图。我们的JAAS扩展组在实现可定制的LoginModule和策略模块时充分件利用了JAAS插拔式的体系结构。这些模块中，我们委派数据请求到适配器。这些适配器的每个对于诸如数据取回的简单任务是隔离的，所以你可以快速地使用不同的安全知识或者算法开发不同的适配器而不是尝试去实现不同的LoginModule或者策略模块，它们更加复杂并且需要更多的努力。
你可以从www.sys-con.com/java/sourcec.cfm.下在完整的源玛。
实现的AuthLoginModule类
AuthLoginModule类是我们定制的LoginModule实现，LoginModule类是在JAAS中是一个可插拔组件并且服务于两个目的：
1、鉴定认证用户
2、如果认证成公，则用相关的负责人信息或者证书更新主题。
LoginModule有5个方法去实现功能，让我们关注一下login()方法。这个方法被调用以认证主题并且主要作两件事情：
1、包含用户名和密码，典型地，LoginModule要调用CallbackHandler类的handle方法去得到用户名和密码
2、通过和数据源中的比较校验密码。LoginModule从Callbacks取回用户名和密码。(其默认期望用户接口的某种排序)，这一点对于一个简单的演示程序或者就在命令行，可是他对于一个J2EE应用来说不太实用，例如，对于大多数的Web应用，用户名和密码将比较典型的从一个form中读出。在这种情况下，使用JAAS认证会比较困难。考虑我们不直接使用LoginModule,解决方案是实现一个可定制的CallbackHandler类，他会接收用户名和密码然后递交它们给LoginModule，所以他没有必要提示用户输入信息
以下示例説明用户信息如何从JSP或者Servlet中传递：
String userName = request.getParameter (“user”);
String password = request.getParameter(“password”);
LoginContext context = new LoginContext (“MySample”,
new AuthCallbackHandler (userName, password));
一旦拥有了用户名和密码在手，AuthLoginModule类，我们的LoginModule类的定制实现，会经由LoginSourceAdapterFactory实例化LoginSourceAdapter并同时委派实际的认证过程到资源适配器。适配器只不过是一个简单的类，其从一个具体的数据适配器（比如数据库或者LDAP,或者一些别的系统）领取用户信息。在“提交”阶段，AuthLoginModule类从LoginSourceAdapter类取回相关的信息并且把他们和主题相关联。
LoginSourceAdapter类
LoginSourceAdapter类是一个认证目的的资源适配器的接口，它有4个需要实现的方法：
1、void initialize(Hashtable parameters):initialized方法被调用来以相关的参数初始化适配器。此方法在对象生成后立即被调用并且优先于任何对其他方法的调用。
2、boolean authenticate(String username,char[] password):此认证方法被调用来认证用户。
3. String[] getGroupNames (String userName):getGroupNames方法被调用来在认证成功后得到相关的主要信息。
4. void terminate ():这个方法在LoginModule类的logout方法被执行后调用，它给适配器做一些清理工作的机会。
AuthPolicy类
在JAAS架构下，安全策略被java.securety.Policy 类来处理，他会证明赋给一个具体的代码源或者主体的多种权限。就像在上一段被讨论的，sun.securety.provider.PolicyFile是其默认实现。PolicyFile类使用平面文本文件去证明在权限和代码源之间的对应关系，这点对于企业级应用可能不是太好。一个集中的系统比如支持基于角色的安全性的关系数据库将会更好。很明显，扩展JAAS授权以处理不同的来源的不同的安全标记，我们需要写我们自己的策略实现。
生成一个定制的策略实现的步骤如下：
•扩展java.securety.Policy类
•实现getPermissions()方法
•实现refresh()方法.
如果你看到我们定制的策略类的实现，你可能注意到我们的AuthPolicy类派生在sun.security.provider.PolicyFile而不是java.security.Policy. 为什么？首先，我想要实现AuthPolicy类作为通用的Policy类，这可以处理默认的策略类不需要用任何适配器介入。通过从PolicyFile类，我们不需要去实现策略文件解析和其他相关的代码。同时，党应用运行于一个安全管理器起作用的情况下，一些权限，比如doAsPrivileged AuthPermission类和读入配置文件的FilePermission(为了载入配置文件)，需要被赋权为了执行JAAS.
当然,这些权限可以被存储在数据源里，但是把它们放入标准Java安全策略文件中可能更为有利。可是，对于正规开发你应该实现一个适配器以应付这些事情。在扩展认证时要遵循相同的设计模式。我们的策略类委托权限请求于
PermisssionAdapter类
在权限类里，不同的权限保存于自己的PermissionCollection类实例，如果你创建一个定制的权限类，你需要生成你自己的PermissionCollection类类型，否则不能保证你的权限对象将被参考确认。
PermissionAdapter类
PermissionAdapter类在我们的JAAS扩展组件中是认证过程可插拔模块的接口。它从一个具体的数据源评估策略并且分发一个包含一套已赋予的权限的PermissionCollection类。PermissionAdapter类接口有下面的方法：
• void initialize (Hashtable initParams):initialize方法被调用以相关的参数初始化适配器。此方法会被立即调用并且优先于任何其它的方法调用。同时，在Policy类的refresh方法被执行后它也会被调用。
• PermissionCollection getPermissions (ProtectionDomain
domain): 本方法只要某种主体权限被请求就会被调用。
作为一例子，让我们看看如何实现一个基于角色的PermissionAdapter类。假设有三个角色：管理员，用户，和客人，都拥有不同的权限，并且所有的权限信息被存储在数据库中。
首先，在initialize方法中，我们将从数据中取得所有角色的权限信息并且组装入集合类中，比如，Hashtable.接下来，在getPermissions方法中，我们会收集到相关主体有关的权限（这是仅有的会涉及到基于角色的访问控制）并且返回它们。注意我们可以得到相关的主体通过调用ProtectedDomain类的getPrincipals方法。它是如此的简单，不是吗？
JaasUtil类
对于我们的JAAS扩展组件JaasUtil类是主要的纽带，并且它有一个构造函数取得用户名和密码。有两个关键的方法：
1． boolean authenticate()
2． boolean checkPermission(Subject subject,final Permission perm)
JaasUtil类实际延迟了LoginContext类的登陆请求和SecurityManager类的权限检查步骤。 Listing 1 显示了如何使用JaasUtil类。这段代码首先从HtttpServletRequest类取得用户名和密码并且尝试认证用户.然后其检测是否用户有权限访问“editReg.jsp”.
配置
现在我们拥有自己的定制的LoginModule,Policy和其他相关模块实现。这些模块可以委托相关的数据请求给合适的适配器；这是很好的事情。然而，在JAAS结构中LoginModule类和Policy类绝对不会被应用程序直接调用，所以我们怎样知道那种适配器应该被实力化和怎样传递需要的参数或者信息，比如数据连接，给适配器？答案是适配器可以通过更新一个XML配置文件被动态配置。这个XML配置文件由两个主要的数据段组成：
1、<authentication>:本段内容定义登陆源适配器和认证过程需要的各种可能的输入参数。
2、<authorization>:本段内容定义权限适配器和授权过程序要的各种可能的输入参数
你可以制定使用哪个LoginSourceAdapter类和PermissionAdapter类。在配置文件中传递额外的信息也是可能的。让JaasUtil类知道在那里寻找配置文件有两种途径：
1、 制定配置文件经由命令行属性开关: -Dcon.auth.config
2、 调用JaasUtil.setConfigFile（configFile）方法.
当你部署JAAS扩展组件时，这个定制安全策略类文件必须被加入到Java的jre/lib目录，这将引起策略类文件被bootstrap类加载其载入。否则，即便你放置策略文件在你的Java类路径中，它也将不能被检出并且Sun默认提供的策略类将会代替而被使用。
总结
扩展JAAS是不困难的。JAAS结构提供给你定制实现认证和授权过程的弹性。理解这些过程如何工作是懂得如何替换你自己的实现的第一步。在本文中，我们重温JAAS的基础，并且检查验证了如何扩展JAAS使其成为一个更加具备动态化、灵活化和规模化的特性的框架。使用这种扩展框架，你既能够轻松的生成自己登陆和访问控制机制以支持你自己的企业级别的安全需求也能够支持新兴的安全标准，或者平衡你们已经存在的或定制安全模型作为适配器，然后热插拔他们进入JAAS中。这应该可以给你的企业应用提供一个基于标准的同时高可定制的认证和授权过程
posted on 2006-03-08 15:11
fadesea 阅读(154)
评论(0) 编辑 收藏 所属分类:
J2EE