axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Gainty <>
Subject RE: Having trouble interfacing with WCF
Date Fri, 05 Aug 2011 19:39:09 GMT

1)you need a Policy object if you are planning a live production Rampart secured axis-web-service
...from the doc
"It is recommended to use policy based configuration model for all production scenarios "

IF you're generating the policy attributes into the Policy object then you will NOT need policy.xml
(or anyfile which contains the policy attributes)
if you are NOTgenerating the policy attributes into a generated Policy Object then you will
absolutely need to read in a policy.xml to StAXOMBuilder
the filename can be any name that is loaded to the StAXOMBuilder

take a look at this simple client example:
                ServiceContext context = serviceClient.getServiceContext();
                        loadPolicy("/rampart/policy/" + i + ".xml"));

    private Policy loadPolicy(String xmlPath) throws Exception {
        StAXOMBuilder builder = new StAXOMBuilder(RampartTest.class.getResourceAsStream(xmlPath));
        return PolicyEngine.getPolicy(builder.getDocumentElement());

2) populating signatureCrypto element of RampartConfig
if you are using merlin as your encryption provider then you can assign the signatureCrypto
element with merlin(provider)assigned properties:
I use bouncycastle crypto provider myself..but merlin crypto provider will do just fine
	<crypto provider="">
		<property name="">JKS</property>
		<property name="">client.jks</property>
		<property name="">apache</property>
be forewarned client.jks must exist on classpath
3)passwordCallback populates passwordCallBackClass element of RampartConfig
you can generate your own Class which extends PWCallback if you do not need any custom refactorings
assigning base PWCallbackClass will do
</passwordCallbackClass>Read this to gain an understanding of RampartConfig and how
to configure RampartConfig:

Your best way to learn this is to run the samples located at

download samples
run the sample which demonstrates UsernameToken Authentication
The policy uses a TransportBinding and requires a SignedSupportingToken which 
is a UsernameToken and the inclusion of a TimeStamp. 

cd sample/policy
$ant service.01
$ant client.01

ping back if you have any questions.
Martin Gainty 
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten
wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist
unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet
keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen
wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire
prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe
quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information
seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les
email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune
responsabilité pour le contenu fourni.

Date: Fri, 5 Aug 2011 13:57:54 -0400
Subject: Re: Having trouble interfacing with WCF

On Fri, Aug 5, 2011 at 12:34 PM, Hasini Gunasinghe <> wrote:

Hi Jay,

Since you've generated stubs from a security policy annotated wsdl, you do not need to load
the security policy from file in the client side.

But you need to set the rampart specific configurations in the client side. The article that
I pointed in my previous mail describes how to do it programetically in the client side. The
article at [1] also discusses the same.

You can find a list of such rampart configurations from [2].

The above null pointer exceptions might have occurred due to not setting required rampart
configurations (like keystore details, encyptionUser, userCertAlias etc..) for the relevant
security scenarios, in the client side.


For [1]:

First of all, I have no idea what options to set here...are the merlinProp Properties there
to supply a client-side certificate? (and thus not necessary if I'm doing a UserName token
sort of thing?)  I think it's confusing that there's both a setUser(..) and setEncryptionUser(..);
not sure if I should just put the same thing in both places...then, after that, it's not clear
if this will override my options.setUserName(..) setting.   And what's the deal with the password
callback? Can't we just supply a password as a string without requiring a callback?  

I tried it anyway, but here's where I get stuck:

StAXOMBuilder builder = new StAXOMBuilder("path/to/policy");  
Policy policy = PolicyEngine.getPolicy(builder.getDocumentElement());  policy.addAssertion(rc);
I don't have a "path/to/policy", remember it's generated, so I'm stuck on this.  

Thanks for the help! I don't mean to be a stickler or anything, I honestly want to understand
this all and there's just a bunch of things that haven't been cleared up yet for me.
Jay Sullivan
View raw message