Java开发网 Java开发网
注册 | 登录 | 帮助 | 搜索 | 排行榜 | 发帖统计  

您没有登录

» Java开发网 » Java Security  

按打印兼容模式打印这个话题 打印话题    把这个话题寄给朋友 寄给朋友    该主题的所有更新都将Email到你的邮箱 订阅主题
flat modethreaded modego to previous topicgo to next topicgo to back
作者 Web service安全性访谈
menzy



版主


发贴: 754
积分: 113
于 2003-02-08 13:40 user profilesend a private message to usersearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
采访对象:Tony Cowan, IBM Software Group 中 Web Services 小组的带头人。他专门研究安全性以及 IBM 的 J2EE 与 Microsoft.NET® 的互操作性。

问:我是一名安全性设计师,在一家业界领先的全球性银行工作,我们这个银行拥有 100,000 多名职员。目前我们正在讨论应该在内部开发哪种类型的标准/指导方针来帮助开发小组实现 Web 服务安全性,或者应该用哪种类型的基础架构和标准产品。我想问一下您会如何解决这种问题?(由 EG 提出)

答:您所在的公司很可能被这个问题所困扰。由于这个领域目前一直处于不断的变化之中,我已经预计到目前实现的短期战略意义上的银行解决方案随着时间的推移将会被取代。您可能想做出这样的声明:“我们的长期目标是使所有使用 Web 服务的应用程序都将依赖用'现成的'基础架构实现的诸项 WS 标准,以便进行安全的对话。但在商业基础架构产品完全支持那些仍在发展中的标准之前,每个应用程序都可以自由增强该基础架构提供的功能以便用一种高效率的、特定于应用程序的方式满足它们对完整性、机密性和不可抵赖性的独立需要。被选中的解决方案需要提供一条合理的迁移路径来实现规定的长期目标。”在提供上面列出的那些东西时,您也指出了安全性实际上是基础架构问题。应用程序开发者应该把他们要实现所需的安全性功能而需要编写的所有代码都保留在某个单独的模块中,将来这个模块会被买来的基础架构代替。

目前,Web 服务开发和部署环境将用它们自身的数字签名、用户名和密码令牌生成和检查 WS-Security 头。我们已经看到过传送二进制令牌 X509 和 Kerberos 票据的演示,但在任一端使用那些东西的基础架构都主要是用手工编码的。一些大型的组织仍在开发胖客户机,这些组织中已经有一部分选择了使用 C# 作为它们的平台,这就在未成熟问题上又引入了互操作性问题。简言之,大多数被部署的 Web 服务都是在使用 SSL 和 HTTP 基本认证(basic Auth)的标准 HTTP 安全性技术满足它们的紧急安全性需要。这个简单的、单一的传输解决方案缺少下列特征:端到端的保护、不可抵赖性、选择性保护(保护消息的一部分)、健壮且灵活的认证机制以及消息级(或称端到端)安全上下文的供应。随着 Web 服务被更广泛地应用,需要用与 WS-Security 相关的机制来代替 HTTP 级安全性。在未来几年内,银行将能够购买实现了某种 WS 标准的基础架构。除非您的应用程序要求更多的解决方案,否则我会避免使用比 HTTP 技术更细致的中间解决方案。遗憾的是,大约有一半的实际应用程序要求的都不仅仅是 HTTPS 提供的解决方案。例如,不可抵赖性是金融机构一直强调的问题,所以有些系统很可能需要实现签过名的请求。

问:如果我正在开发通过 HTTP 服务器(它有基本认证)与 Web 服务进行谈话的 Web 服务客户机,我应该怎样做?除非 Web 服务器管理员禁用了安全性,否则我会一直收到“403 Forbidden”消息。(由 PG 提出)

答:如果您使用的是基于 Apache SOAP 项目的代码,那么就可以使用“Call”类的实例。如果您正在用 WebSphere Studio Application Developer(以下称为 Application Developer)构建客户机,您会看到对生成的代理类中 call 对象的引用。“Call”对象允许您为基本认证设置 HTTP 用户标识和密码,以及中间 HTTP 代理(如果它们存在的话)所需的类似方法。遗憾的是,生成的代理并不提供任何公开嵌入的 call 对象的机制,所以您需要手工添加一些代码以使您的应用程序能够访问 call 对象的那些方法。请注意,生成的代理创建 Call 对象的方法取决于您是否选择了使用同步方法。如果您选择了使用同步方法(缺省值),代理将根据实例化创建一个单独的 call 对象,然后为每个方法使用该对象。如果您选择了不使用同步的关键字生成方法,那么生成的代理将为每次方法调用都创建一个新的 call 对象,所以您将需要在每个方法调用内初始化 HTTP 用户标识等。

问:Axis WS-Security 实现是基于处理程序的,所以不必通过更改代码来保护它。但 SW 构件(artifact)如何管理 WS-Security 的相关信息?例如,您怎样知道是谁发出了请求、怎样知道消息是否被加密了,如何指定用来签发响应的凭证。WebSphere Application Server 和 WebSphere Studio Application Developer 何时支持 WS-Security?据我所知,版本 5.0 目前还不支持 WS-Security。WS-Policy、WS-Trust 和 WS-Privacy 什么时候可用?它们将在什么时候被集成到 IBM 产品中?(由 PL 提出)

答:我们首先来看一下编写 Web 服务的开发者如何访问传入的请求的头部分中的信息,以及如何指定外发请求和回复的头部分中的信息。WebSphere Application Server(以下称为 Application Server)处理您所需的大部分内容的方法是通过配置文件。这些文件是 IBM 的扩展,它们使您能够指定用什么证书签署或加密到某个服务的消息以及期望从应答的服务中得到什么反馈等这些内容。当然,参与交换的服务器端也有类似的配置文件允许它对传入的请求进行认证,并对传出的应答进行签署和加密。从“业务”代码中提取并且深入到部署领域的这种“基础架构”需求在大多数情况下都很有意义,与普通 J2EE 的情况类似。例如,在写 EJB 时,通常您并不关心是谁调用了 EJB,并且喜欢依赖容器来确定这次调用是否经过了授权。如果确实需要知道调用者是谁(以便进一步限制授权,或者进一步确定需求的审计类型),您就可以调用 getCallerPrincipal() 。在实现您的 Web 服务时,您可以使用这个 EJB API 来确定调用程序主体(caller principal)。显然,您需要把您的 Web 服务实现为 EJB 而不只是 Java™ bean。所以,总之您并没有通过程序控制要使用什么密钥或者要在 WS-Security 头中包含什么部件。但是,您必须在配置文件中明确指定那些内容,这是您通常想做的。有时候如果您需要知道与传入的请求关联的主体,您可以用 EJB 实现自己的 Web 服务,然后用 getCallerPrincipal() 查清楚是谁调用了您的服务。

WebSphere Application Server V5 提供了对用户名令牌、X509、身份断言、签名和加密的支持作为“技术预览”,这表示它们还没有得到正式支持。技术预览是供开发和计划之用的。目的是使客户可以开发能用 Application Server 的后继发行版进行部署的应用程序。在这些发行版面世之前,IBM 并没有宣布它们要提供什么功能,但我希望在 2003 年年中左右这些功能能够得到官方支持。IBM 正继续制定计划中提到的规范,一旦发布了这些规范我们将致力于把它们结合到我们的产品中。

问:LTPA 功能怎么了(例如,不是一个浏览器客户机)或者您是否需要对每个请求都进行重新认证?(由 IC 提出)

答:轻量级第三方认证(Lightweight Third Party Authentication ,LTPA)是用来进行认证的 IBM 专有解决方案。在一般的 Web 服务环境中不应该使用这个解决方案。目前的解决方案是使用 SOAP 信封头(SOAP Envelope Header)中的 Web 服务安全性(Web Services Security ,WS-Security)头来识别和认证每个请求的用户。这种机制的功能与 HTTP Basic Authentication 头几乎一样,它也是对每个请求都提供用户名和密码。将来的实现将有选择地把 Kerberos 票据或 X.509 证书结合起来进行认证。如果您正在“内部”实现 Web 服务并且拥有对客户机代码的控制权,您就可以把 Application Server 配置为生成 LTPA 令牌并让客户机在 cookie 中返回它们。这样 Application Server 就可以识别每个请求的用户。您还必须考虑您的挑战机制以确保它不要求用户的交互。在 J2EE 1.3 环境(Application Server 5.x)中,J2EE 为这种认证引入了回调(Callback)机制(以防万一用户想用自己的机制来提供安全性信息)。同时,基本认证或证书仍可以发挥作用,但基于表单的挑战更加复杂,因为您无法用 Web 服务请求发送认证信息了。使用 SOAP 信封外的认证机制(比如来回传送 cookie)就要依赖特定的协议(HTTP)。而且,越来越多的人正指望使用基于消息的传输,并希望提供“异步”调用选项。要使您的 Web 服务能够在各种底层协议上工作,请使用 WS-Security 头进行认证,因为这个头可以用所有的协议发送。请注意,WebSphere 的 WS-Security 实现将会是版本 5.0 阶段的技术预览。

问:WebSphere Studio Application Developer 构建工具什么时候会支持 XML Signatures、WS-I 等?(由 KH 提出)

答:版本 5.0 为 WS-Security 头提供了用户名令牌、x509 证书、身份断言、数字签名和加密作为技术预览。希望以后的版本能“支持”它们。

问:我如何用 WSDL 表达以上所有这些东西?WSAD 向导可以构建它们吗?(由 KH 提出)

答:版本 5 技术预览并不用 Web 服务描述语言(Web Services Description Language,WSDL)文件表达安全性需求。它使用 IBM 扩展文件指出服务提供了或者要求什么样的安全性。这种文件是手工创建的。将来,您可以寻找一种要么直接用 WSDL,要么分开并从 WSDL 引用这两种方式创建 WS-SecurityPolicyAssertions 的 GUI 工具。

问:它是怎样实现互操作的?(由 KH 提出)

答:尽管运行时并不使用 WS-Policy 来描述 WS-Security 头的元素(它使用 IBM 配置文件),产生的 WS-Security 头仍遵照当前的 WS-Security 提议。它们与支持 WS-Security 提议标准的其他运行时兼容。

问:我如何通过中介体传播这一点?(由 KH 提出)

答:根据 WS-Security 规范,您可以为特定的操作者(actor)“指定” WS-Security 头。如果您只是想把安全性信息传播到一个特定的中介体,您可以为该操作者指定一个特定的 WS-Security 头。在一个 SOAP 信封内可以有多个 WS-Security 头。我们很欢迎中介体把内容添加到为另一个操作者绑定的 WS-Security 头,但它们绝不可除去这个头(根据 WS-Routing)。

问:我需要注意哪些方面?哪里有漏洞?我的安全性如何?(由 KH 提出)

答:我们还没有“已经支持”的产品,所以我们在生产时还没考虑这一点。这一块正在改变中,您在设计如何使用它的过程中投进去的精力也应该考虑在内。希望将来工具能帮您承担更多的工作。关于漏洞以及它的安全程度,我认为还是相当安全的。这是用笨方法使用成熟的技术,但仍不失为一种成熟的技术。如果您正在使用带 X.509 证书的那一版技术预览 WS-Security 头,那就可以了。与平常一样,拥有好的技术才只是开始。您需要确保人们准备使用它,并且关键的存储是安全的。

问:我如何把信任从一个服务传送到另一个服务?(由 KH 提出)

答:新兴的标准(即 WS-Trust 及相关标准)将提供用来委托凭证的机制。

问:在没有协议(JMS/SMTP/HTTP/xxx)的情况下,这个机制能发挥多大用处?(由 KH 提出)

答:在没有传输协议的情况下,它也能充分发挥作用,因为它是包在 SOAP 信封中的 WS-Security 头内。所以,在某种意义上,您是被绑定到 SOAP 的。如果您把 Web 服务定义为“用 WSDL 描述的某种东西”,那么用一致的方式跨非 SOAP 服务为您描述和实现安全性就需要做更多的工作。

问:为调用其他 Web 服务的 Web 服务实现单点登录的最佳方法是什么?(由 RR 提出)

答:通过用“其他”Web 服务的安全性需要配置中间 Web 服务的 IBM 扩展配置文件,您可以高效地提供“单点登录”。应用程序代码不需要考虑认证信息。

问:带 Apache SOAP 的 WebSphere Application Server 5.0 中支持 WS-Security 的哪些部件?(由 RR 提出)

答:从开发的角度来看,IBM 扩展了 SOAP 使它更易于使用,同时也解决了实现方面的一些局限性。从“有线格式”的角度来说,根据 IBM 实现生成的消息是被基于 Apache SOAP 和其他规范的其他实现使用的。现在,WebSphere Studio Application Developer V5 将构建生成并检查数字签名,并且运行在 Application Server 5.0 附带的 SOAP 实现上的代理和服务器。技术预览考虑到了数字签名、加密、用户标识/密码、X.509、身份断言,并且运行在新运行上。它还附带 WebSphere ApplicationServer V5,但没有生成配置文件(它们指定应该包含什么样的 WS-Security 头)的工具支持。

问:我如何将 WS-Security 集成到我的 J2EE 应用程序中?(由 RR 提出)

答:Application Server 5.0 附带的技术预览将为您创建一个安全上下文。请使用常规的 J2EE 授权过程授予对实现为 EJB 的 Web 服务的访问权。如果您的 Web 服务调用 EJB,安全上下文可能(也可能不)被传播,这取决于被调用 EJB 的配置。

问:我怎样才能把对单个 Web 服务的访问限制到经过授权的用户/角色?(由 RR 提出)

答:把您的 Web 服务实现为 EJB,然后按照标准 EJB 实践(通过部署描述符和 IBM 扩展文件)配置对 EJB 的访问权。

问:我想把对视图帐户信息的访问权限制到帐户的所有者。有没有一种方法可以通过配置或我的 WebSphere Application Server Java™ 代码中的编码规则完成这项任务?(由 RR 提出)

答:直接用使用 EJB 时的相同选项和限制。Tivoli 提供了一种解决方案,使得业务代码不必再实现那类授权扩展。这个解决方案叫 Privacy Manager,它与 WebSphere Application Server V5 授权集成在了一起。

问:加密部分 Web 服务消息时的主要问题是什么?我为什么不可以直接在请求者和提供者间使用 SSL?(由 RR 提出)

答:关于这个问题有好几个方面。首先,有时候消息只有一部分包含敏感信息,所以如果加密整个消息的话就会浪费周期时间。有时候您可能想根据消息中的一些内容路由消息。如果整条消息都为最终的接收方加了密,那么中间的接收者就无法把消息内容用于路由或其他目的。还有可能是您期望多个“操作者”对您发送的消息进行操作,您可能想为不同的操作者加密消息的不同字节。其次,SSL 还提供了一个基于连接的加密解决方案,所以加密状态持续不了多个跳转,也不能持久。为了使消息具有不可抵赖性,您可能想使经过加密或签署的消息持久存在。

问:我怎样才能在 Microsoft.NET 和 WebSphere Application Server 间建立安全的消息交换?根据加密、认证和授权吗?(由 RR 提出)

答:请参阅 Microsoft™ 手册了解如何配置该产品,但您可以通过 IBM 扩展配置文件为认证、加密和签名配置 WebSphere 技术。您可以使用标准 J2EE 部署描述符与那些文件的 IBM 扩展的组合来配置 WebSphere Application Server 服务器上的权限。



作者 Re:Web service安全性访谈 [Re:menzy]
lyon



发贴: 0
积分: 0
于 2003-03-11 22:46 user profilesend a private message to usersearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
好文!期待更多中。。。。。。。



flat modethreaded modego to previous topicgo to next topicgo to back
  已读帖子
  新的帖子
  被删除的帖子
Jump to the top of page

   Powered by Jute Powerful Forum® Version Jute 1.5.6 Ent
Copyright © 2002-2021 Cjsdn Team. All Righits Reserved. 闽ICP备05005120号-1
客服电话 18559299278    客服信箱 714923@qq.com    客服QQ 714923