扩展JAAS (转载)

用户认证和访问控制是大多数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方法被执行后调用，它给适配器做一些清理工作的机会。