Web应用程序的安全机制

现Web应用程序的安全机制是Web应用程序的设计人员和编程人员必须面对的任务。在J2EE中，Web容器支持应用程序内置的安全机制。

Web 应用程序的安全机制有二种组件：认证和授权。基于J2EE的Web容器提供三种类型的认证机制：基本认证、基于表单的认证、相互认证。由于能够对认证用户 界面进行定制，大多数的Web应用程序都使用基于表单的认证。Web容器使用在Web应 用程序的部署描述符中定义的安全角色对应用程序的Web资源的访问 进行授权。

在使用基于表单的认证机制中，应用程序的设计人员和开发人员会遇到3类问题：

1、基于表单的认证如何与数据库和LDAP等其他领域的安全机制协同工作。（这是非常必要的，因为许多组织已经在数据库和LDAP表单中实现了认证机制。）

2、如何在Web应用程序的部署描述符（web.xml）中增加或删除 功能模块(原文为“军政府”,不知道什么意思)的授权角色。

3、Web容器在Web资源层次上进行授权；应用程序则需要在单一的Web资源中执行功能层次上的授权。尽管有许多与基于表单的认证有关的文档和例子，但都没有能够阐明这一问题。因此，大多数的应用程序都以自己的方式表达安全机制。

本篇文章说明了基于表单的认证如何与其他方面的安全机制，尤其是数据库中的安全机制协作的问题。它还解释了Web窗口如何使用安全角色执行授权以及应用程序如何扩展这些安全角色，保护Web资源中的功能。

基于表单的认证

基于表单的认证能够使开发人员定制认证的用户界面。web.xml的login-config小节定义了认证机制的类型、登录的URI和错误页面。

＜login-config＞ ＜auth-method＞FORM＜/auth-method＞ ＜form-login-config＞ ＜form-login-page＞/login.jsp ＜/form-login-page＞ ＜form-error-page＞/fail_login.html ＜/form-error-page＞ ＜/form-login-config＞ ＜/login-config＞

登录表单必须包含输入用户姓名和口令的字段，它们必须被分别命名为j_username和j_password，表单将这二个值发送给j_security_check逻辑名字。下面是一个该表单如何在HTML网页中实现的例子：

＜form method="POST" action="j_security_check"＞ ＜input type="text" name="j_username"＞ ＜input type="password" name="j_password"＞ ＜/form＞

除非所有的连接都是在SSL上实现的，该表单能够透露用户名和口令。当受保护的Web资源被访问时，Web容器就会激活为该资源配置的认证机制。

为了实现Web应用程序的安全，Web容器执行下面的步骤：

1、在受保护的Web资源被访问时，判断用户是否被认证。

2、如果用户没有得到认证，则通过重定向到部署描述符中定义的注册页面，要求用户提供安全信任状。

3、根据为该容器配置的安全领域，确认用户的信任状有效。

4、判断得到认证的用户是否被授权访问部署描述符（web.xml）中定义的Web资源。

就如基本的安全认证机制那样，在Web应用程序的部署描述符中，基于表单的认证不指定安全区域。也就是说，它不明确地定义用来认证用户的安全区域类型，这就会在它使用什么样的安全区域认证用户方面引起混淆。

要对用户进行验证，Web窗口需要完成下面的步骤：

1、判断该容器配置的安全区域。

2、使用该安全区域进行认证。

由于数据库和LDAP在维护信息方面提供了更大的灵活性，因此大多数组织都会希望继续使用它们维护安全认证和授权信息。

许多Web窗口都支持不同类型的安全区域：数据库、LDAP和定制区域。例如，在Tomcat Web容器中，server.xml将数据库配置为其安全区域。

 

＜Realm className="org.apache. catalina.realm.JDBCRealm" debug="99" driverName="oracle.jdbc. driver.OracleDriver" connectionURL="jdbc:oracle:thin: @{IPAddress}:{Port}:{Servicename}" connectionName="{DB Username}" connectionPassword="{Password}" userTable="users" userNameCol="username" userCredCol="password" userRoleTable="user_roles" roleNameCol="rolename" /＞

Tomcat的server.xml的＜Realm＞标志定义了窗口用来识别一个用户的安全区域的类型。注意，容器对Web应用程序使用该区域，应用程序的认证机制是基于表单的。

授权

一旦用户被识别后，容器就会得到认证用户的安全角色，看用户是否属于在部署描述符中的＜auth-constraint＞标志中定义的安全角色之一。如果用户不属于任何一个安全角色，则容器会返回一个错误。

部署描述符（web.xml）的＜security-constraint＞标志定义了被保护的Web资源和能够访问这些资源的安全角色清单。

＜security-constraint＞ ＜web-resource-collection＞ ＜web-resource-name＞AdminPages ＜/web-resource-name＞ ＜description＞ accessible by authorised users ＜/description＞ ＜url-pattern＞/admin/*＜/url-pattern＞ ＜http-method＞GET＜/http-method＞ ＜/web-resource-collection＞ ＜auth-constraint＞ ＜description＞These are the roles who have access＜/description＞ ＜role-name＞manager＜/role-name＞ ＜/auth-constraint＞ ＜/security-constraint＞

Web窗口在网页层次上执行认证。然而，商业性应用程序可能还希望对一个网页内的功能进行认证，这会要求在应用程序中定义一些新的附加的与应用程序有关的安全角色。为了控制对功能的访问，应用程序需要理解角色的权限概念。Web容器标准没有解决权限的问题。

由 于授权角色是动态的，开发人员常常会感到迷惑，即这些安全角色是否需要添加到部署描述符中。为了使应用程序充分利用安全支持，Web容器只需要在部署描述 符中定义的一个角色。因此，应用程序可以定义一个高层次的角色，然后将所有的用户都指派给该角色。这将使该角色中的所有用户都拥有能够访问Web资源的权 限。

另外，应用程序还可以定义额外的角色，执行对一种Web资源中较低层次的功能的授权。由于应用程序已经配置有一个包含应用程序中所有用户的高层次安 全角色，这些低层次的安全角色也就不需要在部署描述符中进行定义。这使得Web应用程序能够利用容器的授权支持，实现与指定应用程序有关的授权。

我们可以在部署描述符中为所有用户定义一个高层次的管理员角色，保护管理类Web资源，这使得管理员角色中的所有用户都能够访问管理网页。为了控制管理网页中的其他功能，我们可以在应用程序中创建 sysadmin或appadmin等新的角色。

应用程序可以对这些安全角色进行扩展，使它们拥有一定的权限。然后，应用程序可以使用这些权限来控制对其功能的访问。

尽管与特定应用程序相关的安全角色不是定义在部署描述符中的，这些角色仍然可以在isUserInRole方法中使用，判断用户是否在这些安全角色中。

优点

•Web应用程序无需实现认证机制，简化Web应用程序的配置。

•Web应用程序能够使用getRemoteUser、IsUserInRole和getUserPrincipal方法实现有规划的安全。

•Web应用程序能够将认证信息传播给EJB容器。