Submitted by emil_prager on July 28, 2008 - 14:18.
Hello, Prabath!
First of all, thank you for your tutorial article!
I tried to follow all the steps exactly as described in your tutorial (the only difference being the value for the %AXIS2_HOME%).
I've encountered the following minor problems, which I'll enumerate here to ease the following up of the tutorial for somebody else. (I also mention that I have never been working before with the BouncyCastle JCE provider.)
Places where more details should be useful:
1) from the provided link to the BouncyCastle site it's not very clear what exactly should be downloaded from there. There are 2 JCE provider jars per jdk version, but, as it's written there, the one with -ext- in the name should be ignored here (as it contains the proprietary algorithm IDEA). For Java 5, from what I've figured out that, it should be that with the name of the form bcprov-jdk15-%version%.jar (currently, the last version is 1.40, so the file should be bcprov-jdk15-140.jar). This jar should be copied in both:
i) the %AXIS2_HOME%\lib ($AXIS2_HOME/lib) directory, and:
ii) somewhere in the runtime classpath, for example (maybe not the best example) in %JAVA_HOME%\jre\lib\ext\
Remark: it's not generally recommendable to put our jars in system wide locations such $JAVA_HOME/jre/lib/ext/ or $AXIS2_HOME/lib/, but given the nature of this libray (a JCE provider), it deserves to be there (of course, if we have writing rights to the $JAVA_HOME directory).
2) The next thing to mention is that we have to add an entry in the java.security file (%JAVA_HOME%\jre\lib\security),
in the # List of providers and their preference orders (see above):, more precisely:
where N is the preference order of the last JCE provider mentioned there (by default, there are 6 in Java 5), so (in that case) we'll have to add the line:
Not doing so will result in error messages like this:
org.apache.ws.security.WSSecurityException: WSHandler: Encryption: error during message processingorg.apache.
ws.security.WSSecurityException: An unsupported signature or encryption algorithm was used (unsupported key transport en
cryption algorithm: No such algorithm: http://www.w3.org/2001/04/xmlenc#rsa-1_5)
or, more detailed:
Exception in thread "main" org.apache.axis2.AxisFault: WSHandler: Encryption: error during message processing org.apache.ws.security.WSSecurityException: An unsupported signature or encryption algorithm was used (unsupported key transport encryption algorithm: No such algorithm: http://www.w3.org/2001/04/xmlenc#rsa-1_5)
at org.apache.rampart.handler.WSDoAllSender.processMessage(WSDoAllSender.java:67)
at org.apache.rampart.handler.WSDoAllHandler.invoke(WSDoAllHandler.java:72)
at org.apache.axis2.engine.Phase.invoke(Phase.java:317)
at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:264)
at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:429)
at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:401)
at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:228)
at org.apache.axis2.client.OperationClient.execute(OperationClient.java:163)
at org.apache.axis2.client.ServiceClient.sendReceive(ServiceClient.java:548)
at org.apache.axis2.client.ServiceClient.sendReceive(ServiceClient.java:528)
at org.apache.rampart.samples.sample05.Client.main(Client.java:45)
Caused by: org.apache.ws.security.WSSecurityException: WSHandler: Encryption: error during message processing org.apache.ws.security.WSSecurityException: An unsupported signature or encryption algorithm was used (unsupported key transport encryption algorithm: No such algorithm: http://www.w3.org/2001/04/xmlenc#rsa-1_5)
at org.apache.ws.security.action.EncryptionAction.execute(EncryptionAction.java:65)
at org.apache.ws.security.handler.WSHandler.doSenderAction(WSHandler.java:197)
at org.apache.rampart.handler.WSDoAllSender.processBasic(WSDoAllSender.java:201)
at org.apache.rampart.handler.WSDoAllSender.processMessage(WSDoAllSender.java:64)
... 10 more
3) we should overwrite the client java keystore file [rampart-sample]\client\client.jks, which is already present in the rampart-sample.zip with the one built by us during the keystores setup (the tutorial path would be C:\keystores\client\client.jks).
Not doing so will result in error messages like this:
Exception in thread "main" org.apache.axis2.AxisFault: WSDoAllReceiver: security processing failed
at org.apache.axis2.util.Utils.getInboundFaultFromMessageContext(Utils.java:512)
at org.apache.axis2.description.OutInAxisOperationClient.handleResponse(OutInAxisOperation.java:370)
at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:416)
at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:228)
at org.apache.axis2.client.OperationClient.execute(OperationClient.java:163)
at org.apache.axis2.client.ServiceClient.sendReceive(ServiceClient.java:548)
at org.apache.axis2.client.ServiceClient.sendReceive(ServiceClient.java:528)
at org.apache.rampart.samples.sample05.Client.main(Client.java:45)
After those supplemental steps, everything should go smooth, and we should see the result as:
In conclusion, thanks again, Prabath, for your tutorial, it might help many of us which have to do with WSS etc.
PS: Another suggestion might be to continue this tutorial with a .NET (or native win32?) client that would consume such a securized service, it's a situation not very rarely encountered in practice -- Java EE on the server side, and .NET clients on the client one (and who knows?, maybe I can contribute myself on some parts of such a post).
Submitted by feliduca on October 23, 2008 - 09:50.
Open source computing has gained a tremendous degree of momentum in the last few years. Nowhere is this more evident than in the area of web services and Service-Oriented Architecture (SOA). The Apache Foundation alone has more than 20 SOA/WS projects. One of the common obstacles for large enterprises to adopt open source solutions for key systems is the lack of administrative infrastructure and standardized glue for pulling together complementary projects. Essentially, the lack of a true open source "platform" (along with professional consulting and training services) limits more extensive adoption of open source technology. One group that has successfully addressed this open source platform gap is the JBoss Group. Until recently, however, no such group existed to establish a platform around Apache SOA projects. Enter WSO2 (WS "Oh" 2).
This article introduces the WSO2 platform by looking at two key features -- security and reliable messaging. We will begin with an examination of the relevant WS-* standards (WS-ReliableMessaging, WS-Security, WS-SecureConversation, and WS-Trust) followed by a peek into the related Apache projects. Then we will proceed to explore the value-add that WSO2 provides above and beyond the basic Apache projects.
Security and Reliability Service Standards Overview
The field of web service standards is vast and constantly evolving. The security space, in particular, has an extensive set of standards (many of which are defined as extensions of WS-Security). For the purposes of this article, the following service standards come into play:
WS-Security: Describes a protocol for securing web service message exchanges, addressing identity, integrity, and confidentiality. WS-Security serves as the core specification for service security and leverages two other specifications, XML Encryption and XML Digital Signatures.
WS-Trust: Building upon the extensibility of WS-Security, this specification defines a means of brokering security credentials among partners within different trust domains.
WS-SecureConversation: This specification defines extensions to WS-Security and builds on WS-Trust to govern secure communication across multiple message exchanges. It defines a mechanism for sharing security contexts and deriving session keys to tie messages together as a part of a "conversation."
WS-ReliableMessaging: Describes a protocol for exchanging messages between nodes in the face of network, system, and component-level failures. Message delivery is guaranteed to occur and if a sequence of messages has been sent, they will arrive in the order they were sent.
Securing a single service invocation is fine for simple business scenarios. Modern enterprise messaging architectures require support for more complex scenarios involving multi-message conversations, brokering of security context across trusted domains, and assurance that messages are delivered to their intended destination. In short, modern enterprise architectures must support secure, reliable messaging.
Related Apache Projects
In support of the service standards identified earlier, we will look to several Apache projects that implement these standards. Specifically, we will leverage Apache Axis and several add-on modules (Rampart, Rahas, and Sandesha).
Axis2 (Service Engine): Apache Axis2 provides the core web services engine and supports SOAP 1.1, SOAP 1.2, and REST-style services. In order to take advantage of increased efficiency, modularity, and the latest standards, we will want to use the new and improved Axis2 engine. The Axis engine is designed as a series of loosely coupled message handlers, which perform pre- and post-processing on messages. This design will be leveraged by the modules described below to perform additional pre- and post-processing on messages in order to support higher-level security and reliability messaging standards.
Rampart (WS-Security & WS-SecureConversation): Apache Rampart is an Axis2 module that supports various service security standards. Rampart inserts message handlers into the pre-dispatch message processing phase within Axis to support the validation or production of security semantics.
Rahas (WS-Trust): Apache Rahas provides WS-Trust support and does not currently exist as an independent Apache project. At the time of this writing, it resides as a library that is bundled along with Rampart.
Sandesha2 (WS-ReliableMessaging): Apache Sandesha implements the WS-ReliableMessaging specification and, like Rampart, is packaged as an Apache Axis module.
While there are many more Apache projects that we could pull into the mix, this short list provides us with a sufficiently robust web service engine complete with a security and reliability framework. Although this project set provides sufficient functionality, it does not represent a cohesive platform. There is a significant amount of work that application developers and system administrators will need to do in order to deploy, connect, configure, and maintain this framework. Next, we will explore how to pull this together into a comprehensive enterprise service platform.
THE DEVELOPER PORTAL FOR SOA
Some minor clarifications
Hello, Prabath!
First of all, thank you for your tutorial article!
I tried to follow all the steps exactly as described in your tutorial (the only difference being the value for the %AXIS2_HOME%).
I've encountered the following minor problems, which I'll enumerate here to ease the following up of the tutorial for somebody else. (I also mention that I have never been working before with the BouncyCastle JCE provider.)
Places where more details should be useful:
1) from the provided link to the BouncyCastle site it's not very clear what exactly should be downloaded from there. There are 2 JCE provider jars per jdk version, but, as it's written there, the one with -ext- in the name should be ignored here (as it contains the proprietary algorithm IDEA). For Java 5, from what I've figured out that, it should be that with the name of the form bcprov-jdk15-%version%.jar (currently, the last version is 1.40, so the file should be bcprov-jdk15-140.jar). This jar should be copied in both:
i) the %AXIS2_HOME%\lib ($AXIS2_HOME/lib) directory, and:
ii) somewhere in the runtime classpath, for example (maybe not the best example) in %JAVA_HOME%\jre\lib\ext\
Remark: it's not generally recommendable to put our jars in system wide locations such $JAVA_HOME/jre/lib/ext/ or $AXIS2_HOME/lib/, but given the nature of this libray (a JCE provider), it deserves to be there (of course, if we have writing rights to the $JAVA_HOME directory).
2) The next thing to mention is that we have to add an entry in the java.security file (%JAVA_HOME%\jre\lib\security),
in the # List of providers and their preference orders (see above):, more precisely:
security.provider.N+1=org.bouncycastle.jce.provider.BouncyCastleProvider,
where N is the preference order of the last JCE provider mentioned there (by default, there are 6 in Java 5), so (in that case) we'll have to add the line:
security.provider.7=org.bouncycastle.jce.provider.BouncyCastleProvider
Not doing so will result in error messages like this:
org.apache.ws.security.WSSecurityException: WSHandler: Encryption: error during message processingorg.apache.
ws.security.WSSecurityException: An unsupported signature or encryption algorithm was used (unsupported key transport en
cryption algorithm: No such algorithm: http://www.w3.org/2001/04/xmlenc#rsa-1_5)
or, more detailed:
Exception in thread "main" org.apache.axis2.AxisFault: WSHandler: Encryption: error during message processing org.apache.ws.security.WSSecurityException: An unsupported signature or encryption algorithm was used (unsupported key transport encryption algorithm: No such algorithm: http://www.w3.org/2001/04/xmlenc#rsa-1_5)
at org.apache.rampart.handler.WSDoAllSender.processMessage(WSDoAllSender.java:67)
at org.apache.rampart.handler.WSDoAllHandler.invoke(WSDoAllHandler.java:72)
at org.apache.axis2.engine.Phase.invoke(Phase.java:317)
at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:264)
at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:429)
at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:401)
at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:228)
at org.apache.axis2.client.OperationClient.execute(OperationClient.java:163)
at org.apache.axis2.client.ServiceClient.sendReceive(ServiceClient.java:548)
at org.apache.axis2.client.ServiceClient.sendReceive(ServiceClient.java:528)
at org.apache.rampart.samples.sample05.Client.main(Client.java:45)
Caused by: org.apache.ws.security.WSSecurityException: WSHandler: Encryption: error during message processing org.apache.ws.security.WSSecurityException: An unsupported signature or encryption algorithm was used (unsupported key transport encryption algorithm: No such algorithm: http://www.w3.org/2001/04/xmlenc#rsa-1_5)
at org.apache.ws.security.action.EncryptionAction.execute(EncryptionAction.java:65)
at org.apache.ws.security.handler.WSHandler.doSenderAction(WSHandler.java:197)
at org.apache.rampart.handler.WSDoAllSender.processBasic(WSDoAllSender.java:201)
at org.apache.rampart.handler.WSDoAllSender.processMessage(WSDoAllSender.java:64)
... 10 more
3) we should overwrite the client java keystore file [rampart-sample]\client\client.jks, which is already present in the rampart-sample.zip with the one built by us during the keystores setup (the tutorial path would be C:\keystores\client\client.jks).
Not doing so will result in error messages like this:
Exception in thread "main" org.apache.axis2.AxisFault: WSDoAllReceiver: security processing failed
at org.apache.axis2.util.Utils.getInboundFaultFromMessageContext(Utils.java:512)
at org.apache.axis2.description.OutInAxisOperationClient.handleResponse(OutInAxisOperation.java:370)
at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:416)
at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:228)
at org.apache.axis2.client.OperationClient.execute(OperationClient.java:163)
at org.apache.axis2.client.ServiceClient.sendReceive(ServiceClient.java:548)
at org.apache.axis2.client.ServiceClient.sendReceive(ServiceClient.java:528)
at org.apache.rampart.samples.sample05.Client.main(Client.java:45)
After those supplemental steps, everything should go smooth, and we should see the result as:
<ns:echoResponse xmlns:ns="http://sample05.samples.rampart.apache.org"><ns:return>Hello world</ns:return></ns:echoResponse>
In conclusion, thanks again, Prabath, for your tutorial, it might help many of us which have to do with WSS etc.
PS: Another suggestion might be to continue this tutorial with a .NET (or native win32?) client that would consume such a securized service, it's a situation not very rarely encountered in practice -- Java EE on the server side, and .NET clients on the client one (and who knows?, maybe I can contribute myself on some parts of such a post).
Open source computing has
Open source computing has gained a tremendous degree of momentum in the last few years. Nowhere is this more evident than in the area of web services and Service-Oriented Architecture (SOA). The Apache Foundation alone has more than 20 SOA/WS projects. One of the common obstacles for large enterprises to adopt open source solutions for key systems is the lack of administrative infrastructure and standardized glue for pulling together complementary projects. Essentially, the lack of a true open source "platform" (along with professional consulting and training services) limits more extensive adoption of open source technology. One group that has successfully addressed this open source platform gap is the JBoss Group. Until recently, however, no such group existed to establish a platform around Apache SOA projects. Enter WSO2 (WS "Oh" 2).
This article introduces the WSO2 platform by looking at two key features -- security and reliable messaging. We will begin with an examination of the relevant WS-* standards (WS-ReliableMessaging, WS-Security, WS-SecureConversation, and WS-Trust) followed by a peek into the related Apache projects. Then we will proceed to explore the value-add that WSO2 provides above and beyond the basic Apache projects.
Security and Reliability Service Standards Overview
The field of web service standards is vast and constantly evolving. The security space, in particular, has an extensive set of standards (many of which are defined as extensions of WS-Security). For the purposes of this article, the following service standards come into play:
WS-Security: Describes a protocol for securing web service message exchanges, addressing identity, integrity, and confidentiality. WS-Security serves as the core specification for service security and leverages two other specifications, XML Encryption and XML Digital Signatures.
WS-Trust: Building upon the extensibility of WS-Security, this specification defines a means of brokering security credentials among partners within different trust domains.
WS-SecureConversation: This specification defines extensions to WS-Security and builds on WS-Trust to govern secure communication across multiple message exchanges. It defines a mechanism for sharing security contexts and deriving session keys to tie messages together as a part of a "conversation."
WS-ReliableMessaging: Describes a protocol for exchanging messages between nodes in the face of network, system, and component-level failures. Message delivery is guaranteed to occur and if a sequence of messages has been sent, they will arrive in the order they were sent.
Securing a single service invocation is fine for simple business scenarios. Modern enterprise messaging architectures require support for more complex scenarios involving multi-message conversations, brokering of security context across trusted domains, and assurance that messages are delivered to their intended destination. In short, modern enterprise architectures must support secure, reliable messaging.
Related Apache Projects
In support of the service standards identified earlier, we will look to several Apache projects that implement these standards. Specifically, we will leverage Apache Axis and several add-on modules (Rampart, Rahas, and Sandesha).
Axis2 (Service Engine): Apache Axis2 provides the core web services engine and supports SOAP 1.1, SOAP 1.2, and REST-style services. In order to take advantage of increased efficiency, modularity, and the latest standards, we will want to use the new and improved Axis2 engine. The Axis engine is designed as a series of loosely coupled message handlers, which perform pre- and post-processing on messages. This design will be leveraged by the modules described below to perform additional pre- and post-processing on messages in order to support higher-level security and reliability messaging standards.
Rampart (WS-Security & WS-SecureConversation): Apache Rampart is an Axis2 module that supports various service security standards. Rampart inserts message handlers into the pre-dispatch message processing phase within Axis to support the validation or production of security semantics.
Rahas (WS-Trust): Apache Rahas provides WS-Trust support and does not currently exist as an independent Apache project. At the time of this writing, it resides as a library that is bundled along with Rampart.
Sandesha2 (WS-ReliableMessaging): Apache Sandesha implements the WS-ReliableMessaging specification and, like Rampart, is packaged as an Apache Axis module.
While there are many more Apache projects that we could pull into the mix, this short list provides us with a sufficiently robust web service engine complete with a security and reliability framework. Although this project set provides sufficient functionality, it does not represent a cohesive platform. There is a significant amount of work that application developers and system administrators will need to do in order to deploy, connect, configure, and maintain this framework. Next, we will explore how to pull this together into a comprehensive enterprise service platform.
______________________
Submited by : Libros Gratis