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

中国移动WebLogic Portal安全配置手册密 级：文档编号：项目代号：中国移动WebLogic Portal安全配置手册Version 1.0中国移动通信有限公司二零零四年十二月第 2 页 共 5 页第 4 页 共4页拟 制:审 核:批 准:会 签:标准化:版本控制版本号日期参与人员更新说明分发控制编号读者文档权限与文档的主要关系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中定义的角色信息不会在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章 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运行的用户分配相应的权限。对这个成员组的访问应该被限制。3.3.2.1 注册一个组1. 登录管理控制台，在上面的菜单中选择User&Groups。2. 下面左侧的窗口中会列出所有的用户组。3. 选择everyone，点击鼠标右键，选择Add User-Group，则创建一个根组，如果选择任意一个组，点击鼠标右键，选择Add User-Group，则创建一个属于该组的用户组。4. 输入组名，BEA建议组的名字是复数的。如Administrators 而非Administrator。表2-5注册组属性属性描述Name定义的组名5. 输入组属性后，点击create。注意：如果在用户组A上注册组B，在WebLogic Server的管理控制台上，可以看到B组的membership里当前属于A组。3.3.2.2 添加组成员如果需要给一个指定的Portal增加用户，需要在该Portal管理控制台上添加组用户，具体可见“定义用户”中的“定义一个用户”。如果是给组添加一个通用的用户，可以通过WebLogic Server的管理控制台完成，具体如下：1. 登录管理控制台，选择Security-Realm-Users节点。2. 在右面操作窗口中，选择需要添加到组中的用户。3. 点击Groups标签，在possible Groups下选择将用户加入的组，拖至current Groups下。即将该用户添加到该组中。4. 配置完毕后，点击apply。相同地，在用户的Groups窗口中的Current Groups下的组拖至Possible Groups下，即可将该用户从该组中删除。3.4 安全服务提供者管理WebLogic Portal中对第三方的安全服务提供厂商的管理基于WebLogic Server 中的安全域管理机制实现。WebLogic Server的安全域中可以管理的安全服务提供者类型有：v Adjudication；v Auditing；v Authentication；v Authorization；v Credential Mapping；v KeyStoresv Role Mapping第三方的安全服务提供厂商采用标准的接口开发的以上类型的安全应用，都可以接入webLogic Server中使用。每个服务提供商的管理基本相同，以Authorization（认证提供商管理）为例。3.4.1 注册安全服务提供商在WebLogic服务器中，你可以创建一个认证服务提供商，为用户完成认证功能等。认证服务的提供者，要实现weblogic.security.audit.AuditProvider接口。然后安装到WebLogic Server并激活该接口的实现类。在管理控制台的配置选项中就可以看到该认证服务的提供配置菜单。目前WebLogic Server对一些通用的安全认证服务都已预制了提供商的实现接口，可以之间在管理控制台配置认证服务提供者。3.4.2 配置一个服务提供商1. 登录管理控制台，选择Security-Realms-Providers；2. 选择Authentication，右面窗口中列出目前服务器支持的提供商类型；3. 选择要配置的认证提供商，点击configure a new.，例如（RDBMS Authenticator）。4. 输入新的认证服务的名字和注册类型；5. 点击Create。6. 创建完毕后，点击Details标签，进行具体的配置7. 由于选择配置RDBMS Authenticator，输入数据库相关配置信息。8. 点击apply，完成配置。3.5 管理Permission授予WebLogic Portal的角色管理基于WebLogic Server，不同的是，在Server的基础上Portal自有Vistor Entitlement和Delegated Administration两类业务权限，管理员可以在这个权限基础上定义角色。其中Delegated Administration是对用户和组定义管理Portal的具体权限的基本角色。Vistor Entitlement是对用户和组定义管理Portlet和内容的具体权限的基本角色。进入Delegated Administration管理时，管理员可以实例化自己的Delegated Administation Role，并给其分配一定的权限，并为用户和组指定相应的角色，在该角色下用户或组就将具备这些管理权限。定义角色是权限生效的条件有多种：v 按时间：指定日、在指定日后、在指定某日某时间后、在某时间段的、在某两日之间的、在某两个日期的具体时间之间的v 按字符数据：指定的字符串条件的、htpp请求中某属性条件、http会话中某属性条件。可以是满足所有条件，也可以满足任意条件。3.5.1 注册一个角色1. 登录portal的管理控制台，在上面的菜单上选择Delegated Administration或Vistor Entitlements。两个注册角色的步骤相同，我们以Delegated Administration为例。2. 点击左面窗口中PortalSystemDelegator右键选择Add New Role或在右面的窗口右上角点击Add New Role按钮。3. 输入注册的角色名字，点击Create。3.5.2 角色属性配置1. 角色注册后，点击新注册的角色，右面的窗口上有Role Properties标签。2. 点击Role Properties标签进入角色属性配置。3. 可以查看当前角色中包含的用户、组和是否定义了角色的条件表达式等信息，也可以配置该组中的管理员是否能够管理子角色。3.5.3 向角色添加用户和组1. 角色注册后，点击新注册的角色，右面的窗口上有Add User to Role 或Add Groups to Role标签。2. 点击Add User to Role标签进入添加用户。3. 查询要添加的用户，选择要添加的用户名，点击Select Users。4. 点击Add User(s) to Role。5. 点击Add Groups to Role标签进入添加用户组。6. 在列出的用户组中，选择要添加的用户组，点击组名边的蓝色箭头7. 点击Add Groups to Role按钮。3.5.4 编辑角色表达式1. 角色注册后，点击新注册的角色，右面的窗口上有Edit Role Expression标签。2. 选择条件的生效方式：ALL 或ANY3. 根据业务要求编辑条件。4. 点击Save Changes。3.5.5 角色权限设置1. 角色注册后（例如角色名MyPortalAdmin），在管理控制台选择某一功能，比如用户和用户组管理；2. 点击菜单中User&Groups进入用户和组管理；3. 点击everyone或任意一组，右面的操作窗口出现管理窗口，选择Edit Delegated Admin标签，进入权限分配页面；4. 在Delegated Administration Roles中选择要分配权限的角色，点击Add Role；5. 进入权限分配，选择右侧Capabilities下的权限，如Read User/Group等，点击save；6. 属于该角色的用户就具备了读取User/Group的权限。3.5.6 角色使用配置1. 角色注册后，在管理控制台的功能中将该角色赋予了管理权限，可以在角色使用配置中查看并修改2. 在角色中选择右面的窗口上Policy Reference Summry标签。3. 可以看到当前角色已经分配了哪些管理权限。4. 可以选择已有的权限，点击delete，进行删除。3.6 访问控制portletVistor Entitlement是对用户和组定义管理portlet和内容的权限的基本角色。与Delegated Administration相同，进入Vistor Entitlement管理时，管理员可以实例化自己的Vistor Entitlement Role，并给其分配一定的权限，并为用户和组指定相应的角色，在该角色下用户或组就将具备这些对资源操作的权限。对Vistor Entitlement Role的角色定义、属性配置、添加用户和组、编辑角色表达式以及角色使用配置，可参考Delegated Administration即3.5节中描述。本节具体介绍如何向Vistor Entitlement Role分配权限。3.6.1 角色权限设置1. 角色注册后（例如角色名MyEntitlement），在管理控制台选择PortalManagement-Portals；2. 在左面的菜单中选择 Portal Resources-Library-All Portlets，右面会显示操作页面，点击Entitlements标签；3. 进入Entitlements的权限分配窗口，选择刚刚定义好的角色，MyVistor，点击Add Role；4. 进入权限编辑，在Capabilities下选择要分配给该角色的权限，点击save；5. 属于MyEntitlement角色的用户和组就可以对这些portlets进行相应权限的操作了。第4章 单点登录配置目前河南移动的单点登录系统是sitemider5.5第三方的产品，集成在WebLogicPortal中实现的。关于单点登录的配置本章将详细描述使用sitemider5.5 for WLS Agent的安装和配置的步骤，和在sitemider5.5中配置WLS Agent的步骤。具体的单点登录实现原理不作详细描述。4.1 安装SiteMider for WLS AgentWLS Agent是SiteMider部署在WebLogic Server上辅助Sitemider Server完成SSO流程的代理。本节以Windows平台的安装为例描述Agent的安装过程。1. 运行Agent的安装文件；2. 进入Agent安装界面，对license Agreement选择接受；3. 选择安装目录，可以选择缺省或根据需要变更安装目录；4. 选择BEA WebLogic目录，找到WebLogic的安装目录点击install。5. 点击install，进