中国移动WebLogicPortal安全配置手册.docx

密 级：
文档编号：
项目代号：

中国移动
WebLogic Portal安全配置手册

Version 1.0

中国移动通信有限公司
二零零四年十二月

拟 制:

审 核:

批 准:

会 签:

标准化:

版本控制

版本号
日期
参与人员
更新说明

分发控制

编号
读者
文档权限
与文档的主要关系
1

创建、修改、读取
负责编制、修改、审核
2

批准
负责本文档的批准程序
3

标准化审核
作为本项目的标准化负责人，负责对本文档进行标准化审核
4

读取

5

读取

目 录
第1章 WEBLOGIC PORTAL 安全概述 1
1.1 工作原理 1
1.1.1 安全框架体系架构 1
1.1.2 服务提供者集成 2
1.2 功能与定位 3
1.3 特点与局限性 4
1.3.1 集成的安全性 4
1.3.2 兼容性 5
1.3.3 安全管理特性 5
第2章 3A 8
2.1 认证(authentication) 8
2.2 授权(authorization) 9
2.3 审计(auditing) 10
第3章 WEBLOGIC PORTAL资源的访问控制 12
3.1 安全配置步骤 12
3.2 系统安全配置 13
3.2.1 更新系统口令 13
3.2.2 配置安全域 15
3.3 用户和组 19
3.3.1 定义用户 19
3.3.2 定义组 24
3.4 安全服务提供者管理 27
3.4.1 注册安全服务提供商 28
3.4.2 配置一个服务提供商 28
3.5 管理Permission授予 29
3.5.1 注册一个角色 30
3.5.2 角色属性配置 31
3.5.3 向角色添加用户和组 32
3.5.4 编辑角色表达式 33
3.5.5 角色权限设置 34
3.5.6 角色使用配置 35
3.6 访问控制portlet 36
3.6.1 角色权限设置 37
第4章 单点登录配置 39
4.1 安装SiteMider for WLS Agent 39
4.2 SiteMider策略服务器配置WLS Agent 42
4.3 配置WLS上的安全提供商 50
第5章 WEBLOGIC PORTAL配置SSL 53
5.1 配置SSL 53
5.1.1 获得私钥与数字证书 53
5.1.2 保存私钥与数字签名 54
5.1.3 配置单向SSL 56
5.1.4 配置双向SSL 59
附录 术语表 61

第1章 WebLogic Portal 安全概述
1.1 工作原理
1.1.1 安全框架体系架构
BEA WebLogic 8.1安全框架的目标是为应用程序安全提供一种全面、灵活和开放的方法。与BEA WebLogic以前版本中的安全领域(realm)不同，新的框架适用于所有的J2EE对象，包括JSP、servlet、EJB、JCA适配器、JDBC连接池以及JMS目标。此外，新的框架还被用来提供安全的Web服务开发所必需的认证和授权服务。它符合所有的J2EE 1.3安全性要求，例如JAAS（用于与认证和授权相关联的对象）、JSSE（用于通过SSL和TLS进行的通信）和SecurityManager类（用于代码级安全）。
这一架构的核心是安全和业务逻辑的分离。业务逻辑在适当的容器（可以是JSP、servlet或EJB容器）里执行。当容器接收到一个针对它包含的对象的请求时，它把整个请求及其整个上下文委托给安全框架。框架则根据是否通过请求，返回yes或no决策。由于向安全系统提供了目标对象也可以使用的相同信息，所以这个方法把业务逻辑从安全因素里分离了出来。二者都利用这项信息来实现自己的责任：框架实施安全策略，对象则执行业务逻辑。
当安全框架接收到委托的请求时，它以图1所示的形式管理安全处理。这个处理非常灵活，其中的精细步骤在许多系统中都见不到，例如动态的角色映射、动态授权以及多个授权者的调整。在每一步里，框架都会通过对应的服务提供者接口（SPI）把处理委托给一个自带的、第三方的或者自定义的提供者。这个架构使BEA WebLogic Server&Portal能够把所有必要的信息路由给每种类型的服务提供者，以便应用程序可以充分利用专业化安全服务的特长。

图1-1. 安全框架体系架构
1.1.2 服务提供者集成
安全框架仅仅管理安全处理。每一步骤都要求服务提供者来执行。BEA WebLogic 8.1为每个步骤包含提供者，但是这些提供者都使用框架SPI。其他的提供者也都可以访问同样的工具。这些SPI包括：
· 认证。
· 身份断言。
· 角色映射。
· 授权。
· 判决。
· 凭据映射。
· 审计。
1.2 功能与定位
BEA WebLogic Portal安全管理功能包括：
v 安全域管理：包括用户、组和角色管理；安全服务提供者管理；
安全域管理中，WebLogic portal采用了WebLogic Server提供的安全域（security realm）机制管理用户，用户组和加载第三方安全厂商的信息。在原Server的安全域上，对用户和用户组的管理增加了新的属性，通过每个portal管理控制台创建的用户和组信息也可以通过WebLogic Server的管理控制台进行属性配置和修改。Portal中的角色管理是Portal的独立的管理模块，因此在Portal中定义的角色信息不会在WebLogic的GobalRoles进行配置。
v Portal管理Permission的管理；
Portal对管理权限采用Delegate方式实现权限分配，在Portal管理控制台中可以配置管理权限的Delegate角色，为Delegate角色分配管理权限。属于该Delegate角色的用户成员或用户组都具备Delegate角色中的管理权限。
v Portal访问控制Portlet的管理；
与管理权限分配机制相似，Portal对访问控制Portlet也通过对访问控制角色定义不同的权限实现。在Portal 的管理控制台中定义Vistor Entitlement角色，并将Portlet的管理权限分配给定义的Vistor Entitlement角色。属于该Vistor Entitlement角色的用户成员或用户组都具备角色中指定的内容资源管理的权限。
v 单点登录：包括WebLogic Portal内嵌的单点登录和集成第三方的单点登录系统两种模式；
单点登录方面WebLogic Portal模块化安全域模型构成了WebLogic Portal与第三方安全产品集成的基础。众多第三方安全产品厂商提供了支持WebLogic 的SSO产品，通过配置WebLogic Portal使用厂商提供的安全域实现单点登陆。WebLogic Portal集成的优点是使门户应用能够与第三方安全服务共享用户名和用户组/角色，进而实现无缝的安全认证。因此，储存于外部安全库的用户名能够被WebLogic Portal识别。另外，来自于第三方安全产品的组成员信息也能被用于定义组的门户，并为用户访问门户页面和Portlet建立基本的授权。本文档考虑到河南移动的SSO采用了第三方的安全产品（Netegrity的Siteminder），单点登录的安排配置主要针对与Sitemider产品集成做详细介绍。
v SSL协议。
SSL协议保证用户在使用服务在信息通道上的安全，WebLogic Portal的SSL是基于WebLogic Server实现的，主要内容包括：
· 获得私钥和数字证书；
· 保存私钥和数字签名；
· 配置单向SSL；
· 配置双向SSL。
1.3 特点与局限性
1.3.1 集成的安全性
BEA WebLogic Server 8.1为企业应用程序提供了解决整体安全问题的集成方法。这个方法在业界是独一无二的，其他应用程序服务器供应商、开放源代码产品和专用的安全解决方案都没能达到这样的程度：可以提供强大的、灵活的、可扩展的安全架构。有了这个框架，应用程序安全不再是亡羊补牢了：它变成了应用程序基础架构的一项功能，并从应用程序分离出来。有了这个框架，任何部署在BEA WebLogic Server上的应用程序，都可以得到安全保护，或者通过服务器自带的安全特性，或者通过对开放安全服务提供者接口进行扩展以实现定制安全解决方案，或者通过插入来自客户用作企业标准的主流安全供应商的其他专门的安全解决方案。
1.3.2 兼容性
新的BEA WebLogic安全框架革新了应用程序层的安全性。但是，您可能已经在WLW 6.X的安全领域上做了相当的投资。您可能不想立即升级安全模型，所以框架提供了一个领域适配器，用于向后兼容性。实质来说，这个适配器就是BEA WebLogic 6.x中完整的安全子系统，而框架把它和其他实现认证和授权SPI的服务提供者同样对待。在服务器启动时，适配器像以前一样从部署描述符里提取访问控制定义。在运行时，它通过对应的SPI，接受框架委托给它的认证和授权请求。从您的角度来看，BEA WebLogic 8.1的安全性工作起来就像6.x的安全性一样。从服务器的角度来看，领域适配器则完全集成进了8.1安全框架。一旦您决定了迁移到安全框架，您可以方便地从6.x的定义里导入安全信息。您甚至还可以同时用领域适配器和安全框架本身的提供者，以便确认升级行为正确无误。
1.3.3 安全管理特性
1.3.3.1 外周认证
在SSO或集成安全认证的情况下，是由BEA WebLogic自己的认证器之外的部分来负责担保请求者的身份。这个部分有可能是BEA WebLogic Server的SSL层，也可能是Kerberos系统，也有可能是居中的Web服务。在这些情况下，第三方提供应用程序可以验证的令牌。只要应用程序相信第三方，就可以接受一个通过验证的令牌，好像它就是原始用户凭据一样。安全框架使用了非常简单的机制来与这类系统协作。第三方需要做的全部工作，就是把它的令牌放在HTTP头里。安全框架检查令牌，并根据令牌类型分配合适的服务提供者。如果进来的是来自中立SSL认证的X.509证书，框架分配的提供者会有这样的能力：验证证书链，一直验证到根证书授权机构，甚至还可以用在线证书状态检测协议来检查证书目前的有效性。如果进来的是Kerberos凭证或安全令牌，适当的提供者会对令牌解码，并执行必要的验证。
一旦提供者执行完验证，就会把凭据里的身份映射成本地用户。框架用这个本地用户回调JAAS，然后JAAS填充J2EE 1.3所规定的主体（Principal）对象。所以，这个方法在提供巨大灵活性的同时，完全遵守适当的标准。第三方提供者或企业开发团队可以把任何认证技术与BEA WLS集成在一起，只要这些技术能够填充HTTP头。集成BEA WLS应用程序和Web SSO解决方案很容易，因为它们中的大多数，包括SAML，都已经使用cookie或HTTP头了。
1.3.3.2 角色关联
多数应用程序安全模型使用角色的概念。角色在用户和资源之间提供了一个迂回层，可以提高管理的方便性。它们很像组，但是更加动态。通常来说，安全管理员根据规划把用户分配到一个组，然后在用户的工作责任变化时，再修改这个分配。角色的变化则更频繁，甚至根据具体情况，从请求到请求就发生变化。安全框架既支持组，也支持角色。图1-2所示的屏幕截图显示了可以很容易地以图形化方式配置组和角色。

图1-2. 动态角色映射过程
1.3.3.3 凭据映射
企业通常想把对后台数据库、打包应用程序或者传统系统的每一个请求，都绑定在一个最终用户身上。所以，当J2EE对象代表用户访问后端系统时，就必须向系统提供适当的凭据。基本的问题是，要把J2EE主体映射到后端系统凭据。自带的服务提供者解决了多数情况下用户名/口令凭据的问题。每个BEA WebLogic Server实例都有一个内嵌的LDAP目录，在里面保存了每个有效主体和后端系统组合的加密过的用户名/口令对。
对安全不断增长的关注，有可能形成对更复杂的第三方或定制提供者的需求。某些数据库的最新版本可以使用Kerberos凭证。同样，一些打包应用程序的最新版本可以使用不同形式的强认证，而许多主机系统使用RACF。安全框架能够轻松地适应支持这些替代项的第三方或定制提供者。

第2章 3A
2.1 认证(authentication)
认证是第一道防线。知道请求者的身份，应用程序层就能决定是否通过他们的请求，并对攻击者布下一道防线。从根本上说，所有认证方案的工作方式都相同。它们提供凭据来建立身份，并提供某种手段来验证凭据。但是，凭据的形式和验证机制多种多样。企业选择每一种认证方案都取决于大量因素，包括受保护资源的敏感程度、预期的攻击模型以及解决方案生命周期的成本。多数情况下，企业已经有了一种或多种认证方案在使用中，所以中间件必须与这些方案协作，接受它们的凭据，采用它们的验证机制。没有这种协作，企业就不得不采用口令这样的最小公因子方案，这样就可能把这类中间件的应用限制在一些低价值的应用程序中。
Web单点登录（single sign-on，SSO）的问题更加困难。SSO的动机来自Web应用程序的分布式本质。从用户的角度来说，一个应用程序可以实际包括大量不同的软件组件，运行在大量不同服务器上，甚至可以由大量不同的组织操作。但是，用户不想每次单击一个链接，因为是到不同地点的链接，就得重新提交凭据。用户的体验应当是无缝的。采用现有认证方案之前的问题，只是要求理解凭据格式并与验证机制集成。但是，使用Web SSO时，用户在许多情况下甚至不想提供凭据。不用看到用户的凭据就能建立用户身份的技巧，需要在处理用户会话的两台服务器之间进行复杂的后台通信。有大量专有的解决方案，而且有些已经成为这些通信的标准，但是对于可以预见的未来，很有可能一个特定应用程序必须要支持多种技术，所以必须要有一个开放模型。
处理其他Web应用程序组件涉及到与前端的协作，但是中间件基础架构还必须与后端协作。数据库已经存在了很长时间，企业对于数据库安全非常小心在意。企业实际上不相信前端和中间件层。如果攻击者攻陷了这些层里的任意一个，就有可能发送一系列数据库请求，请求可能会返回数据库里保存的大量数据。同样，如果前端或中间件组件有缺陷，那么有可能会为错误的用户请求数据，因而可能造成私密信息的泄漏。因此，许多企业想把每个数据库请求都绑定到一个具体终端用户上，包括用于建立用户身份的适当凭据。应用程序必须做好准备来传递这个信息。
2.2 授权(authorization)
一旦应用程序已经生成了请求者的身份，就必须确定现有安全策略集是否允许它通过该请求。通常情况下，中间件基础架构（例如J2EE）使用静态的基于角色的系统。在用户规划的时候，安全管理员会明确地给用户分配角色，然后当条件要求时，再更新这些分配。在组件部署期间，安全管理员指定允许哪些角色访问组件。在运行的时候，如果请求来自具备必要角色的用户，那么应用程序就许可该请求。这种静态的方法忽视了许多业务策略的动态本质。想想控制银行帐户、费用报告、银行出纳等策略的例子。对于银行帐户，每个客户都应当只能访问他自己的帐户。对于费用报告，经理只能批准规定额度内的费用，而且不能批准自己的费用。对于银行出纳来说，只有在他们当班的时候才能履行出纳的职责。甚至还有更加复杂的策略，这时授权取决于分配给用户的角色以及请求的内容的组合。中间件基础架构必须明确地支持这些种类的动态策略，或者至少提供足够的上下文来做这些专业安全工作。
对于动态授权的需求增加了管理问题。我们当然不想强迫安全管理员成为编程语言（如Java）专家。当然，会有一些非常规情况需要一些定制编程，但是例行公事地更新费用报告授权的资金额度并不需要编程。在更现实的层面上，我们也不想强迫管理员去深入XML格式的部署描述符，然后重新部署组件以更新角色分配。安全管理员需要设计良好的、图形化的用户界面，让他们可以执行所有例行任务，以及大多数运行时的非例行任务。管理用户列表以及为用户分配的角色、修改组件的保护级别、配置动态约束，都应当只需要一点点时间。
对安全管理员来说，更大的麻烦来自从一个授权服务迁移到另外一个。由于授权决策的复杂性，许多企业依赖专业化的服务，所有应用程序都把这类决策委托给专业服务。当需要执行主要的版本更新或转换到另外一个服务的时候，管理员就面临了困境。什么时候转换到新提供者？要关注的是新服务中的缺陷或配置问题。管理员们不想因为转换就造成扑天盖地的不当授权或错误地拒绝用户。他们实际喜欢的是同时应用二套系统，关注新旧服务之间决策的差异，但是这种方法，要求中间件基础架构要具备更高的与安全生态系统中其他部分协作的能力。
2.3 审计(auditing)
如果一个应用程序能够同时使用两种不同的授权服务，那么选项之间的差异会是非常值得注意的事件，而管理员可能想知道这些差异。不幸的是，多数中间件基础架构忽略了这类安全审计。恰当的审计不仅仅是把信息写进磁盘。为了支持验证、侦测和调查 职责，管理员需要在单一位置记录所有安全事件，需要对特殊的重要事件提供主动通知，还需要迅速搜索记录的能力。
安全管理员负责保证与信息访问有关的企业策略的实施。显然，他们首先必须指定这些策略，最好是用前面所说的那种生产力高的界面。然后他们必须定期检查审计记录，确认这些策略实际得到了执行。政府管制或商业合约有可能需要这类审计。管理员会抽样具有代表意义的事务集合，并跟踪它们通过各种不同应用程序组件的路径，从而确保每一步上的安全措施都得到了正确执行。管理员需要经过整理的审计轨迹，否则他们就不得不花费大量精力，手工地把不同位置的日志汇集起来。他们需要详细的记录，否则就无法确定策略是否得到完全遵守。
对于潜在的违反规则的行为作出响应，是安全管理员的另一项主要职责。响应包括两步：侦测和调查。首先，他们要有这样的能力，可以指定在什么条件下，安全系统会主动通知他们。这些条件可以包括交易值（例如超过一百万美金的资金转移）或者事件模式（例如访问敏感功能时使用弱加密连接的客户峰值）。一旦收到通知，管理员必须能够迅速搜索日志，以便判断是否确实发生了违规行为，并确定损害的程度。这些搜索可能包括复杂的条件，而且必须针对活动的审计轨迹执行，这样他们就可以在某个具体攻击展开的时候对其进行跟踪。这些需求使得审计子系统成为软件的重要组成部分，所以中间件提供者必须付出切实的努力来完善它。
注意：在应用程序安全性上，有许多具体的挑战。然而就像应用程序安全性自己的核心一样，WebLoigc Portal安全解决方案的核心也非常简洁。
1. 在安全策略和业务逻辑之间，我们拥有一个干净、优美的抽象。
2. 我们有一个简单的、声明性的接口，用来实时地管理安全策略。
3. 我们有一个开放、灵活的架构用来与安全服务集成。
这些实践避免了安全和业务逻辑混杂在一起的问题，理顺了安全管理，支持与安全生态系统的其他部分进行协作。BEA WebLogic 安全框架提供了这些关键能力。

第3章 WebLogic Portal资源的访问控制
3.1 安全配置步骤
在WebLogic服务器中，安全管理主要通过配置定义安全策略的属性来实现。可以用管理控制台定义安全策略。在管理控制台中，你应该为所分发的应用指定设置与安全相关的属性：
v 域
v 用户与组
v 角色
v SSL协议
v 双向认证
v 第三方安全服务提供者
因为各安全部件之间是紧密关联的，因此，在进行安全配置时，很难确定从哪开始。事实上，安全配置是一个重复的过程。尽管在进行安全配置时，可能会有很多种流程，但我们还是建议你遵照以下步骤进行：
1. 改变system用户的口令以保护WebLogic服务器，见“修改系统口令”。
2. 定义一个安全域。WebLogic服务器有一个缺省的安全域。但你可能更愿意用别的安全域或者是一个定制的安全域，见“配置安全域”。
3. 定义安全域的用户。你可以在安全域中用组来组织用户，见“定义用户”。
4. 客户端与WebLogic服务器之间的通信采用SSL协议，这样可以保护网络连接。当使用SSL协议，WebLogic服务器会使用由可靠的证书认证机构所发放的数字证书对客户进行验证。这一步是可选的，但我们建议你实施这一步，见“配置SSL协议”。
5. 通过实施双向认证进一步保护你的WebLogic服务器。当使用了双向验证， WebLogic服务器在对客户端进行验证，然后客户端会对WebLogic服务器进行验证，这个步骤也是可选的。
本章将介绍上述安全配置步骤，以及如何在管理控制台中设置那些与安全相关的属性。
注意：本章所描述的所有配置步骤都是在管理控制台中进行的。
3.2 系统安全配置
3.2.1 更新系统口令
在安装WebLogic服务器时，安装程序会要求你指定系统用户的口令。该口令是WebLogic服务器中weblogic用户的口令，被存储在%bea_home%\user_projects\domains\mydomain目录中的fileRealm.properties文件中。这个口令可以用于这个域的管理服务器以及所有与这个管理服务器关联的受管服务器。
注意：WebLogic服务器只能用weblogic用户来启动。
保存在fileReamln.properties文件中的口令是经过加密的。WebLogic服务器对被加密的口令进行散列化处理，从而进一步保护了口令。为了提高安全性，我们建议你经常更新系统口令。每个部署的WebLogic服务器必需有唯一的口令。
以下是更改系统口令的步骤：
1．在管理控制台中打开Users窗口
2．在User属性中输入webloigc
3．在Password属性中输入一个新的口令
4．确认你输入的口令

在一个域中，所有受管服务器的口令与管理服务器的口令相同。你应该用管理控制台经常地改变管理服务器的口令，新口令会传播到同一域中的所有受管服务器上。记住，一个域中的所有服务器成员的系统口令必须相同。
注意：Petstore以及ExampleServer域仍然把系统口令保存在password.ini文件中。当使用这些域时，你可以通过修改password.ini文件中的口令信息来修改examples服务器的系统口令。Password.ini文件中的口令是以明文形式保存的。
保持WebLogic服务器的口令不公开，是你部署WebLogic服务器和数据安全的关键。为了保护你应用的安全，BEA建议你不要公开WebLogic服务器的口令。
3.2.2 配置安全域
本节描述配置WebLogic应用部署的安全域，安全域在WebLogic Server81后的版本不在提供file、catch、windows NT、UNIX等安全域的配置功能，只保留了LDAP安全域的配置，下面介绍LDAP安全域配置内容。配置安全域一节包括：
l 创建安全域
l 配置用户登录锁
此外，安全域中还包含各个实体的管理如：用户、组、角色、安全服务提供者等等管理，具体的管理配置功能见“用户和组”与“安全服务提供者”。
3.2.2.1 创建LDAP安全域
LDAP安全域通过轻量级目录访问协议（LDAP）服务器对客户端请求进行验证。该服务器把组织中的所有用户都放在LDAP目录中以进行集中管理。LDAP安全域支持Open LDAP，Netscape iPlanet, Microsoft Site Server与Novell NDS等主流LDAP Server。
以前WebLogic服务器支持以下两个版本的LDAP安全域。
l LDAP realm V1 — 打包在以前WebLogic服务器版本中的LDAP安全域。LDAP security realm V1可以与所有所支持的LDAP服务器一同工作，该版本主要是为那些仍然使用老版本WebLogic服务器的BEA用户提供的。但是这一版本已经不推荐使用LDAP realm V1，所以BEA建议用户升级到LDAP realm V2。
l LDAP realm V2 － 最新的LDAP安全域在性能与可配置性方面都得到了提高。与WebLogic Server 8.1中提供的LDAP安全域是一样的。
注意：在使用LDAP安全域 v1时，可以通过管理控制台查看存储于LDAP目录服务器中的用户与用户组，但使用LDAP安全域 v2时，只能通过管理控制台查看存于LDAP服务器中的用户组信息。目前，在WebLogic Server 8.1版本中只用LDAP realm V2方式的LDAP安全域。
对用户以及用户组的管理（例如，增加与删除用户或用户组，或者是在组中增加成员），你需要使用LDAP服务器所提供的管理工具。如果你修改了LDAP存储中的内容，重置用户和组的信息以便查看改动情况。
LDAP安全域的配置主要是确定WebLogic服务器中的LDAP安全域如何与LDAP服务器进行通信以及描述用户与用户组如何保存在LDAP目录中。如果使用LDAP realm V2，那么可以使用WebLogic服务器所提供的模板来配置LDAP安全域。
l 对使用LDAP安全域的限制
在使用LDAP安全域时，应该注意以下限制：
n 在安装Microsoft Site Server中的LDAP服务器并创建了LDAP目录的根时，将缺省地创建若干个组织单元。在Groups下面有一个缺省的组织单元（名字为NTGroups）以及一个名字为Administrators的缺省空用户组。缺省情况下，WebLogic服务器也提供一个名字为Administrators的用户组，这个组中包含了一个启动WebLogic服务器的成员：weblogic。如果你使用了Microsoft Site Server的缺省设置，并在缺省的组织单元中创建自己的用户组，那么WebLogic服务器将不能被启动。因此你应该在LDAP目录服中创建自己的组织单元并在这个组织单元中创建自己的用户组。
n 如果LDAP目录中存在两个同名的用户组，那么WebLogic服务器将不能正确地对用户组中的用户进行验证。LDAP安全域使用用户组的DN来定位LDAP目录中的用户组。如果你创建了多个同名的用户组，WebLogic服务器只对它所找到的第一个组中的用户进行验证。因此在使用LDAP安全域时，每个用户组的名字应该是唯一的。
l 创建LDAP Realm
WebLogic服务器为所支持的LDAP服务器提供了模板。这些模板定义了代表所支持的LDAP服务器中的用户与用户组信息的缺省属性。
使用LDAP Security realm ：
1. 进入管理控制台左窗格中的Security->Realms节点。
2. 点击Configure a new Realm
3. 配置安全域的属性包括域名、角色检查策略、后期重部署、是否忽视部署机密配图等。
表2-1 安全域的配置属性
属性
描述
name
为新的安全域定义的名字：如myrealm
Check Roles and Policies for
定义的安全域针对什么应用进行角色检查的，提供两种可选值：
1、对所有web 应用和EJB；
2、只对部署描述文件中描述的web 应用和EJB；
On Future Redeploys
如果是角色检查策略配置的是只对所有web 应用和EJB时该配置生效，有两个可选值：
1、按照初始的部署描述文件中的角色和策略部署；
2、忽略部署描述文件中的角色和策略部署；
Ignore Deploy Credential Mapping
选择是否在该安全域中选择忽视部署机密配图
4. 配置完数据项后，点击create按钮。

3.2.2.2 口令保护
WebLogic Server对用户登录多次输入用户名或口令错误时，可以配置是否禁止其再次登录。
1. 进入管理控制台，选择Security-Realms
2. 选择要配置的安全域，右面的服务窗口显示该域的配置信息。
3. 选择User Lockout标签，修改相应的配置项。
表2-2 安全域口令保护的配置属性
属性
描述
Lockout Enabled
是否打开或关闭使用登录锁
Lockout Threshold
同一用户非法登录的最多次数，超过该次数将该用户账号上锁
Lockout Duration
每次非法登录上锁的时间周期，范围为1－99999mins。
Lockout Reset Duration
连续非法登录造成用户账号被锁的时间间隔，即用户在这个时间范围内连续非法登录超过最大登录次数后，会导致该账号被锁。范围为1－99999mins
Lockout Cache Size
Server在缓存中维护的非法登录记录的个数，范围为0－99999个
Lockout GCThreshold
Server保存在内存中所有非法登录记录的个数，范围为0－99999
4. 根据系统需要配置对应的属性值，点击apply。
建议配置原则：口令保护配置可根据应用系统的安全级别设定是否使用保护锁和用户非法登录的最多次数等信息。通常配置：
属性
常规配置
Lockout Enabled
Enabled
Lockout Threshold
5
Lockout Duration
30mins
Lockout Reset Duration
1mins
Lockout Cache Size
99999
Lockout GCThreshold
99999

3.2.2.3 测试安全域
1. 进入管理控制台，选择Security-Realms；
2. 选择要测试的安全域
3. 在右面的操作窗口中，选择Testing标签
4. 进入测试窗口，点击Validate this Security Realm按钮。

3.3 用户和组

WebLogic Server的每个安全域中有独立的用户和组的管理，基于某一个安全域上的WebLogic Portal的用户和组的管理可在相应portal的管理控制台中完成，可以为用户分配角色。在WebLogic Server的管理控制台上也可以看到这些用户和组，但是对用户的详细的属性配置，不能在Server的管理控制台上实现。
注意：在Portal的应用中，用户、组和角色的管理BEA推荐在portal的管理控制台上实现。
在本节描述Portal的配置功能有：
v 用户管理
v 组管理
v 角色管理
3.3.1 定义用户
用户是可以在WebLogic服务器的安全域中进行身份验证的实体。用户可以是人也可以是一个软件实体，例如Java客户端。在WebLogic服务器的安全域中每个用户都有唯一的标识，因此管理员必须保证安全域中不存在相同的用户。
在安全域中定义用户需要为每个访问WebLogic服务器安全域中的资源的用户指定一个唯一的名字与口令，在WebLogic Portal管理控制台的Users窗口来定义用户。
WebLogic服务器有一个特殊的用户：weblogic
v weblogic用户具有管理权限。该用户控制系统级的WebLogic服务器操作，如启动与停止服务器，锁定与解锁资源。weblogic用户及其口令是在安装WebLogic服务器时定义。作为一个安全措施，BEA建议你经常更换weblogic用户的，参见“改变系统口令”。
weblogic用户与WebLoigc服务器安全域的用户具有以下相似之处：
v 如果这个用户要访问WebLogic服务器的资源，那么需要有合适的ACL
v 要对WebLogic服务器的资源进行操作，那么需要提供用户名与口令（或者是数字签名）
3.3.1.1 定义一个用户
如果是给组添加一个通用的用户，可以通过WebLogic Server的管理控制台完成，具体见“定义组”中“添加组成员”。如果需要给一个指定的Portal增加用户，需要在该Portal管理控制台上添加组用户，具体如下：
1. 进入管理控制台，在上端的菜单中选择Users&Groups。
2. 在下面的操作窗口中选择要添加用户的组，点击。
3. 进入组管理界面，在右面操作窗口中点击Add Users标签。
4. 在操作页面中点击Create New User按钮，进入用户注册页面
表2-3 用户定义属性
属性
描述
Name
要定义的用户名
Password
定义该用户的口令密码
Confirm Password
确认口令密码
5. 数据填写完毕后，点击Create New User。

3.3.1.2 编辑一个用户
1. 进入管理控制台，在上端的菜单中选择Users&Groups。
2. 在下面操作窗口中选择用户所在的组，在右面窗口中点击Edits Users。
3. 在search窗口中输入要编辑的用户名，点击search。
4. 查找到用户后，选择该用户，点击select users将用户移入编辑区，选择Edit Profile Values，进入用户信息编辑界面。

5. 用户信息编辑界面包括：Edit Group Memberships，Edit User Profile Values和Chang Login Password三项。
a) 点击Edit Group Memberships标签，进入用户属组编辑页面；
I. 点击Add User To More Groups，为用户增加属组；
II. 或选中用户所在的组，点击Remove User From Groups，将用户从该组中删除。
注意：用户所属的组也可以在Weblogic Server管理控制台中添加和删除。

b) 点击Edit User Profile Values标签，进入用户Profile值的编辑页面；
I. 进入用户所在的portal中设置的user Profile信息的配置，窗口中会列出user Profile的配置属性。
II. 点击User Profile的配置属性，查看兵选择对用户要变更的属性值；
III. 点击Update Value。

c) 点击Chang Login Password标签，进入用户口令修改页面；
I. 口令修改配置项。
表2-4变更用户口令属性
属性
描述
New Password
定义该用户新的口令密码
Confirm Password
确认口令密码
II. 修改后点击save。

3.3.1.3 删除一个用户
1. 进入管理控制台，在上端的菜单中选择Users&Groups。
2. 在下面操作窗口中选择用户所在的组，在右面窗口中点击Edits Users。
3. 在search窗口中输入要编辑的用户名，点击search。查找到用户后，选择该用户，点击select users将用户移入编辑区，选择delete user from system。

另外，在服务器运行时，某用户被锁定。执行以下步骤以解除：
1. 打开WebLogic Server管理控制台中的用户窗口。
2. 点击 Unlock Users链接。
3. 在Users to Unlock字段中输入希望解除锁定的用户的名字。
4. 选择在哪一台服务器上解除锁定。
5. 点击 Unlock.
3.3.2 定义组
用户组代表了一组具有某些共同点的用户，例如