JBoss下利用JAAS处理登录 - 刘学文的专栏 - CSDNBlog

       两年前参与一个项目的时候，第一次接触到JAAS技术，那个项目采用IBM的Websphere做应用服务器。感觉非常的简洁和严谨：没用登录的用户在请求任意一个设置了权限的资源时都会转向登录页面(在这个登录页面的源代码里你绝对看不到隐藏了要跳转的页面的URL)，登录完成后再转到请求的资源，如果用过滤器来实现这种登录验证方式可能要写很多的代码，效果也未必很好，用JAAS的方式来处理则非常简单，配置一下就好了，甚至不用写代码。

　　于是等到去年自己负责一个项目的时候也采用了这种安全验证方式，由于这方面的技术资料很少，所以也摸索了不少时间。一开始是用Tomcat做Web服务器，后来迁移到了Jboss平台，我在这里主要介绍一下Jboss下这方面的技术，如果还有精力也提一下Tomcat下的实现方式。先来罗列一下接下来我要介绍的内容：

1. JAAS概述,Jboss下配置安全性验证的几种方式
2. 从数据库里读取登录用户的验证信息
3. 用自己的类来实现JAAS登录模块

• Java 鉴别与授权服务（JAAS）
  JAAS(Java Authentication and Authorization Service)可以在Java 平台上提供用户身份鉴别。在Java 平台上，其功能是独一无二的。
  Java 安全设计的所有核心功能都是为了保护终端用户不受程序开发者的影响，由于终端用户为了使用开发者提供的程序，不得不满足其对本地资源的存取要求，这就要求必须保证用户不受到程序的影响。另一方面，JAAS 允许开发者根据用户提供的鉴别信任状（credential）准许（或拒绝）用户对程序的访问。
  JAAS 可由 http://java.sun.com/products/jaas/ 下载。它包括两部分： 一部分是Java类库，其中定义了服务接口（JAAS 固有的)，另一部分为平台专用的模块，其作用是实现授权（JAAS 模块）。此外还可以获得模块样例，从而在JNDI 目录服务、Windows NT 登录服务和Solaris 登录服务基础上实现鉴别。
  JAAS 本身包括文档和一个lib 目录，其中只有一个jar 文件（jaas.jar）。可以将此jar 文件安装到$JREHOME/lib/ext 中，用户也可以将它放在类路径指定的目录下。JAAS模块的lib 目录中包括另一个jar 文件（jaasmod.jar），对其处理方法与jaas.jar类似。

• Jboss安全性配置

  J2EE定义了应用中指定安全性约束的机制，但并没有给出具体服务器是如何实现和配置认证和访问控制机制（译者注：授权）的。JBoss使用了JAAS以提供集成不同认证技术的可插入方式，供应用的认证和授权使用。同时，JBoss还提供了一套标准模块，即基于文件、数据库、LDAP的安全性机制。其中，基于文件的方式最为简单。用户可以使用现有的认证模块，或者可以开发更适合自身需求的认证模块。
  Jboss安全性域信息存储在login-config.xml文件中，其包含了许多安全性域定义。各个安全性域指定了许多JAAS3登陆模块，供安全性域认证使用。当用户需要在应用中使用安全性时，需要在JBoss特定部署描述符jboss.xml或jboss-web.xml中指定待使用的安全性域名。本节将快速地带领用户分析如何保护随JBoss发布的JMX控制台和Web控制台应用。
  通过JMX控制台基本上能够控制JBoss服务器的各个方面，因此保护该控制台很重要，至少需要通过密码来保护它。否则，任何远程用户将能够完全控制用户的JBoss服务器。为实现此目的，本文将安全性域添加给JMX控制台应用。通过server/default/deploy/jmx-console.war/WEB-INF/目录能够找到待修改的JMX控制台文件，即jboss-web.xml。将jboss-web.xml中security-domain的注释去掉，具体如下。
  
  java:/jaas/jmx-console
  
  这将设置Web应用待使用的安全性域，但还未确定Web应用应该使用的安全性策略。待保护的URL是什么，相应的访问角色又是哪些？为配置这些内容，用户需要在同一目录中找到web.xml文件，然后将security-constraint的注释去掉。其中，该安全性约束要求登陆用户必须具有JBossAdmin角色。
  
  
  
  HtmlAdaptor
  
  An example security config that only allows users with the
  role JBossAdmin to access the HTML JMX console web application
  
  /*
  GET
  POST
  
  
  JBossAdmin
  
  
  太好了，但是用户名和密码来自哪里呢？不错，它们来自jmx-console安全性域。通过conf/login-config.xml文件能够看到。
  
  
  flag="required">
  
  jmx-console-users.properties
  
  
  jmx-console-roles.properties
  
  
  
  
  上述配置使用了基于简单文件的安全性策略。其中，登陆JMX控制台应用的用户名和密码存储在jmx-console-users.properties中，并且以“username=password”形式给出。为了将用户添加到JBossAdmin角色中，需要将“username=rolename”形式给出的用户和角色映射关系给出在jmx-console-roles.properties文件中。现存的文件创建了admin用户，其密码为admin。用户可能删除该用户，或者更改其密码，使得JMX控制台应用更安全。
  当更新了web.xml时，JBoss会重新部署JMX控制台应用。用户可以通过服务器控制台检查JBoss保存了对web.xml所作的修改。如果用户正确地配置了上述各个任务，并且重新部署了JMX控制台应用，则下次访问它时，JBoss会要求用户提供用户名和密码。
  JMX控制台应用不是JBoss唯一提供的、基于Web的管理界面。JBoss还提供了另一管理应用，即Web控制台（参考附录A）。尽管Web控制台是基于Java Applet形式给出的，但是对应的Web应用还是可以类似于JMX控制台的方式来保护它。其中，Web控制台应用位于default/deploy/management/web-console.war。注意，这同JMX控制器应用有所区别，因为JMX控制器应用是以目录形式展开的。因此，编辑web-console.war WAR存档更费力些。

• 配置Jboss安全性域
  通常，用于Web和EJB层的、标准的J2EE安全性声明需要借助于web.xml和ejb-jar.xml部署描述符指定。然而，为配置使用JBoss安全性，开发者还需要提供JBoss专有的部署描述符。
  通过JBoss具体部署描述符能够完成应用的安全性配置。为保护Web应用，用户需要将security-domain元素包含在jboss-web.xml中。
  
  java:/jaas/dukesbank
  ...
  
  如果需要在EJB层实现访问控制，则用户也可以对jboss.xml文件添加同样的security-domain元素。
  
  java:/jaas/dukesbank
  
  ...
  
  
  这将意味着，JBoss会在JNDI名“java:/jaas/dukesbank”下为Duke银行应用绑定安全性管理器实例。所有的安全性域配置在java:/jaas上下文，因此Duke银行应用实际上使用了dukesbank安全性域。
  用户通过conf/login-config.xml文件能够配置它。但是，如果浏览Duke银行应用，并不能够找到dukesbank安全性域。一旦JBoss寻找不到相应的安全性域，则它会使用other域。其中，other域的具体配置如下。
  
  
  flag="required" />
  
  
  此处，登陆模块使用本地属性文件来认证应用。JBoss借助于两个文件进行认证工作。其一，提供用户名、密码；其二，提供角色。比如，如下是Duke银行应用的users.properties。
  # users.properties file for use with the UsersRolesLoginModule
  # Format is:
  #
  # username=password
  200=j2ee
  属性文件的格式非常简单。各行采用username=password的形式。因此，上述文件定义了200用户，其密码为j2ee。这就是用户访问Duke银行应用的帐号。如果用户修改了上述密码，则需要重新部署Web应用。
  当然，用户名和密码不是驱动J2EE应用安全性的唯一因素。部署者需要将用户指定角色，因此应用会根据用户的角色信息来决定用户是否有权访问目标资源。只有是Duke银行应用的客户才有权访问它，即通过bankCustomer角色。下面给出了roles.properties文件，用于指定200用户的角色。
  # A roles.properties file for use with the UsersRolesLoginModule
  #
  # Format is
  #
  # username=role1,role2,role3
  200=bankCustomer
  
  为让Duke银行应用使用dukesbank安全性域，而不是使用服务器提供的默认安全性域，开发者还需定义出dukesbank安全性域。因此，开发者需要往conf/login-config.xml文件中添加如下内容：
  
  
  flag="required" />
  
  
  注意，需要重启JBoss，否则修改后的login-config.xml不会生效。
  

•  使用RDBMS实现安全性
  实际应用中，将用户、角色信息存储在数据库中很常见。JBoss提供了称之为DatabaseServerLoginModule的登陆模块，用户只需要做少许的配置即可使用它。用户需要提供如下内容：
  ?? 获得用户密码的SQL查询语句
  ?? 获得用户角色的SQL查询语句
  ?? 待使用数据源的JNDI名
  因此，可以使用现有的数据库模式。现假定：使用如下SQL语句创建安全性相关的数据库表。
  CREATE TABLE Users(username VARCHAR(64) PRIMARY KEY, passwd VARCHAR(64))
  CREATE TABLE UserRoles(username VARCHAR(64), userRoles VARCHAR(32))
  INSERT INTO Users VALUES ('200','j2ee')
  INSERT INTO UserRoles VALUES ('200','bankCustomer')
  然后，将它们作为Duke银行应用的安全性数据库。需要对login-config.xml作如下修改：
  
  
  flag="required">
  java:/DefaultDS
  
  select passwd from Users where username=?
  
  
  select userRoles,'Roles' from UserRoles where username=?
  
  
  
  
  其中，获得密码的SQL语句很好理解。但是，对于获得角色的SQL语句而言，多出了称之为“Roles”的角色组域。用户可以添加自身需要的、处于该角色组中的其他角色。JBoss本身要求，其取值是“Roles”。本实例的数据库中，仅仅存在一套角色，并无角色组信息5。
  上述登陆模块中，使用了默认数据源。如果用户在使用Hypersonic，则可以使用数据库管理器工具创建数据库表、添加数据（Duke银行应用一章曾给出介绍）。
  

• 使用密码散列
  到目前为止，本书使用到的登陆模块都支持密码散列，即不是以明文存储密码，而是存储单工密码（比如，使用MD5）。这同UNIX系统中的/etc/passwd文件类似。因此，用户即使浏览到密码，也不能够登陆到系统中。然而，这种方式也有缺点。其一，万一用户忘记密码，则不能够恢复。其二，管理工作变得较复杂，因为用户需要计算密码散列，并放置在安全性数据库中。当然，这并不妨碍其使用。为生效密码散列，用户需要添加如下模块选项。
  MD5
  base64
  这表明使用了MD5散列、base64编码，从而将二进制散列值转换为字符串。JBoss在认证用户之前，会使用上述选项计算出密码的散列，因此用户必须确保数据库中存储了正确的散列信息。如果用户使用UNIX系统，或者在Windows上安装了Cygwin，则可以使用openssl计算散列。
  $ echo -n "j2ee" | openssl dgst -md5 -binary | openssl base64
  glcikLhvxq1BwPBZN0EGMQ==
  用户应该将“glcikLhvxq1BwPBZN0EGMQ==”插入到数据库中，而不是明文，“j2ee”。或者，可以使用jbosssx.jar中的org.jboss.security.Base64Encoder类。
  $ java -classpath ./jbosssx.jar org.jboss.security.Base64Encoder j2ee MD5
  [glcikLhvxq1BwPBZN0EGMQ==]
  如果用户只提供单个参数，则上述类只会以base64对它进行编码。但如果将加密算法名作为第二个参数，则它将计算出第一个参数的散列。