Tuesday, June 15, 2010

How to invoke a secured web service without maintaining a policy at the client side ?

http://charithaka.blogspot.com/2010/02/how-to-invoke-secured-web-service.html

Sunday, June 13, 2010

What are the required minimal jars to run an Axis2 client?

http://amilachinthaka.blogspot.com/2009/11/minimal-jars-required-for-axis2-15.html

Thursday, June 3, 2010

How to invoke a web service call with curl ?

If you are on Windows you can download the curl-7.19.5-win32-ssl-sspi.zip from here.

You can download the SimpleStockQuoteService.aar used in the example from here.

SOAP Invocations

curl -d @request.xml -H "Content-Type: application/soap
+xml action=getQuote" http://localhost:8080/axis2/services/SimpleStockQuoteService


The request.xml will look like following.

<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
<soapenv:Body>
<getQuote xmlns="http://services.samples">
<request>
   <symbol xmlns="http://services.samples/xsd">IBM</symbol>
</request>
</getQuote>
</soapenv:Body>
</soapenv:Envelope>

POX Invocations

curl -d @request.xml -H "Content-Type: application/xml" http://localhost:8080/axis2/services/SimpleStockQuoteService

*Notice that the Content-Type has changed.

Now the request.xml will look like following.

<getQuote xmlns="http://services.samples">
<request>
   <symbol xmlns="http://services.samples/xsd">IBM</symbol>
</request>
</getQuote>
If you want to invoke a service with an HTTPS end point without trusting it's certificate authority - you can use the option "-k"

curl -k -d @request.xml -H "Content-Type: application/xml action=getQuote" http://localhost:8080/axis2/services/SimpleStockQuoteService

Friday, May 7, 2010

How to cache Crypto objects in Rampart?

http://www.mail-archive.com/rampart-dev@ws.apache.org/msg04375.html

How does clustering affect the security context token with WS-SecureConversation?

Rampart keeps Token Storage in the Axis2 ConfigurationContext.

TokenStorage storage = (TokenStorage) configurationContext.getProperty(TokenStorage.TOKEN_STORAGE_KEY);

If you use WSAS [which is built on top of Axis2] to enable clustering, it replicates following three session data accross nodes.

-ServiceContext: Data that should only be available to a service.
-ServiceGroupContext: Common data for all the services in a service group.
-ConfigurationContext: Common data for all the service groups

This explains more about how to clustering with WSAS.

Thursday, May 6, 2010

WS-Trust with SAML vs. WS-SecureConversation

WS-Trust builds on the framework provided by WS-Security, defining SOAP based mechanisms for brokering trust relationships, requesting and returning security tokens.

WS-Security provides mechanisms for securing a single message in a one-way message exchange. Often interactions between a Web service and a consumer will result in multiple messages being exchanged. While each message could be secured in isolation, it is more efficient to establish some form of context that the Web service and consumer share and use that context to reduce the burden with respect to securing each message exchanged. WS-SecureConversation defines a Security Context Token [SCT] to perform this task.

WS-SecureConversation defines three ways to establish the SCT.

1. Security context token created by a security token service
2. Security context token created by one of the communicating parties and propagated with a message
3. Security context token created through negotiation/exchanges

In [1] and [2] the initiator establishes the security context token (SCT) by using the WS-Trust protocol for session-based security with the recipient.After establishing the security context token, derived keys from the security context token are used to sign and encrypt the SOAP message to provide message-level protection.

In [1], the context initiator asks a security token service to create a new security context token - based on WS-Trust.

In [2], the initiator creates a security context token and sends
it to the other parties on a message using the mechanisms described in this specification and in WS-Trust.

Above explains all about the relationship between WS-Trust and WS-SecureConversation.

In otherwords, WS-SecureConversation uses WS-Trust to establish the SCT.

SAML is an XML-encoded framework for exchanging authentication, subject attribute and
authorization information.

Under the WS-Trust protocol we can add SAML Assertions under the wst:RequestedSecurityToken of the RSTR returned by the STS.

When you use SAML is WS-Trust, that is for identity propagation - When we use WS-Trust with SecureConversation, that is for establishing a SCT.

So, the question is when to use SAML with WS-Trust and when to use WS-Trust with SecureConversation.

If relying party service requires user attributes [claims] in addition to the authentication - then we can use SAML with WS-Trust.

If relying party service requires to establish an authenticated session with the client - then we can use SecureConversation with WS-Trust.

Wednesday, December 2, 2009

How to build rampart-config programmatically..

This post explains, how to build the rampart-config programmatically at service consumer's end, without specifying it in policy file.