通向八段的道路第14天Axis2 Web Service安全二文档格式.docx
- 文档编号:13694571
- 上传时间:2022-10-12
- 格式:DOCX
- 页数:27
- 大小:595.52KB
通向八段的道路第14天Axis2 Web Service安全二文档格式.docx
《通向八段的道路第14天Axis2 Web Service安全二文档格式.docx》由会员分享,可在线阅读,更多相关《通向八段的道路第14天Axis2 Web Service安全二文档格式.docx(27页珍藏版)》请在冰豆网上搜索。
2.3使用jks文件来实现Server-Client间的“公钥加密,私钥解密”6
三、使用Axis2Rampart实现WebService安全规范7
3.1Axis2与Rampart7
3.2动手来做例子8
3.2.1搭建环境9
3.2.2Service端10
1)org.sky.axis2.security.MyRampartService10
2)service.xml文件10
3)service.properties文件13
3.2.3编写client端前的准备14
3.2.4编写client端17
1)org.sky.axis2.security.MyRampartServiceClient18
2)工程的src\repository\axis2.xml文件20
3)client.properties文件21
四、换一种WebServiceSecurity规范来试试同样的例子22
4.1换service端的配置22
4.2换client端的配置23
一、加密保护我们的webservice传输
在上一天的教程中,我们讲了一个简单的基于”security-constraint”的以指定用户名和密码来保护一个WebService以及如何用https对这个webservice的通讯过程进行保护。
虽然它用https来进行保护了,但是我们抛开https,这个webservice之间传输的用户名,密码,数据都是明文的。
在我之间教程中曾经提到过,有一种黑客工具叫作sniffer,或者使用MIM-ATTACK(中间件拦截)的方式,也是可以把客户端的流拦截住并且发往黑客主机的,这样我们的用户名和密码就可以被黑客所获取了。
因此,今天我们要讲述的就是如何在webservice传输时,使得这个用户名和密码以及相关数据也能被加密。
二、基本概念
我们先来看基本概念,这个基本概念将涉及到PKI的相关领域,请仔细看完这一章,要不然后面你将云里雾里然后我劝你从头来过,我将参照麻省理工大学的教程-RSA公司出版的“计算机加密与解密原理”,用最实际的例子和最简化的语言把PKI中最重要的几个概念给大家说清楚。
这次应该是我们第三次要求生成证书请求,证书,签名了,挺折腾的!
!
不折腾你们不行,我要把大家折腾的蛋疼,这次折腾过后就彻底明白了。
被折腾着,痛苦着并最后快活着,好了我废话又多了,下面开始。
2.1加密解密的基本概念
我们的加密解密分两种:
1)对称加密(SymmetricCipher)
2)非对称加密(AsymmetricCipher)
2.1.1对称加密
即采用一个密码(密钥)来对一串String进行解密,同样这个密码(密钥)也能对被加密的密文进行解密,至始至终只有一个密码(密钥),因此它叫做对称加密。
2.1.2非对称加密
这个是最重要的概念之一
我们知道,对称加密只有一把密钥(你可以把这个密钥看成一个密码)。
而非对称加密呢?
它有2把密钥,
●一把我们称为私钥即privatekey,一把私钥可以对应着无数把公钥,公钥是可以“散播”的。
●一把我们称为公钥即publickey,一堆公钥只能对应着仅有的一把私钥,私钥是绝对不可以“散播”的。
这两把密钥在产生时是被一起产生的,相当于同年同月生一样,即生成私钥时也伴随着生成了公钥。
下面公式来了:
公钥加密,私钥解密
大家试想一下哈,我有两把钥匙,一把是用来专门锁门的(加密),一把是专门用来开门的(解密)。
那么我用来锁门的那把key掉了,被其它人捡到了,要不要紧?
大不了别人可以锁我家的门。
但是,如果我用来开门的这么key掉了?
怎么办?
被人捡到了人家就可以开我家的门进我家了。
因此,公钥永远被用来加密,可以有多把被多人持有,而私钥永远用来解密且只能主人自己拥有。
公钥加密,私钥解密!
老老记住,这是永远的公式,也是真理!
2.1.3数字签名
看了上面的“真理”即“公钥加密,私钥解密”后有人说了,我偏不信邪我就是要把它们倒过来,好好好!
我们一起来看倒过来是什么样的,即成了“私钥加密,公钥解密”了。
但话不能这样说,真理是不容否定的,但倒过来不是也行?
行,行是行,不过这句话就不能这样说了。
我们知道,公钥是可以多把的,私钥只有一把,因此:
1)如果我们先把我们的明文用MD5或者SHA1这样的杂凑算法做一个杂凑,得到一堆杂凑值我们称它为报文。
2)然后呢我们拿着我们的私钥来对着这个得到的杂凑码不管它是MD5还是SHA1,做一个加密运算,就得到了一个“摘要”即Digest。
3)然后我们把这个摘要和我们的明文一起发送给接收方。
4)接收方首先用与发送方一样的杂凑函数与接收到的原始明文中计算出这个杂凑计算,得到杂凑值即报文。
5)接着再用发送方的公用密钥来对这个报文附加的数字签名进行解密,这样,在接收方手上就会有两样东西了。
●接收方用发送方的公钥与所谓的原始明文运算得到的杂凑值或者称为报文也可称为摘要即digest。
●接收方收到的由发送方发过来的摘要
6)将这两要东西,就是两个摘要,它通宵是如下的格式:
0af5b03f386b979c08629b8bdfd7a0c6fe001208
把这两个摘要一比较,完全一致我们就可以说:
从接收方发送来的摘要是出自某某某之手!
为什么?
举例来说:
因为我们的公钥和密钥在产生时是一对的,Andy保留了私钥,他把公钥给了Forest。
If
Forest用这把公钥和明文得到的摘要如果==Andy用私钥和明文做了杂凑后发来的摘要
Then
这条消息一定是Andy发过来的。
除非Andy把他的私钥交给了其它人并授权其它人代理他来做这个“私钥签证”
所以,我们得到另一条公式:
私钥签名,公钥认证
这也是一条真理,不能违背,这条真理也被称为“数字签名”,这边的“认证”也可以称为“被信任”。
2.1.4口令保护
我们的privatekey,publickey如果一旦真的出现了privatekey被丢失的情况下怎么办?
不要紧,我们在privatekey上加一道锁:
这下成了最右边那个带锁的信封了,是不是,这个带锁的信封就是我们的钥匙袋。
你要拿到我的私钥就必须要先打开这个钥匙带,打开这个钥匙带你就必须再需要一把钥匙。
一般这把钥匙就是一个密码,我们称之为“口令”。
来看如下的一个jks的生成来理解吧:
keytool-genkey-aliasshnlap93client-keyalgRSA-keysize1024-dname"
CN=shnlap93,OU=insurance,O=CTS,L=SH,S=SH,C=CN"
-keypassbbbbbb-keystoreshnlap93client.jks-storepassbbbbbb
JKS文件就是“公钥私钥证书”在一起的一种证书格式。
一般证书如IE中的证书都只带着公钥(publickey),而jsk是同时带有公钥和私钥的证书。
因此,如果你要得到这对密钥,你就必须要“解信封”,解开信封时你就要输入密码(口令),这边的口令就是:
keypass即bbbbbb六个小写的b。
2.2回过头来看https与证书、公钥、私钥的关系
CA证书签出一张服务器证书,在签出签书时CA使用自己的私钥,签完后怎么叫作这张被签的证书生效呢?
因为这张被签的证书中含有着CA证书中的“公钥”。
然后我们产生一个客户端的证书,该客户端的证书生成后我们把CA的公钥也“烧”到客户端的证书里。
因此,我们有了下面这样的一个关系(见第十三天教程中的3.3小节-需要为我们的Axis2的调用客户端也建立起https中的互信)。
这边的客户端jks文件(带着RootCA),就是带着RootCA的公钥,因为公钥是可以多把的吗,因此RootCA可以把自己的公钥散播给其它人。
于是我们来套“私钥签名,公钥认证”这个公式就得到了:
1)因为客户端的jks文件的公钥可以“认证”RootCA,即RootCA被客户端信任。
2)因为服务端的ks文件也带着RootCA的公钥,可以“认证”RootCA,即RootCA可以被服务端信任。
3)因此,客户端可以信任服务端
2.3使用jks文件来实现Server-Client间的“公钥加密,私钥解密”
上面说了,客户端拥有RootCA的publickey,服务端也拥有RootCA的publickey,所以客户端与服务端可以彼此间也建立起这条信任链。
但是,信任不代表它们可以实现“公钥加密,私钥解密”。
来看一个例子,这是今天的核心:
需求一、如果我们的客户端对一个webservice进行加密,然后传到服务端进行解密。
对于需求一来说:
我们需要在客户端用服务端的公钥加密欲传给服务端的消息,然后在服务端得到客户端传过来的加密消息后我们拿着服务端的私钥进行解密。
需求二、服务端将返回的webservice的内容先用客户端的公钥加密后传给客户端,客户端拿自己的私钥进行解密。
对于需求二来说:
我们在服务端返回给客户端消息之间先用客户端的公钥对消息进行加密,等消息传到客户端的时候,客户端再拿着客户端自己的私钥进行解密。
是不是就可以满足上述两个需求了?
于是,根据上面的描述我们来做一件事,即:
●把客户端的公钥烧到服务端的jks文件里
●把服务端的公钥烧到客户端的jks文件里
即可达到上面两个需求中的文字描述了,是不是?
三、使用Axis2Rampart实现WebService安全规范
3.1Axis2与Rampart
WebService安全规范其实就是在讲一套客户端与服务端的webservice之间如何进行认证、加密的手段。
在Axis2中,是以handler的模式来实现webservice安全规范的。
在旧的Axis版本中,使用的是自己写handler然后来实现客户端与服务端之间的webservice加密、认证。
而到了Axis21.4版即后续版中,这个handler已经不需要我们手工写了,Axis2为我们提供了一个组件,这个组件叫rampart。
rampart是axis2实现ws-security的一个必须模块。
它基于wss4j来完成安全相关的任务,以下是rampart的工作原理:
因为Rampart是基于Handler模式的,是对handler的一种封装,它很像一个拦截器,因此有了Rampart我们可以在不需要改动客户端、服务端的代码的情况下只通过修改service端与client端的xml即可实现不同的webservice安全规范,而且有了rampart我们只需要提供client端与server端的jks以及相关的“口令”和“用户名(即jks的alias-别名)Rampart就可以自动为我们进行:
加密;
解密;
认证;
而不需要我们再去书写加密、解密、认证的底层API了,够方便吧。
3.2动手来做例子
需求:
实现客户端访问一个webservice,彼此间只通
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 通向八段的道路第14天Axis2 Web Service安全二 通向 道路 14 Axis2 Service 安全
![提示](https://static.bdocx.com/images/bang_tan.gif)