中国移动WebLogic Portal安全配置手册Word文档下载推荐.docx
- 文档编号:18359280
- 上传时间:2022-12-15
- 格式:DOCX
- 页数:53
- 大小:936.24KB
中国移动WebLogic Portal安全配置手册Word文档下载推荐.docx
《中国移动WebLogic Portal安全配置手册Word文档下载推荐.docx》由会员分享,可在线阅读,更多相关《中国移动WebLogic Portal安全配置手册Word文档下载推荐.docx(53页珍藏版)》请在冰豆网上搜索。
4
读取
5
目录
第1章WebLogicPortal安全概述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章3A8
2.1认证(authentication)8
2.2授权(authorization)9
2.3审计(auditing)10
第3章WebLogicPortal资源的访问控制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访问控制portlet36
3.6.1角色权限设置37
第4章单点登录配置39
4.1安装SiteMiderforWLSAgent39
4.2SiteMider策略服务器配置WLSAgent42
4.3配置WLS上的安全提供商50
第5章WebLogicPortal配置SSL53
5.1配置SSL53
5.1.1获得私钥与数字证书53
5.1.2保存私钥与数字签名54
5.1.3配置单向SSL56
5.1.4配置双向SSL59
附录术语表61
第1章WebLogicPortal安全概述
1.1工作原理
1.1.1安全框架体系架构
BEAWebLogic8.1安全框架的目标是为应用程序安全提供一种全面、灵活和开放的方法。
与BEAWebLogic以前版本中的安全领域(realm)不同,新的框架适用于所有的J2EE对象,包括JSP、servlet、EJB、JCA适配器、JDBC连接池以及JMS目标。
此外,新的框架还被用来提供安全的Web服务开发所必需的认证和授权服务。
它符合所有的J2EE1.3安全性要求,例如JAAS(用于与认证和授权相关联的对象)、JSSE(用于通过SSL和TLS进行的通信)和SecurityManager类(用于代码级安全)。
这一架构的核心是安全和业务逻辑的分离。
业务逻辑在适当的容器(可以是JSP、servlet或EJB容器)里执行。
当容器接收到一个针对它包含的对象的请求时,它把整个请求及其整个上下文委托给安全框架。
框架则根据是否通过请求,返回yes或no决策。
由于向安全系统提供了目标对象也可以使用的相同信息,所以这个方法把业务逻辑从安全因素里分离了出来。
二者都利用这项信息来实现自己的责任:
框架实施安全策略,对象则执行业务逻辑。
当安全框架接收到委托的请求时,它以图1所示的形式管理安全处理。
这个处理非常灵活,其中的精细步骤在许多系统中都见不到,例如动态的角色映射、动态授权以及多个授权者的调整。
在每一步里,框架都会通过对应的服务提供者接口(SPI)把处理委托给一个自带的、第三方的或者自定义的提供者。
这个架构使BEAWebLogicServer&
Portal能够把所有必要的信息路由给每种类型的服务提供者,以便应用程序可以充分利用专业化安全服务的特长。
图1-1.安全框架体系架构
1.1.2服务提供者集成
安全框架仅仅管理安全处理。
每一步骤都要求服务提供者来执行。
BEAWebLogic8.1为每个步骤包含提供者,但是这些提供者都使用框架SPI。
其他的提供者也都可以访问同样的工具。
这些SPI包括:
∙认证。
∙身份断言。
∙角色映射。
∙授权。
∙判决。
∙凭据映射。
∙审计。
1.2功能与定位
BEAWebLogicPortal安全管理功能包括:
v安全域管理:
包括用户、组和角色管理;
安全服务提供者管理;
安全域管理中,WebLogicportal采用了WebLogicServer提供的安全域(securityrealm)机制管理用户,用户组和加载第三方安全厂商的信息。
在原Server的安全域上,对用户和用户组的管理增加了新的属性,通过每个portal管理控制台创建的用户和组信息也可以通过WebLogicServer的管理控制台进行属性配置和修改。
Portal中的角色管理是Portal的独立的管理模块,因此在Portal中定义的角色信息不会在WebLogic的GobalRoles进行配置。
vPortal管理Permission的管理;
Portal对管理权限采用Delegate方式实现权限分配,在Portal管理控制台中可以配置管理权限的Delegate角色,为Delegate角色分配管理权限。
属于该Delegate角色的用户成员或用户组都具备Delegate角色中的管理权限。
vPortal访问控制Portlet的管理;
与管理权限分配机制相似,Portal对访问控制Portlet也通过对访问控制角色定义不同的权限实现。
在Portal的管理控制台中定义VistorEntitlement角色,并将Portlet的管理权限分配给定义的VistorEntitlement角色。
属于该VistorEntitlement角色的用户成员或用户组都具备角色中指定的内容资源管理的权限。
v单点登录:
包括WebLogicPortal内嵌的单点登录和集成第三方的单点登录系统两种模式;
单点登录方面WebLogicPortal模块化安全域模型构成了WebLogicPortal与第三方安全产品集成的基础。
众多第三方安全产品厂商提供了支持WebLogic的SSO产品,通过配置WebLogicPortal使用厂商提供的安全域实现单点登陆。
WebLogicPortal集成的优点是使门户应用能够与第三方安全服务共享用户名和用户组/角色,进而实现无缝的安全认证。
因此,储存于外部安全库的用户名能够被WebLogicPortal识别。
另外,来自于第三方安全产品的组成员信息也能被用于定义组的门户,并为用户访问门户页面和Portlet建立基本的授权。
本文档考虑到河南移动的SSO采用了第三方的安全产品(Netegrity的Siteminder),单点登录的安排配置主要针对与Sitemider产品集成做详细介绍。
vSSL协议。
SSL协议保证用户在使用服务在信息通道上的安全,WebLogicPortal的SSL是基于WebLogicServer实现的,主要内容包括:
∙获得私钥和数字证书;
∙保存私钥和数字签名;
∙配置单向SSL;
∙配置双向SSL。
1.3特点与局限性
1.3.1集成的安全性
BEAWebLogicServer8.1为企业应用程序提供了解决整体安全问题的集成方法。
这个方法在业界是独一无二的,其他应用程序服务器供应商、开放源代码产品和专用的安全解决方案都没能达到这样的程度:
可以提供强大的、灵活的、可扩展的安全架构。
有了这个框架,应用程序安全不再是亡羊补牢了:
它变成了应用程序基础架构的一项功能,并从应用程序分离出来。
有了这个框架,任何部署在BEAWebLogicServer上的应用程序,都可以得到安全保护,或者通过服务器自带的安全特性,或者通过对开放安全服务提供者接口进行扩展以实现定制安全解决方案,或者通过插入来自客户用作企业标准的主流安全供应商的其他专门的安全解决方案。
1.3.2兼容性
新的BEAWebLogic安全框架革新了应用程序层的安全性。
但是,您可能已经在WLW6.X的安全领域上做了相当的投资。
您可能不想立即升级安全模型,所以框架提供了一个领域适配器,用于向后兼容性。
实质来说,这个适配器就是BEAWebLogic6.x中完整的安全子系统,而框架把它和其他实现认证和授权SPI的服务提供者同样对待。
在服务器启动时,适配器像以前一样从部署描述符里提取访问控制定义。
在运行时,它通过对应的SPI,接受框架委托给它的认证和授权请求。
从您的角度来看,BEAWebLogic8.1的安全性工作起来就像6.x的安全性一样。
从服务器的角度来看,领域适配器则完全集成进了8.1安全框架。
一旦您决定了迁移到安全框架,您可以方便地从6.x的定义里导入安全信息。
您甚至还可以同时用领域适配器和安全框架本身的提供者,以便确认升级行为正确无误。
1.3.3安全管理特性
1.3.3.1外周认证
在SSO或集成安全认证的情况下,是由BEAWebLogic自己的认证器之外的部分来负责担保请求者的身份。
这个部分有可能是BEAWebLogicServer的SSL层,也可能是Kerberos系统,也有可能是居中的Web服务。
在这些情况下,第三方提供应用程序可以验证的令牌。
只要应用程序相信第三方,就可以接受一个通过验证的令牌,好像它就是原始用户凭据一样。
安全框架使用了非常简单的机制来与这类系统协作。
第三方需要做的全部工作,就是把它的令牌放在HTTP头里。
安全框架检查令牌,并根据令牌类型分配合适的服务提供者。
如果进来的是来自中立SSL认证的X.509证书,框架分配的提供者会有这样的能力:
验证证书链,一直验证到根证书授权机构,甚至还可以用在线证书状态检测协议来检查证书目前的有效性。
如果进来的是Kerberos凭证或安全令牌,适当的提供者会对令牌解码,并执行必要的验证。
一旦提供者执行完验证,就会把凭据里的身份映射成本地用户。
框架用这个本地用户回调JAAS,然后JAAS填充J2EE1.3所规定的主体(Principal)对象。
所以,这个方法在提供巨大灵活性的同时,完全遵守适当的标准。
第三方提供者或企业开发团队可以把任何认证技术与BEAWLS集成在一起,只要这些技术能够填充HTTP头。
集成BEAWLS应用程序和WebSSO解决方案很容易,因为它们中的大多数,包括SAML,都已经使用cookie或HTTP头了。
1.3.3.2角色关联
多数应用程序安全模型使用角色的概念。
角色在用户和资源之间提供了一个迂回层,可以提高管理的方便性。
它们很像组,但是更加动态。
通常来说,安全管理员根据规划把用户分配到一个组,然后在用户的工作责任变化时,再修改这个分配。
角色的变化则更频繁,甚至根据具体情况,从请求到请求就发生变化。
安全框架既支持组,也支持角色。
图1-2所示的屏幕截图显示了可以很容易地以图形化方式配置组和角色。
图1-2.动态角色映射过程
1.3.3.3凭据映射
企业通常想把对后台数据库、打包应用程序或者传统系统的每一个请求,都绑定在一个最终用户身上。
所以,当J2EE对象代表用户访问后端系统时,就必须向系统提供适当的凭据。
基本的问题是,要把J2EE主体映射到后端系统凭据。
自带的服务提供者解决了多数情况下用户名/口令凭据的问题。
每个BEAWebLogicServer实例都有一个内嵌的LDAP目录,在里面保存了每个有效主体和后端系统组合的加密过的用户名/口令对。
对安全不断增长的关注,有可能形成对更复杂的第三方或定制提供者的需求。
某些数据库的最新版本可以使用Kerberos凭证。
同样,一些打包应用程序的最新版本可以使用不同形式的强认证,而许多主机系统使用RACF。
安全框架能够轻松地适应支持这些替代项的第三方或定制提供者。
第2章3A
2.1认证(authentication)
认证是第一道防线。
知道请求者的身份,应用程序层就能决定是否通过他们的请求,并对攻击者布下一道防线。
从根本上说,所有认证方案的工作方式都相同。
它们提供凭据来建立身份,并提供某种手段来验证凭据。
但是,凭据的形式和验证机制多种多样。
企业选择每一种认证方案都取决于大量因素,包括受保护资源的敏感程度、预期的攻击模型以及解决方案生命周期的成本。
多数情况下,企业已经有了一种或多种认证方案在使用中,所以中间件必须与这些方案协作,接受它们的凭据,采用它们的验证机制。
没有这种协作,企业就不得不采用口令这样的最小公因子方案,这样就可能把这类中间件的应用限制在一些低价值的应用程序中。
Web单点登录(singlesign-on,SSO)的问题更加困难。
SSO的动机来自Web应用程序的分布式本质。
从用户的角度来说,一个应用程序可以实际包括大量不同的软件组件,运行在大量不同服务器上,甚至可以由大量不同的组织操作。
但是,用户不想每次单击一个链接,因为是到不同地点的链接,就得重新提交凭据。
用户的体验应当是无缝的。
采用现有认证方案之前的问题,只是要求理解凭据格式并与验证机制集成。
但是,使用WebSSO时,用户在许多情况下甚至不想提供凭据。
不用看到用户的凭据就能建立用户身份的技巧,需要在处理用户会话的两台服务器之间进行复杂的后台通信。
有大量专有的解决方案,而且有些已经成为这些通信的标准,但是对于可以预见的未来,很有可能一个特定应用程序必须要支持多种技术,所以必须要有一个开放模型。
处理其他Web应用程序组件涉及到与前端的协作,但是中间件基础架构还必须与后端协作。
数据库已经存在了很长时间,企业对于数据库安全非常小心在意。
企业实际上不相信前端和中间件层。
如果攻击者攻陷了这些层里的任意一个,就有可能发送一系列数据库请求,请求可能会返回数据库里保存的大量数据。
同样,如果前端或中间件组件有缺陷,那么有可能会为错误的用户请求数据,因而可能造成私密信息的泄漏。
因此,许多企业想把每个数据库请求都绑定到一个具体终端用户上,包括用于建立用户身份的适当凭据。
应用程序必须做好准备来传递这个信息。
2.2授权(authorization)
一旦应用程序已经生成了请求者的身份,就必须确定现有安全策略集是否允许它通过该请求。
通常情况下,中间件基础架构(例如J2EE)使用静态的基于角色的系统。
在用户规划的时候,安全管理员会明确地给用户分配角色,然后当条件要求时,再更新这些分配。
在组件部署期间,安全管理员指定允许哪些角色访问组件。
在运行的时候,如果请求来自具备必要角色的用户,那么应用程序就许可该请求。
这种静态的方法忽视了许多业务策略的动态本质。
想想控制银行帐户、费用报告、银行出纳等策略的例子。
对于银行帐户,每个客户都应当只能访问他自己的帐户。
对于费用报告,经理只能批准规定额度内的费用,而且不能批准自己的费用。
对于银行出纳来说,只有在他们当班的时候才能履行出纳的职责。
甚至还有更加复杂的策略,这时授权取决于分配给用户的角色以及请求的内容的组合。
中间件基础架构必须明确地支持这些种类的动态策略,或者至少提供足够的上下文来做这些专业安全工作。
对于动态授权的需求增加了管理问题。
我们当然不想强迫安全管理员成为编程语言(如Java)专家。
当然,会有一些非常规情况需要一些定制编程,但是例行公事地更新费用报告授权的资金额度并不需要编程。
在更现实的层面上,我们也不想强迫管理员去深入XML格式的部署描述符,然后重新部署组件以更新角色分配。
安全管理员需要设计良好的、图形化的用户界面,让他们可以执行所有例行任务,以及大多数运行时的非例行任务。
管理用户列表以及为用户分配的角色、修改组件的保护级别、配置动态约束,都应当只需要一点点时间。
对安全管理员来说,更大的麻烦来自从一个授权服务迁移到另外一个。
由于授权决策的复杂性,许多企业依赖专业化的服务,所有应用程序都把这类决策委托给专业服务。
当需要执行主要的版本更新或转换到另外一个服务的时候,管理员就面临了困境。
什么时候转换到新提供者?
要关注的是新服务中的缺陷或配置问题。
管理员们不想因为转换就造成扑天盖地的不当授权或错误地拒绝用户。
他们实际喜欢的是同时应用二套系统,关注新旧服务之间决策的差异,但是这种方法,要求中间件基础架构要具备更高的与安全生态系统中其他部分协作的能力。
2.3审计(auditing)
如果一个应用程序能够同时使用两种不同的授权服务,那么选项之间的差异会是非常值得注意的事件,而管理员可能想知道这些差异。
不幸的是,多数中间件基础架构忽略了这类安全审计。
恰当的审计不仅仅是把信息写进磁盘。
为了支持验证、侦测和调查职责,管理员需要在单一位置记录所有安全事件,需要对特殊的重要事件提供主动通知,还需要迅速搜索记录的能力。
安全管理员负责保证与信息访问有关的企业策略的实施。
显然,他们首先必须指定这些策略,最好是用前面所说的那种生产力高的界面。
然后他们必须定期检查审计记录,确认这些策略实际得到了执行。
政府管制或商业合约有可能需要这类审计。
管理员会抽样具有代表意义的事务集合,并跟踪它们通过各种不同应用程序组件的路径,从而确保每一步上的安全措施都得到了正确执行。
管理员需要经过整理的审计轨迹,否则他们就不得不花费大量精力,手工地把不同位置的日志汇集起来。
他们需要详细的记录,否则就无法确定策略是否得到完全遵守。
对于潜在的违反规则的行为作出响应,是安全管理员的另一项主要职责。
响应包括两步:
侦测和调查。
首先,他们要有这样的能力,可以指定在什么条件下,安全系统会主动通知他们。
这些条件可以包括交易值(例如超过一百万美金的资金转移)或者事件模式(例如访问敏感功能时使用弱加密连接的客户峰值)。
一旦收到通知,管理员必须能够迅速搜索日志,以便判断是否确实发生了违规行为,并确定损害的程度。
这些搜索可能包括复杂的条件,而且必须针对活动的审计轨迹执行,这样他们就可以在某个具体攻击展开的时候对其进行跟踪。
这些需求使得审计子系统成为软件的重要组成部分,所以中间件提供者必须付出切实的努力来完善它。
注意:
在应用程序安全性上,有许多具体的挑战。
然而就像应用程序安全性自己的核心一样,WebLoigcPortal安全解决方案的核心也非常简洁。
1.在安全策略和业务逻辑之间,我们拥有一个干净、优美的抽象。
2.我们有一个简单的、声明性的接口,用来实时地管理安全策略。
3.我们有一个开放、灵活的架构用来与安全服务集成。
这些实践避免了安全和业务逻辑混杂在一起的问题,理顺了安全管理,支持与安全生态系统的其他部分进行协作。
BEAWebLogic安全框架提供了这些关键能力。
第3章WebLogicPortal资源的访问控制
3.1安全配置步骤
在WebLogic服务器中,安全管理主要通过配置定义安全策略的属性来实现。
可以用管理控制台定义安全策略。
在管理控制台中,你应该为所分发的应用指定设置与安全相关的属性:
v域
v用户与组
v角色
vSSL协议
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应用部署的安全域,安全域在WebLogicServer81后的版本不在提供file、catch、windowsNT、UNIX等安全域的配置功能,只保留了LDAP安全域的配置,下面介绍LDAP安全域配置内容。
配置安全域一节包括:
●创建安全域
●配置用户登录锁
此外,安全域中还包含各个实体的管理如:
用户、组、角色、安全服务提供者等等管理,具体的管理配置功能见“用户和组”与“安全服务提供者”。
3.2.2.1创建LDAP安全域
LDAP安全域通过轻量级目录访问协议(LDAP)服务器对客户端请求进行验证。
该服务器把组织中的所有用户都放在LDAP目录中以进行集中管理。
LDAP安全域支持OpenLDAP,NetscapeiPlanet,MicrosoftSiteServer与NovellNDS等主流LDAPServ
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 中国移动WebLogic Portal安全配置手册 中国移动 WebLogic Portal 安全 配置 手册