用户和组
　　
　　为列出属于某个安全域的用户，从administration console选择该安全域，然后选择users节点。然后，可以使用右侧窗格来查看所有用户或者过滤清单。system用户帐号也将是清单的一部分――这是当使用configuration wizard（配置向导）创建域时定义的administration用户帐号。选择“configure a new user”，创建一个新用户。需要为每个用户指定一个名称、一段简短的描述和一个密码。注意，安全域中所有的用户名必须是独一无二的。默认的提供程序使用不区分大小写的用户名。用户可以属于一个或多个组。
　　
　　为列出和编辑属于某个安全域的所有组，需要从administration console选择该安全域，然后选择groups节点。还可以在这里创建一个新组。组的membership选项卡可能会误导人，因为它并不允许查看组的成员。要查看一个用户是不是组的成员，必须选择该用户，然后查看它的groups选项卡。weblogic允许向其他现有的组添加组，而membership选项卡列出了所选中的组中包含的所有子组。还可以使用这个选项卡给当前组添加另一个组。
　　
　　对于安全配置，组成员资格具有两点重要的含义。假定用户在域中定义了两个组，a和b，而组b是组a的一个成员。这意味着：
　　
　　属于组b的每个用户同时也属于组a。
　　
　　如果指派一个角色或策略给组a，就是同时向组a的所有成员和组b的所有成员指定了相同的角色或策略。
　　
　　当查看用户的groups选项卡时，administration console仅列出该用户直属的组。所以，如果一个用户属于组b，administration console在groups选项卡下只会列出组b，即使该用户实际上既属于组a，也属于组b。
　　
　　当使用configuration wizard创建一个新域时，以下组将会自动创建并随时可用：administrators、deployers、operators和monitors。一开始，system用户是惟一被创建的用户，它也是域中administrators组的惟一成员。
　　
　　记住，组只不过简化了管理的任务。如果一个用户是某个组的成员，它不会自动获得任何特殊的权限。只有当组（直接地或通过一个角色）参与策略语句时，它才会继承访问权限。例如，最初的system用户帐号获得了administrative访问权限，仅仅是因为它是administrators组的成员，而这个组又是（全局的）admin角色的一个成员，同时有一条可用的策略语句把访问域中各个区域(area)的权限授予admin角色。
　　
　　有两个组在groups页面上没有列出，但是它们自动对于安全域可用：
　　
　　users
　　
　　该组代表所有通过身份验证的用户的集合。任何成功通过身份验证的用户都是users组的成员。
　　
　　everyone
　　
　　这个组代表所有weblogic用户的集合，包括匿名用户。任何用户，无论是已验证的还是匿名的，都是everyone组的一个成员。
　　
　　这些组为建立默认的访问控制提供了一种便捷的方式。例如，通过策略语句“用户是everyone组的成员”，资源可以被所有用户访问。另外，通过对某项资源定义如下策略：“用户是users组的成员”，可以把访问权限定为仅针对已验证的用户。还可以编程式地检查服务器端的组成员资格。下面的例子用于检查当前用户是users组还是everyone组的成员：
　　
　　/** returns false if executed without any security context */
　　
　　weblogic.security.subjectutils.isuseringroup(
　　
　　weblogic.security.security.getcurrentsubject( ),"users");/** returns true regardless of whether the user authenticates */
　　
　　weblogic.security.subjectutils.isuseringroup(
　　
　　weblogic.security.security.getcurrentsubject( ),"everyone");
　　
　　保护用户帐号
　　
　　weblogic提供一种用户封锁功能，以防止用户帐号的滥用。当一个用户尝试登录失败的次数达到一个阙值时，该用户就会被封锁。当这种情况发生时，该用户将被封锁一段时间（时间长短可以配置），或者直到管理员解锁该用户为止。在这期间，该用户被禁止使用这些证书访问服务器。为配置用户封锁，需要选择administration console左侧窗格中的security/realms节点下的安全域。然后，可以使用user lockout选项卡来调整封锁功能，并查看封锁统计信息。
　　
　　表17-2列出了user lockout选项卡下可用的各种配置选项。默认情况下，这些设置被配置为最高安全性。
　　
　　表17-2. 配置用户封锁
　　　
　　当一个用户被封锁时，用户列表（位于users节点下）中的locked栏下就会出现一个details链接。如果选择列表中某个用户的这个链接，就可以查看该用户登录尝试失败的次数，以及最后一次失败的登录尝试的时间。还可以选择unlock选项，手动重新激活用户的帐户。
　　
　　角色
　　
　　和组不同，角色代表一个动态的用户集合。角色成员资格可以通过以下规则进行定义：
　　
　　用户名
　　
　　可以指定多个用户名。如果通过身份验证的用户与列表中的一个名称相匹配，而且它满足其他所有规则，它将自动成为该角色的成员。
　　
　　组名
　　
　　可以指定多个组名。如果通过身份验证的用户是列表中某个组的成员，而且它满足其他所有规则，它将自动成为该角色的成员。
　　
　　访问时间
　　
　　可以定义多个允许用户进行访问的时间段。如果用户试图在一个指定的时间段之内访问资源，而且满足其他所有规则，它将自动成为该角色的成员。
　　
　　通过使用逻辑and（与）和or（或）关系，可以以各种方式组合这些规则。例如，可以基于如下规则创建rolea：用户属于组ukseller，而且访问时间在上午8:00到下午9:00之间。那么任何试图在这段时间内访问资源，同时又是ukseller组成员的用户就会成为rolea的成员。或者，可以基于如下规则创建roleb：用户属于组ukseller，或者访问时间在上午8:00到下午9:00之间。在这种情况下，组ukseller的每个成员都将始终属于这个角色，同时每个在上午8:00到下午9:00之间访问资源的用户也将成为该角色的一个成员，而不管它属于哪个组。当用户尝试访问受（根据该角色定义的）策略语句保护的资源时，要在运行时对该角色的成员资格条件进行评估。因此，成员资格条件有助于评估在某个时刻用户是否属于该角色。
　　
　　通常，weblogic默认的role mapping provider负责管理与在某个安全域中定义的所有角色相关的信息。事实上可以定义两类角色：全局的(scoped)和局部的(scoped)角色。
　　
　　全局角色
　　
　　全局角色可用于安全域中的所有资源。当创建一个新域时，就会自动创建一组默认的全局角色；它用于授权对各种操作的访问。这些预定义的全局角色与默认的安全策略（对weblogic域执行factory-set安全配置）相关联：
　　
　　admin
　　
　　属于该角色的用户对域的各个区域具有完全访问权。这包括以下能力：查看和编辑域配置、启动和停止服务器、部署应用程序（ejb、jms factory、web应用程序）等等。任何属于administrators组的用户将自动继承admin角色。也就是说，admin角色的成员资格条件是用户必须属于administrators组。
　　
　　deployer
　　
　　属于该角色的用户可以查看域配置，查看和编辑部署描述符，部署应用程序和ejb，以及启动和关闭类、j2ee连接器和web服务组件。deployer角色的成员资格条件是用户必须属于deployers组。
　　
　　operator
　　
　　属于该角色的用户可以查看服务器配置，还可以启动、停止和重新开始服务器实例。operator角色的成员资格条件是用户必须属于operators组。
　　
　　monitor
　　
　　属于该角色的用户只可以查看服务器的配置。monitor角色的成员资格条件是用户必须属于monitors组。
　　
　　为创建或修改现有的全局角色，需要从administration console左侧窗格中选择安全域，然后选择global roles节点。
　　
　　weblogic还提供一个称为anonymous的全局角色。它的成员资格被定义为包括everyone组中的所有用户。即使anonymous角色没有出现在administration console中所列出的角色之中，仍然可以使用它来定义针对资源的策略。
　　
　　局部角色
　　
　　大多数角色是局部的，这是指它们适用于特定的资源或jndi树的分支。全局角色和局部角色的差别在于，前者独立于任何资源，并且可以通过administration console进行集中管理，而后者是跨各种资源分布的。用户必须选择一种特定的资源，以便查看相关的局部角色。不管实际资源是什么，用于创建局部角色的底层principle是相同的。从administration console的左侧窗格中定位资源，然后右击并选择define scoped role。在某些情况下，在更详细的方面中可以定义局部角色及其“兄弟”，局部策略。例如，在web应用程序中，可以为ejb（基于每个方法）、web服务（基于每项操作）和web资源（基于某种http方法类型（post、get、head等等））都定义一个局部角色和策略。现在，让我们看一看如何为特定的资源创建局部角色，以及在此配置中需要采取的一些预防措施。
　　
　　连接池和多池
　　
　　jdbc资源位于services/jdbc子树下。可以右击选定的资源（如：连接池），然后选择define scoped role来为资源定义一个角色。还可以删除或修改以前指派的角色。
　　
　　jdbc角色是分级的。如果右击jdbc/connection pools节点，可以按照同样的过程创建一个适用于所有连接池的局部角色。
　　
　　jndi分支
　　
　　可以为服务器的jndi树的特定的节点或分支指派一个角色。从administ