There is this FAQ prepared by Spencer Davis and some other Apache Axis2/C developers. If you have any entries that you think worth including, please feel free to drop them here.
http://wiki.apache.org/general/axis2c/FAQ
Soon it will be filtered, sorted and integrated into the Apache Axis2/C documentation.
If you do not have permissions to edit, simply drop an email to axis-c-dev@ws.apache.org list with the subject Axis2/C FAQs.
Thursday, January 31, 2008
Create your own Certificate Authority using OpenSSL
In my earlier blog I showed how to generate a self signed certificate.
A self signed certificate is of no use as it is not signed by a third party. There are such well known third parties like verisign and thawte. But getting a certificate signed is a complex and costly process. If you need to form a small trust community (e.g. For your company or with your clients) you can create your own Certificate Authority. The process is not that complex as it sounds. Thanks to a pearl script available in OpenSSL distribution of cource. If you have used default installation settings, this script (CA.pl) can be located in /usr/lib/ssl/misc/CA.pl. First of all create a directory for you CA. Then copy CA.pl and /usr/lib/ssl/openssl.cnf to the directory you just created. Run the CA.pl script.
If you press enter key, the script will create a new certificate/key pair for you. If you already have a certificate and you need to use it, just type the filename. Now you have a certificate authority setup in a sub directory called "demoCA". Simple, right? Let's try to sign a certificate using the CA we have just set up. Copy your certificate request to the current directory and rename it to newreq.pem (In the next section we will discuss how to generate a certificate request). Then issue the following command.
If everything is successful and the request is a valid one, a new certificate called newcert.pem will be created in the same directory.
A self signed certificate is of no use as it is not signed by a third party. There are such well known third parties like verisign and thawte. But getting a certificate signed is a complex and costly process. If you need to form a small trust community (e.g. For your company or with your clients) you can create your own Certificate Authority. The process is not that complex as it sounds. Thanks to a pearl script available in OpenSSL distribution of cource. If you have used default installation settings, this script (CA.pl) can be located in /usr/lib/ssl/misc/CA.pl. First of all create a directory for you CA. Then copy CA.pl and /usr/lib/ssl/openssl.cnf to the directory you just created. Run the CA.pl script.
%./CA.pl -newca
If you press enter key, the script will create a new certificate/key pair for you. If you already have a certificate and you need to use it, just type the filename. Now you have a certificate authority setup in a sub directory called "demoCA". Simple, right? Let's try to sign a certificate using the CA we have just set up. Copy your certificate request to the current directory and rename it to newreq.pem (In the next section we will discuss how to generate a certificate request). Then issue the following command.
%./CA.pl -sign
If everything is successful and the request is a valid one, a new certificate called newcert.pem will be created in the same directory.
Tuesday, January 29, 2008
Self signed certificates using OpenSSL
Use the following command to generate a self-signed x509 certificate (mycert.pem), which is valid for 365 days and an RSA key (mykey.pem) of length 1024.
Then you have to answer few questions. The information you provide by answering these questions will be stored in the certificate.
That's it !!!
openssl req -x509 -nodes -days 365 -newkey rsa:1024 \
-keyout mykey.pem -out mycert.pem
Then you have to answer few questions. The information you provide by answering these questions will be stored in the certificate.
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:
Email Address []:
That's it !!!
Thursday, January 24, 2008
A request to a certificate authority using OpenSSL
Signing your certificate by a recognized certificate authority is consists of two steps. First you have to generate a certificate request locally. Then you need to fill a form providing some information and send to the CA. Here we will describe how to generate such a request using OpenSSL.
First you need to generate a private key. If you already have a private key skip this step.
Then use that private key to generate your request to the CA.
This will create a file called request.pem from the private key (x.key). The requset file has the following format.
Then you have to provide your information to the certificate authority. Usually this can be done by sending a fax or by filling an on-line application. Make sure that you are sending accurate information and specially check your request and information on it. Use following commands for the verification.
First you need to generate a private key. If you already have a private key skip this step.
%openssl genrsa -out x.key 1024
Then use that private key to generate your request to the CA.
%openssl req -new -key x.key -out request.pem
This will create a file called request.pem from the private key (x.key). The requset file has the following format.
-----BEGIN CERTIFICATE REQUEST-----
(Base64 encoded certificate request data)
-----END CERTIFICATE REQUEST-----
Then you have to provide your information to the certificate authority. Usually this can be done by sending a fax or by filling an on-line application. Make sure that you are sending accurate information and specially check your request and information on it. Use following commands for the verification.
%openssl req -noout -text -in request.pem
%openssl req -noout -verify -key x.key -in request.pem
Wednesday, January 23, 2008
Facing security threats with WSF/PHP
Following table shows how to use/combine WSO2 WSF/PHP security features to face the common web services security threats...
Note that it is necessary to use username tokens with transport level security
Note that it is necessary to use username tokens with transport level security
Thursday, January 17, 2008
Apache Rampart/C 1.1.0 is released
Apache Ramaprt/C team has unleashed it's version 1.1.0 y'day.
Check the feature list here...
The project is to fulfill the message level security requirements of the Apache Axis2/C engine. Without worrying about having custom mechanisms to provide message confidentiality, integrity and authentication requirements, it is very easy to use the Rampart/C module with the Axis2/C engine.
The released version is compatible with the Apache Axis2/C 1.2.0.
You may download the latest version here...
Check the feature list here...
The project is to fulfill the message level security requirements of the Apache Axis2/C engine. Without worrying about having custom mechanisms to provide message confidentiality, integrity and authentication requirements, it is very easy to use the Rampart/C module with the Axis2/C engine.
The released version is compatible with the Apache Axis2/C 1.2.0.
You may download the latest version here...
Tuesday, January 15, 2008
Writing a secure client using WSO2 WSF/C
Once you install WSO2 WSF/C , it has a sample client in WSFC_HOME/rampartc/samples/client/sec_echo, that shows how to enable security for the SOAP messages. Go to the directory and open the echo.c source.
In order to write a secure client following steps should be followed.
1.Create a service client
2.Set options, such as endpoint address and SOAP action
3.Create policy object and set it to the service client
4.Engage the security module
5.Write your code to build the payload. i.e. the body of your SOAP message that carries your business logic to the service
6.Send the message
Note that from above list, only 3 and 4 are the additional steps that you have to take, to secure a client request. Also note that in the step 3 we are giving a policy file name as a string argument to the function neethi_util_create_policy_from_file(). Here the policy_file_name is the file name for your policy configurations in the client side. You may find such client's policy files for each and every security requirement in the scenarios available under WSFC_HOME/rampartc/samples/secpolicy.
In order to write a secure client following steps should be followed.
1.Create a service client
svc_client = axis2_svc_client_create(env, client_home);
2.Set options, such as endpoint address and SOAP action
options = axis2_options_create(env);
axis2_options_set_to(options, env, endpoint_ref);
axis2_options_set_action(options, env,"http://example.com/ws/2004/09/policy/Test/EchoRequest");
axis2_svc_client_set_options(svc_client, env, options);
3.Create policy object and set it to the service client
policy = neethi_util_create_policy_from_file(env, policy_file_name);
axis2_svc_client_set_policy(svc_client, env, policy)
4.Engage the security module
axis2_svc_client_engage_module(svc_client, env, "rampart");5.Write your code to build the payload. i.e. the body of your SOAP message that carries your business logic to the service
payload = build_om_payload_for_echo_svc(env);
6.Send the message
ret_node = axis2_svc_client_send_receive(svc_client, env, payload);
Note that from above list, only 3 and 4 are the additional steps that you have to take, to secure a client request. Also note that in the step 3 we are giving a policy file name as a string argument to the function neethi_util_create_policy_from_file(). Here the policy_file_name is the file name for your policy configurations in the client side. You may find such client's policy files for each and every security requirement in the scenarios available under WSFC_HOME/rampartc/samples/secpolicy.
Friday, January 11, 2008
A killer app for semantic web
Are we still waiting for a killer app in symentic web...?
A nice article written on Semantic web, discussing few potential applications.
A nice article written on Semantic web, discussing few potential applications.
Wednesday, January 09, 2008
Training : SOAP and WS-Security in PHP
16th Wednesday...
If you are a PHP developer and would like to learn, how to deploy or consume web services, there are live on-line training sessions available in WSO2 developer portal.
Check this out...
This is a three hour course that brings you the essentials for building quick, inter-operable and secure applications using web services.
There are some other courses too. The complete course list can be seen here.
If you are a PHP developer and would like to learn, how to deploy or consume web services, there are live on-line training sessions available in WSO2 developer portal.
Check this out...
This is a three hour course that brings you the essentials for building quick, inter-operable and secure applications using web services.
There are some other courses too. The complete course list can be seen here.
TCP Monitor tool with WSO2 WSF/C
The TCPMonitor tool can be used to listen to TCP(Transmission Control Protocol) endpoints in your system. When you download and build WSO2 WSF/C, the tool is available at WSFC_HOME/bin/tools for your convenience. Go to the directory and start the tool as follows.
%tcpmon.exe
Note that I've used .exe for the Win32 systems. UNIX guys please use
%./tcpmon
OK. Now by default, the tool listens to the port 9090 and redirects messages to port 8080 at the localhost(i.e. to the same machine). Note: You may change these default settings using few command line arguments.
Usage : tcpmon.exe [-lp LISTEN_PORT] [-tp TARGET_PORT] [-th TARGET_HOST] [-f LOG_FILE]
e.g. tcpmon.exe -lp 9090 -tp 8080 -th localhost -f my_tcpmon.log
Since we are redirecting our messages to port 8080, this time we have to start the server listening to that port.
%axis2_http_server.exe -p8080
Alright now we are ready to sniff the wire content. Now what we have to do is start a client. The client samples are available at WSFC_HOME/bin/samples. I'll use the following. But try other samples as well.
%echo_blocking_addr.exe
OK now you see that your service invoke is successful and feel that the world is newer better. So please do open the tcpmon_traffic.log in WSFC_HOME/bin/tools using a text editor such as notepad, gedit or vi to see the wire content. Now you should see something like this.
The SOAP envelope in the first portion of the file shows the request and the last SOAP envelope shows the response from the server.
%tcpmon.exe
Note that I've used .exe for the Win32 systems. UNIX guys please use
%./tcpmon
OK. Now by default, the tool listens to the port 9090 and redirects messages to port 8080 at the localhost(i.e. to the same machine). Note: You may change these default settings using few command line arguments.
Usage : tcpmon.exe [-lp LISTEN_PORT] [-tp TARGET_PORT] [-th TARGET_HOST] [-f LOG_FILE]
e.g. tcpmon.exe -lp 9090 -tp 8080 -th localhost -f my_tcpmon.log
Since we are redirecting our messages to port 8080, this time we have to start the server listening to that port.
%axis2_http_server.exe -p8080
Alright now we are ready to sniff the wire content. Now what we have to do is start a client. The client samples are available at WSFC_HOME/bin/samples. I'll use the following. But try other samples as well.
%echo_blocking_addr.exe
OK now you see that your service invoke is successful and feel that the world is newer better. So please do open the tcpmon_traffic.log in WSFC_HOME/bin/tools using a text editor such as notepad, gedit or vi to see the wire content. Now you should see something like this.
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
SENDING DATA..
/* sending time = 10:58:13*/
---------------------
POST /axis2/services/echo HTTP/1.1
User-Agent: Axis2/C
Content-Length: 512
Content-Type: application/soap+xml;charset=UTF-8
Host: localhost:9090
<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
<soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing">
<wsa:To>http://localhost:9090/axis2/services/echo</wsa:To>
<wsa:Action>http://ws.apache.org/axis2/c/samples/echoString</wsa:Action>
<wsa:MessageID>02973ea8-bb4f-1dc1-2693-000000000000</wsa:MessageID>
</soapenv:Header>
<soapenv:Body>
<ns1:echoString xmlns:ns1="http://ws.apache.org/axis2/services/echo">
<text>Hello World!</text>
</ns1:echoString>
</soapenv:Body>
</soapenv:Envelope>
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
RETRIEVING DATA..
/* retrieving time = 10:58:13*/
/* time throughput = 0 sec(s)*/
---------------------
HTTP/1.1 200 OK
Content-Type: application/soap+xml;charset=UTF-8
Content-Length: 672
<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
<soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing">
<wsa:Action>http://ws.apache.org/axis2/c/samples/echoString</wsa:Action>
<wsa:From>
<wsa:Address>http://localhost:9090/axis2/services/echo</wsa:Address>
</wsa:From>
<wsa:MessageID>02983114-bb4f-1dc1-3856-000000000000</wsa:MessageID>
<wsa:RelatesTo wsa:RelationshipType="http://www.w3.org/2005/08/addressing/reply">02973ea8-bb4f-1dc1-2693-000000000000</wsa:RelatesTo>
</soapenv:Header>
<soapenv:Body>
<ns1:echoString xmlns:ns1="http://ws.apache.org/axis2/c/samples">
<text>Hello World!</text>
</ns1:echoString>
</soapenv:Body>
</soapenv:Envelope>
The SOAP envelope in the first portion of the file shows the request and the last SOAP envelope shows the response from the server.
Monday, January 07, 2008
WSO2 WSF/C 1.2.0 is released
The Web Services Framework for C (WSF/C) is an open source library written to provide and consume web services in C programming language. The framework is released under Apache license 2.0. That means it comes with a $0 cost and liberty to redistribute.
WSF/C also integrates many Apache projects. Using the famous Apache Axis2/C as the web services engine, it has also accoutered with Apache Rampart/C, Apache Sandesha2/C and Apache Savan/C.
Armed by all these WSF/C provides web services security, reliability and eventing support with just a single download. And it is inter-operable with Microsoft .Net, WSO2 Web Services Application Server and other J2EE implementation.
Moreover, WSO2 WSF/C is the base framework for other web service frameworks like WSF/PHP and WSF/Ruby.
WSO2 Team has announced the release of 1.2.0 last week. You may download the release here
WSF/C also integrates many Apache projects. Using the famous Apache Axis2/C as the web services engine, it has also accoutered with Apache Rampart/C, Apache Sandesha2/C and Apache Savan/C.
Armed by all these WSF/C provides web services security, reliability and eventing support with just a single download. And it is inter-operable with Microsoft .Net, WSO2 Web Services Application Server and other J2EE implementation.
Moreover, WSO2 WSF/C is the base framework for other web service frameworks like WSF/PHP and WSF/Ruby.
WSO2 Team has announced the release of 1.2.0 last week. You may download the release here
Wednesday, January 02, 2008
WSO2's WSF/PHP and Apache Ramaprt/C
Following diagram shows how the WSO2 WSF/PHP is arranged...
Basically the WSO2 WSF/PHP is a PHP extension. It can be seen as the upper layer of a 3-core wire.
And inside it there is another layer wrapping many other products, which we call the WSO2 WSF/C. These products are the implementations of WS-* of specifications including Apache Rampart/C, Apache Sandesha2/C, Apache Savan/C.
A PHP user will basically consume/provide web services by using the upper WSF/PHP layer. The core specifications and implementations are transparent to the PHP user to make the life easier. But sometimes it's worth to know how exactly are the inner components arranged. :)
In order to provide security, WSO2 WSF/PHP uses Apache Rampart/C. Actually via WSO2 WSF/C. Apache Rampart/C is the security module for the Apache Axis2/C engine, which the WSF/PHP depends on. You may refer my this blog entryto see how to write a PHP script to encrypt a SOAP message.
Basically the WSO2 WSF/PHP is a PHP extension. It can be seen as the upper layer of a 3-core wire.
And inside it there is another layer wrapping many other products, which we call the WSO2 WSF/C. These products are the implementations of WS-* of specifications including Apache Rampart/C, Apache Sandesha2/C, Apache Savan/C.
A PHP user will basically consume/provide web services by using the upper WSF/PHP layer. The core specifications and implementations are transparent to the PHP user to make the life easier. But sometimes it's worth to know how exactly are the inner components arranged. :)
In order to provide security, WSO2 WSF/PHP uses Apache Rampart/C. Actually via WSO2 WSF/C. Apache Rampart/C is the security module for the Apache Axis2/C engine, which the WSF/PHP depends on. You may refer my this blog entryto see how to write a PHP script to encrypt a SOAP message.
Subscribe to:
Posts (Atom)
