一起分享一起成长 - goCom - SOA中国第一社区

goCom - 面向构件与SOA社区讨论区 - SOA和WebService

SOA综合 WebService OSGI ESB SOA 我有话说

[无发表权] 请登录或者注册版主: yanfei ScottWang

SSL + WS-Security = Web Service安全保障

#1楼

总分 116 分
财富 273

威望 27
排名 :(
段位

web service 的安全性策略需要根据性能和安全做一定的折中，SSL硬件的实施加上WS-Security可以保证服务的安全性和性能的平衡。今天早晨看了一下blog的留言，发现有位朋友给我留了言，提到了他正在研究SCA，同时也有些困惑，当在异构分布式环境的情况下，不论是否使用SCA规范来实现，都采用Web Service来完成面向服务的服务调用，觉得SCA没有什么优势可言。其实这是一个误解，SCA框架规范并不是一个具体的业务场景解决实施规范，它是一种框架结构性规范，它的精华部分主要在于：一.将抽象和封装由对象提升到了业务组件模块二.框架的可扩展性(也就是因为没有实现的约束，才会能够易于扩展)。当然这两点所带来的好处那就是在这么一个精炼的框架核心规范下，不断融入了外界的各种好的技术和理念，就好比现在的Web2.0最重要的一点特质，规范的只是接口（用于统一交互的管理），开放的是接口下的任何贡献，主动参与和主动的集成将会使得框架越来越有活力，Spring就是很好的例子。而SCA和Spring的差异我也早在前面的文章中说过，SCA和其他的规范一样，并不是一个横空出世的规范，是积累在过去的失败中沉积的产物。最后打了个比方，SCA规范好比一本菜谱，至于采用什么锅子，用哪里产的材料都是由厨师自己掌握，这也是架构师和程序员需要共同努力将这个规范实践的原动力，正确的做事和做正确的事是成败的两个关键。言归正传，继续这次的主题。

在前面的服务框架工作中，对于Web Service的支持成为了这段时间的重点工作，从开始的压力测试，Java客户端的兼容性测试到.net,php客户端的兼容性测试，WS-Security的集成，服务框架对于Web Service的支持在需求中逐渐增强。AEP第一期基本完成准备上线，第二期的需求也已经在酝酿中，ASF的第二期功能需求也逐渐的被提出来了，有一点看上去优先级比较高，因此我就开始动手先做，那就是SSL。一开始的时候对于SSL需求有些误解，以为是要做Web 服务器端的SSL，其实我们需要做的是硬件的SSL，只不过“首架”的意思是需要对SSL模式下的客户端调用作准备（的确，客户端在SSL不论是硬件还是软件模式下都需要作一定的工作）。后续将讲述一下我在做Web 服务器端SSL平台集成的工作和SA专家交流了解的硬件SSL的架构策略。

What is SSL

虽然以前也对SSL有所闻，也常看到IE突然蹦出一个安全提示框，但是对于SSL的具体原理以及结构没有仔细看过。既然要用了，还是那个原则，先把原理搞清楚，然后再去实践。

SSL(Secure Socket Layer)是一种通信交互协议，由Netscape公司在1994年制定，主要目的就是确保在web 服务器和浏览器之间数据传输安全。SSL协议层是在TCP/IP层和应用层之间。当前TLS(Transport Layer Security)正在逐渐替代SSL(最新版本v3)。

SSL协议分成以下几部分：

Record Protocal是SSL的基础层，SSL所有的上层操作都是基于这个层次，这层主要负责消息内容的分段，压缩，加密和数字摘要等操作。

Handshake Protocal故名思义就是握手协议，也是在正式应用数据传输前双方交换加密设置以及认证的流程规范协议。

Change Cipher Spec Protocol是基于record协议层通知远端服务器修改record协议层中安全设置的协议。

Alert Protocol是基于record协议发送警告到远端服务器的协议。

SSL的具体流程图：

SSL的流程也体现了对于对称性密钥和非对称性密钥的使用，由于对称性密钥加密比非对称性密钥加密要快1000倍，那么对称性密钥被用来做对内容的加密，而非对称性密钥用来做传递对称性密钥的加密手段。

服务端所需要具备的是一个拥有服务端的标示，公钥私钥对的证书。在握手的流程中，服务端将带有公钥的证书抽取出来发送给客户端，客户端就首先可以判断证书颁发者是否属于本机受信的CA，如果不是，就会类似于IE跳出提示，如果通过了这部分CA认证，双方就可以通过非对称性加密算法来交换客户端生成的临时对称密码，进行安全加密信息交互。

软件SSL的实践

因为当前所有的单元测试都是通过我提供的ASF模板类，所以启动的Web Service都是服务框架中Jetty发布的Web Service，很轻量级，没有以往测试Web应用的复杂，不需要单独去启动一个Web Container。前期对于WS-Security的集成已经使得单元测试可以支持带WS-Security的Web Service的测试。

抱着试一试的心理，直接用服务框架发布了SSL的Web Service，客户端调用了一下，没有成功，但是错误还不能定位是客户端还是服务端的问题，因此首先去外部配置了Tomcat来建立了一个SSL服务端。

Tomcat SSL服务端的配置：（只需要修改一个文件conf/server.xml）

<Connector port="8443" maxHttpHeaderSize="8192"

maxThreads="150" minSpareThreads="25" maxSpareThreads="75"

enableLookups="false" disableUploadTimeout="true"

acceptCount="100" scheme="https" secure="true"

clientAuth="false" sslProtocol="TLS" keystoreFile="D:/work/asf/webservice/src/conf.test/keys/alisoft.jks"

keystorePass="alisoft" keystoreType="jks" truststoreFile="D:/work/asf/webservice/src/conf.test/keys/alisoft.jks"

truststorePass="alisoft" truststoreType="jks"/>

clientAuth没有必要配置成为true，不需要重复反向再认证。如果这个值设为false。其他几个值就是生成的服务端证书库位置及密码。这里所要注意的就是要求keystore密码和私钥密码一样，因为只有一个配置密码的地方，这在生成公钥密钥对时两者密码写成一致。这样就OK了，直接访问8443端口就能作为https来访问服务了。

采用XFire客户端来做单元测试，代码如下：

public static void SSLSecurityTest()

{

Service serviceModel = new ObjectServiceFactory().create(IAccountService.class);

//https的客户端代码需要增加的

System.setProperty ( "java.protocol.handler.pkgs" , "com.sun.net.ssl.internal.www.protocol" );

System.setProperty ( "javax.net.ssl.keyStore" , "D:/work/asf/webservice/src/conf.test/keys/myisvdemo.jks" );

System.setProperty ( "javax.net.ssl.keyStorePassword" , "myisvdemo" );

System.setProperty ( "javax.net.ssl.trustStore" , "D:/work/asf/webservice/src/conf.test/keys/myisvdemo.jks" );

System.setProperty ( "javax.net.ssl.trustStorePassword" , "myisvdemo" );

System.setProperty ("java.protocol.handler.pkgs","com.sun.net.ssl.internal.www.protocol");

Security.addProvider ( new com.sun.net.ssl.internal.ssl.Provider());

String serviceUrl = "http://localhost:8080/axis2/services/AccountService";

String serviceHttpsUrl = "https://localhost:8443/xfire/services/AccountService";

String serviceHttpsUrl2 = "https://localhost:8443/axis2/services/AccountService";

try

{

IAccountService service = (IAccountService)serviceFactory.create(serviceModel,serviceHttpsUrl2);

//WS-Security所需要的配置

Client client = ((XFireProxy)Proxy.getInvocationHandler(service)).getClient();

client.addOutHandler(new DOMOutHandler());

Properties properties = new Properties();

properties.setProperty(WSHandlerConstants.ENABLE_SIGNATURE_CONFIRMATION, "false");

properties.setProperty(WSHandlerConstants.ACTION, WSHandlerConstants.SIGNATURE);

//properties.setProperty(WSHandlerConstants.ACTION, WSHandlerConstants.TIMESTAMP);

properties.setProperty(WSHandlerConstants.SIG_PROP_FILE, "keys/client.properties");

//properties.setProperty(WSHandlerConstants.USER, "myisvdemo");

properties.setProperty(WSHandlerConstants.USER, "wenchu");

properties.setProperty(WSHandlerConstants.PW_CALLBACK_CLASS, ClientUtPasswordHander.class.getName());

//properties.setProperty(WSHandlerConstants.SIG_KEY_ID, "IssuerSerial");//"DirectReference","IssuerSerial","SKIKeyIdentifier"

properties.setProperty(WSHandlerConstants.SIG_KEY_ID, "SKIKeyIdentifier");

client.addOutHandler(new WSS4JOutHandler(properties));

AccountBean[] result = service.getUserAccountList("te", "ta");

System.out.println(result.length);

}

catch(Exception ex){ex.printStackTrace();}

}

这样保证了客户端的配置已经没有问题了，因此就主要将ASF框架中的SSL集成进去。由于ASF中集成的是Jetty，因此只需要在Jetty动态建立Mapping Server的时候，Server的connector为以SslSocketConnector类型来构造，这样就可以响应https的部分了，同时也可以在其它端口发布成为不需要SSL的服务。这里细节就略去了，改造不是很复杂，只需要对Jetty较为了解即可。不过这里还是要赞一下Jetty，真是轻量级的好东西啊。集成以后再次作单元测试，OK，测试通过。

.Net的客户端测试

最后就需要对.net所SSL的测试，由于.net客户端已经在上次配置了policy作为WS-Security的配置，按照常理来说应该不需要再配置证书之类的东西了，就尝试着做了一下，在建立Web Reference的时候会有提示说证书授权的认证不符合要访问的地址的身份，这个可以忽略。然后接下去测试了一下，就总是提示无法建立TLS/SSL的交互通道，查了一下，只需要加入下面一句话即可：

System.Net.ServicePointManager.ServerCertificateValidationCallback = delegate { return true; };

它的作用就是接受所有的证书，也就是在我们SSL中的流程中，检查证书CA是否受信这部分省略，就好比我们访问一些非受信证书的网站跳出的提示框我们点击确认一样。

到此为止，应用服务器的SSL配置和测试就基本结束了。后面要谈到的就是硬件SSL的结构和设计。

硬件SSL结构设计

首先为什么要使用SSL来加密呢，干脆用WS-Security就好了，而且WS-Security有着很多SSL所无法做到的特性（不基于传输层，保障非点对点的安全传输，部分加密等等）。但是在前面的压力测试中明显可以看到还没有用到加密，仅仅是签名服务器的CPU消耗就成倍的增长，可见对于性能的影响。同时上面提到的应用服务器SSL，其实也是类似于WS-Security，消耗比较大。因此就提出了硬件SSL的设计。

这里主要提了两种，第二种也是现在SA比较推荐的。

一．为应用服务器增加独立的SSL加速卡，例如roadcom CryptoNetXM卡，SSL加速卡的作用在于能够将应用服务器处理SSL的工作独立完成，让应用服务器专心处理应用请求，使得应用服务器性能不受影响。

图 SSL加速卡部署图

由于许多服务器使用的是不同的加密数据，因此管理这样一个Web服务器组会花费比较大并且复杂。同时传统的负载均衡阵列中每一个处理加密服务器要求有一个SSL加速卡和数字证书，而证书是被CA签署过的一个电子认证标识，在加密通信方面提供了一致性的验证，这样对于CA的电子认证标识管理也是很复杂的一件事，因此产生了第二种设计模式。

二．将SSL基础结构与BIG-IP结合

BIG-IP是一个运行有BIG-IP负载均衡软件的服务器，它通过SSL加速卡实现了SSL的off-loading，同时还可以实现应用层和IP层的负载均衡。通过SSL终结，前端的BIG-IP负责SSL的集中处理以及同时将处理后的请求负载均衡到各个应用服务器上，这样既降低了SSL证书管理成本，也减少了Web服务器组的管理复杂性。

2007/12/10 8:49

普元培训中心EOS公开培训

SOA博客精英重金寻求普元诚招技术精英 goCom币赠送：EOS公开培训调研
普元业务流程平台-Primeton BPS 最新频道火热上线

IDC:SOA中国路线图白皮书免费下载普元诚招EOS技术咨询顾问

[无发表权] 请登录或者注册

发表回复
账号	用户名密码登录
内容:	范例 Example [更多...]