中国移动WebLogicPortal安全配置手册模板.doc

密 级：文档编号：项目代号：中国移动WebLogic Portal安全配置手册Version 1.0中国移动通信二零零四年十二月拟 制:审 核:批 准:会 签:标准化:版本控制版本号日期参与人员更新说明分发控制编号读者文档权限和文档关键关系1创建、修改、读取负责编制、修改、审核2同意负责本文档同意程序3标准化审核作为本项目标标准化责任人，负责对本文档进行标准化审核4读取5读取目 录第1章WEBLOGIC PORTAL 安全概述11.1工作原理11.1.1安全框架体系架构11.1.2服务提供者集成21.2功效和定位31.3特点和不足41.3.1集成安全性41.3.2兼容性51.3.3安全管理特征5第2章3A82.1认证(authentication)82.2授权(authorization)92.3审计(auditing)10第3章WEBLOGIC PORTAL资源访问控制123.1安全配置步骤123.2系统安全配置133.2.1更新系统口令133.2.2配置安全域153.3用户和组193.3.1定义用户193.3.2定义组243.4安全服务提供者管理273.4.1注册安全服务提供商283.4.2配置一个服务提供商283.5管理Permission授予293.5.1注册一个角色303.5.2角色属性配置313.5.3向角色添加用户和组323.5.4编辑角色表示式333.5.5角色权限设置343.5.6角色使用配置353.6访问控制portlet363.6.1角色权限设置37第4章单点登录配置394.1安装SiteMider for WLS Agent394.2SiteMider策略服务器配置WLS Agent424.3配置WLS上安全提供商50第5章WEBLOGIC PORTAL配置SSL535.1配置SSL535.1.1取得私钥和数字证书535.1.2保留私钥和数字署名545.1.3配置单向SSL565.1.4配置双向SSL59附录 术语表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中定义角色信息不会在WebLogicGobalRoles进行配置。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采取了第三方安全产品（NetegritySiteminder），单点登录安排配置关键针对和Sitemider产品集成做具体介绍。v SSL协议。SSL协议确保用户在使用服务在信息通道上安全，WebLogic PortalSSL是基于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 ServerSSL层，也可能是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章 3A2.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_projectsdomainsmydomain目录中fileRealm.properties文件中。这个口令能够用于这个域管理服务器和全部和这个管理服务器关联受管服务器。注意：WebLogic服务器只能用weblogic用户来开启。保留在fileReamln.properties文件中口令是经过加密。WebLogic服务器对被加密口令进行散列化处理，从而深入保护了口令。为了提升安全性，我们提议你常常更新系统口令。每个布署WebLogic服务器必需有唯一口令。以下是更改系统口令步骤：1在管理控制台中打开Users窗口2在User属性中输入webloigc3在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 Realm3. 配置安全域属性包含域名、角色检验策略、后期重布署、是否忽略布署机密配图等。表2-1 安全域配置属性属性描述name为新安全域定义名字：如myrealmCheck 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-Realms2. 选择要配置安全域，右面服务窗口显示该域配置信息。3. 选择User Lockout标签，修改对应配置项。表2-2 安全域口令保护配置属性属性描述Lockout Enabled是否打开或关闭使用登录锁Lockout Threshold同一用户非法登录最数次数，超出该次数将该用户账号上锁Lockout Duration每次非法登录上锁时间周期，范围为199999mins。Lockout Reset Duration连续非法登录造成用户账号被锁时间间隔，即用户在这个时间范围内连续非法登录超出最大登录次数后，会造成该账号被锁。范围为199999minsLockout Cache SizeServer在缓存中维护非法登录统计个数，范围为099999个Lockout GCThresholdServer保留在内存中全部非法登录统计个数，范围为0999994. 依据系统需要配置对应属性值，点击apply。提议配置标准：口令保护配置可依据应用系统安全等级设定是否使用保护锁和用户非法登录最数次数等信息。通常配置：属性常规配置Lockout EnabledEnabledLockout Threshold5Lockout Duration30minsLockout Reset Duration1minsLockout Cache Size99999Lockout GCThreshold999993.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服务器有一个特殊用户：weblogicv weblogic用户含有管理权限。该用户控制系统级WebLogic服务器操作，如开启和停止服务器，锁定和解锁资源。weblogic用户及其口令是在安装WebLogic服务器时定义。作为一个安全方法，BEA提议你常常更换weblogic用户，参见“改变系统口令”。weblogic用户和WebLoigc服务器安全域用户含有以下相同之处：v 假如这个用户要访问WebLogic服务器资源，那么需要有适宜ACLv 要对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 定义组用户组代表了一组含有一些共同点用户，比如，在企业同一部门工作。用户组作用关键是为了对一组用户进行有效管理。假如在角色定义中一个组被授予了一个权限，那么组中全部组员全部含有该权限。缺省情况下，WebLogic Portal服务器包含以下用户组：v Administrators组，该用户组给那些负责开启和停止服务器、维护WebLogic服务器运行用户分配对应权限。对这个组员组访问应该被限制。v Deployers组，该用户组给那些负责布署web Application 、EJB、Enterprise Application用户分配对应权限。v Monitors组，该用户组给那些负责监控系统资源使用情况、性能并进行调优用户分配对应权限。v Operators组，该用户组给那些负责查看并修改资源属性和server生命周期中参数用户分配对应权限。v PortalSystemAdministrators组，该用户组给那些负责管理、维护WebLogic Portal运行用户分配对应权限。对这个组员组访问应该被限制