Hello Paul,
I still could not do this :)
I got an error showed below.
I suppose that something wrong with policy files... but I could not
realize what is exactly wrong because I'm new in this area.
I attached policy files and client and it will be good if you look there.
PolicyCache.xml - policy file from workable .net client
rampart.policy - contains configuration for the rampart
Client.java - test code for the web service
Error:
[EMAIL PROTECTED] classes]$
/home/mikolg/job/axis2/axis2-1.1/bin/axis2.sh org.tempuri.Client
Using AXIS2_HOME: /home/mikolg/job/axis2/axis2-1.1
Using JAVA_HOME: /etc/alternatives/java_sdk_1.5.0
17.05.2007 16:03:25 org.apache.axis2.deployment.DeploymentEngine doDeploy
INFO: Deploying module : soapmonitor-1.1
17.05.2007 16:03:25 org.apache.axis2.deployment.DeploymentEngine doDeploy
INFO: Deploying module : addressing-1.1
17.05.2007 16:03:26 org.apache.axis2.deployment.DeploymentEngine doDeploy
INFO: Deploying module : rahas-1.1
17.05.2007 16:03:27 org.apache.axis2.deployment.DeploymentEngine doDeploy
INFO: Deploying module : rampart-1.1
17.05.2007 16:03:27 org.apache.axis2.deployment.DeploymentEngine doDeploy
INFO: Deploying Web service version.aar
Unknown top level PED found:
org.apache.neethi.builders.xml.XmlPrimtiveAssertion
Unknown top level PED found:
org.apache.neethi.builders.xml.XmlPrimtiveAssertion
Unknown top level PED found:
org.apache.neethi.builders.xml.XmlPrimtiveAssertion
Unknown top level PED found:
org.apache.neethi.builders.xml.XmlPrimtiveAssertion
Exception in thread "main" java.lang.NullPointerException
at
org.apache.rampart.util.RampartUtil.addWsuIdToElement(RampartUtil.java:463)
at
org.apache.rampart.builder.AsymmetricBindingBuilder.doSignBeforeEncrypt(AsymmetricBindingBuilder.java:277)
at
org.apache.rampart.builder.AsymmetricBindingBuilder.build(AsymmetricBindingBuilder.java:85)
at org.apache.rampart.MessageBuilder.build(MessageBuilder.java:129)
at
org.apache.rampart.handler.RampartSender.invoke(RampartSender.java:59)
at org.apache.axis2.engine.Phase.invoke(Phase.java:381)
at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:518)
at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:651)
at
org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:365)
at
org.apache.axis2.description.OutInAxisOperationClient.execute(OutInAxisOperation.java:295)
at org.tempuri.JobStub.ListJobAreas(JobStub.java:185)
at org.tempuri.Client.main(Client.java:44)
Paul Fremantle wrote:
Let me know if it works.
Paul
On 5/16/07, Mikhail Maroukhine <[EMAIL PROTECTED]> wrote:
Thanks Paul
I'll try to do it in this way...
Paul Fremantle wrote:
> Mikhail
>
> Yes I have experience of doing this. The latest Axis2 1.2 release will
> embed the policy into the code-generated stub and attempt to engage
> Rampart with that policy.
>
> Alternatively you can explicitly set the policy using:
>
> StAXOMBuilder builder = new StAXOMBuilder(xmlPath);
> Policy policy = PolicyEngine.getPolicy(builder.getDocumentElement());
>
stub._getServiceClient().getOptions().setProperty(RampartMessageData.KEY_RAMPART_POLICY,
>
> policy);
>
> In general you also need to configure Rampart with information like
> passwords etc.
>
> You do this using another policy file like this:
>
> <ramp:RampartConfig xmlns:ramp="http://ws.apache.org/rampart/policy";>
> <ramp:timestampTTL>303</ramp:timestampTTL>
> <ramp:encryptionUser>me</ramp:encryptionUser>
> <ramp:passwordCallbackClass>PWCallback</ramp:passwordCallbackClass>
> ,,,
> </ramp:RampartConfig>
>
> You can merge the two policies first - so:
>
> StAXOMBuilder builder = new StAXOMBuilder(dotnetPolicy);
> Policy dotnetPolicy =
> PolicyEngine.getPolicy(builder.getDocumentElement());
> StAXOMBuilder builder2 = new StAXOMBuilder(rampartPolicy);
> Policy rampartPolicy =
> PolicyEngine.getPolicy(builder.getDocumentElement());
> Policy policy = dotnetPolicy.merge(rampartPolicy);
>
> And then set it onto the stub or service client as above.
>
> Paul
>
--
WBR,
Mikhail
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
WBR,
Mikhail
package org.tempuri;
import org.apache.axiom.om.OMAbstractFactory;
import org.apache.axiom.om.OMElement;
import org.apache.axiom.om.OMFactory;
import org.apache.axiom.om.OMNamespace;
import org.apache.axiom.om.impl.builder.StAXOMBuilder;
import org.apache.axis2.Constants;
import org.apache.axis2.addressing.EndpointReference;
import org.apache.axis2.client.Options;
import org.apache.axis2.client.ServiceClient;
import org.apache.axis2.context.ConfigurationContext;
import org.apache.axis2.context.ConfigurationContextFactory;
import org.apache.neethi.Policy;
import org.apache.neethi.PolicyEngine;
import org.apache.rampart.RampartMessageData;
public class Client {
private static String dotnetPolicy = "/home/mikolg/job/axis2/axis2-1.1/samples/rt/PolicyCache.xml";
private static String rampartPolicy = "/home/mikolg/job/axis2/axis2-1.1/samples/rt/rampart.policy";
public static void main(String[] args) throws Exception {
JobStub s = new JobStub("http://xxx/WSWrapper/Job.asmx";);
StAXOMBuilder builder = new StAXOMBuilder(dotnetPolicy);
Policy dotnetPolicy = PolicyEngine.getPolicy(builder.getDocumentElement());
StAXOMBuilder builder2 = new StAXOMBuilder(rampartPolicy);
Policy p1 = PolicyEngine.getPolicy(builder.getDocumentElement());
Policy policy = dotnetPolicy.merge(p1);
s._getServiceClient().getOptions().setProperty(RampartMessageData.KEY_RAMPART_POLICY,policy);
JobStub.ListJobAreas req = new JobStub.ListJobAreas();
Object res =
s.ListJobAreas(req);
System.out.println(res);
}
}<?xml version="1.0" encoding="utf-8"?>
<policyDocument xmlns="http://schemas.microsoft.com/wse/2003/06/Policy";>
<mappings xmlns:wse="http://schemas.microsoft.com/wse/2003/06/Policy";>
<!--The following policy describes the policy requirements for the service: http://129.35.74.93/WSwrapper/WSSecurity.asmx .-->
<endpoint uri="Http://xxx/WSWrapper/Job.asmx">
<defaultOperation>
<request policy="#Sign-SCT" />
<response policy="#Sign-SCT-1" />
<fault policy="" />
</defaultOperation>
<operation requestAction="http://schemas.xmlsoap.org/ws/2004/04/security/trust/RST/SCT";>
<!--RST and RSTR messages are being processed by WSE policy engine similar to other messages. If a service policy mapping
specifies policies that use SCT token for defaultOperation, there MUST be a separate mapping for RST/RSTR messages.
Policies specified for RST/RSTR messages can be empty. In addition to the policy specified for RST and RSTR messages,
WSE infrastructure will enforce and verify that:
1. RST Enforcement: An RST message will be signed using baseToken. If an Issuer Token is present, an entropy will be created and encrypted
using the Issuer Token. If a UsernameToken is used in the message it will be encrypted using the Issuer Token.
2. RST Verification: An RST message must be signed. If the RST contains an entropy, it must be encrypted by the server token.
If a UsernameToken was used in the message it must be encrypted.
3. RSTR Enforcement: An RSTR message will be signed using the server token. If the client used entropy in the RST message, a server entropy
will be created and encrypted with client's entropy token. If a Username token is used in the message it will be encrypted
with the client's entropy token.
4. RSTR Verification: An RSTR message must be signed using the Server Token. If an entropy is used it must be encrypted using client's
entropy token. If a username token is issued in the RSTR message it must be encrypted.
Implement a custom SecurityContextTokenService or SecurityContextTokenServiceClient to change the policy enforcement
and/or verification behaviors.
-->
<request policy="#Sign-Username" />
<response policy="#Sign-X.509" />
<fault policy="" />
</operation>
</endpoint>
<endpoint uri="Http://xxx/WSWrapper/Candidate.asmx">
<defaultOperation>
<request policy="#Sign-SCT" />
<response policy="#Sign-SCT-1" />
<fault policy="" />
</defaultOperation>
<operation requestAction="http://schemas.xmlsoap.org/ws/2004/04/security/trust/RST/SCT";>
<!--RST and RSTR messages are being processed by WSE policy engine similar to other messages. If a service policy mapping
specifies policies that use SCT token for defaultOperation, there MUST be a separate mapping for RST/RSTR messages.
Policies specified for RST/RSTR messages can be empty. In addition to the policy specified for RST and RSTR messages,
WSE infrastructure will enforce and verify that:
1. RST Enforcement: An RST message will be signed using baseToken. If an Issuer Token is present, an entropy will be created and encrypted
using the Issuer Token. If a UsernameToken is used in the message it will be encrypted using the Issuer Token.
2. RST Verification: An RST message must be signed. If the RST contains an entropy, it must be encrypted by the server token.
If a UsernameToken was used in the message it must be encrypted.
3. RSTR Enforcement: An RSTR message will be signed using the server token. If the client used entropy in the RST message, a server entropy
will be created and encrypted with client's entropy token. If a Username token is used in the message it will be encrypted
with the client's entropy token.
4. RSTR Verification: An RSTR message must be signed using the Server Token. If an entropy is used it must be encrypted using client's
entropy token. If a username token is issued in the RSTR message it must be encrypted.
Implement a custom SecurityContextTokenService or SecurityContextTokenServiceClient to change the policy enforcement
and/or verification behaviors.
-->
<request policy="#Sign-Username" />
<response policy="#Sign-X.509" />
<fault policy="" />
</operation>
</endpoint>
</mappings>
<policies xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"; xmlns:wsp="http://schemas.xmlsoap.org/ws/2002/12/policy"; xmlns:wssp="http://schemas.xmlsoap.org/ws/2002/12/secext"; xmlns:wse="http://schemas.microsoft.com/wse/2003/06/Policy"; xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"; xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing";>
<wsp:Policy wsu:Id="Sign-Username">
<ramp:RampartConfig xmlns:ramp="http://ws.apache.org/rampart/policy";>
<ramp:timestampTTL>500</ramp:timestampTTL>
<ramp:encryptionUser>NO</ramp:encryptionUser>
<ramp:passwordCallbackClass>org.tempuri.PWCallback</ramp:passwordCallbackClass>
</ramp:RampartConfig>
<!--MessagePredicate is used to require headers. This assertion should be used along with the Integrity assertion when the presence of the signed element is required. NOTE: this assertion does not do anything for enforcement (send-side) policy.-->
<wsp:MessagePredicate wsp:Usage="wsp:Required" Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part";>wsp:Body() wsp:Header(wsa:To) wsp:Header(wsa:Action) wsp:Header(wsa:MessageID) wse:Timestamp()</wsp:MessagePredicate>
<!--The Integrity assertion is used to ensure that the message is signed with Username. Many Web services will also use the token for authorization, such as by using the <wse:Role> claim or specific Username claims.-->
<wssp:Integrity wsp:Usage="wsp:Required">
<wssp:TokenInfo>
<!--The SecurityToken element within the TokenInfo element describes which token type must be used for Signing.-->
<wssp:SecurityToken>
<!--<wssp:TokenType>http://schemas.xmlsoap.org/ws/2004/04/security/sc/dk</wssp:TokenType>-->
<wssp:TokenType>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#UsernameToken</wssp:TokenType>
<wssp:Claims>
<wssp:UsePassword Type="wssp:PasswordDigest" wsp:Usage="wsp:Required" />
<wssp:SubjectName MatchType="wssp:Exact">NO</wssp:SubjectName>
</wssp:Claims>
</wssp:SecurityToken>
</wssp:TokenInfo>
<wssp:MessageParts Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part";>wsp:Body() wsp:Header(wsa:Action) wsp:Header(wsa:FaultTo) wsp:Header(wsa:From) wsp:Header(wsa:MessageID) wsp:Header(wsa:RelatesTo) wsp:Header(wsa:ReplyTo) wsp:Header(wsa:To) wse:Timestamp()</wssp:MessageParts>
</wssp:Integrity>
<wssp:Confidentiality wsp:Usage="wsp:Required">
<wssp:KeyInfo>
<wsse:SecurityTokenReference>
<wsse:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509SubjectKeyIdentifier"; xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";>bBwPfItvKp3b6TNDq+14qs58VJQ=</wsse:KeyIdentifier>
</wsse:SecurityTokenReference>
</wssp:KeyInfo>
<wssp:MessageParts xmlns:rp="http://schemas.xmlsoap.org/rp"; Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part";>wsp:Body()</wssp:MessageParts>
</wssp:Confidentiality>
</wsp:Policy>
<wsp:Policy wsu:Id="Sign-X.509">
<!--MessagePredicate is used to require headers. This assertion should be used along with the Integrity assertion when the presence of the signed element is required. NOTE: this assertion does not do anything for enforcement (send-side) policy.-->
<wsp:MessagePredicate wsp:Usage="wsp:Required" Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part";>wsp:Body() wsp:Header(wsa:To) wsp:Header(wsa:Action) wsp:Header(wsa:MessageID) wse:Timestamp()</wsp:MessagePredicate>
<!--The Integrity assertion is used to ensure that the message is signed with X.509. Many Web services will also use the token for authorization, such as by using the <wse:Role> claim or specific X.509 claims.-->
<wssp:Integrity wsp:Usage="wsp:Required">
<wssp:TokenInfo>
<!--The SecurityToken element within the TokenInfo element describes which token type must be used for Signing.-->
<wssp:SecurityToken>
<wssp:TokenType>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3</wssp:TokenType>
<wssp:TokenIssuer>CN=Root Agency</wssp:TokenIssuer>
<wssp:Claims>
<!--By specifying the SubjectName claim, the policy system can look for a certificate with this subject name in the certificate store indicated in the application's configuration, such as LocalMachine or CurrentUser. The WSE X.509 Certificate Tool is useful for finding the correct values for this field.-->
<wssp:SubjectName MatchType="wssp:Exact">CN=WSE2QuickStartServer</wssp:SubjectName>
<wssp:X509Extension OID="2.5.29.14" MatchType="wssp:Exact">bBwPfItvKp3b6TNDq+14qs58VJQ=</wssp:X509Extension>
</wssp:Claims>
</wssp:SecurityToken>
</wssp:TokenInfo>
<wssp:MessageParts Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part";>wsp:Body() wsp:Header(wsa:Action) wsp:Header(wsa:FaultTo) wsp:Header(wsa:From) wsp:Header(wsa:MessageID) wsp:Header(wsa:RelatesTo) wsp:Header(wsa:ReplyTo) wsp:Header(wsa:To) wse:Timestamp()</wssp:MessageParts>
</wssp:Integrity>
</wsp:Policy>
<wsp:Policy wsu:Id="Sign-SCT">
<!--MessagePredicate is used to require headers. This assertion should be used along with the Integrity assertion when the presence of the signed element is required. NOTE: this assertion does not do anything for enforcement (send-side) policy.-->
<wsp:MessagePredicate wsp:Usage="wsp:Required" Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part";>wsp:Body() wsp:Header(wsa:To) wsp:Header(wsa:Action) wsp:Header(wsa:MessageID) wse:Timestamp()</wsp:MessagePredicate>
<!--The Integrity assertion is used to ensure that the message is signed with SCT. Many Web services will also use the token for authorization, such as by using the <wse:Role> claim or specific SCT claims.-->
<wssp:Integrity wsp:Usage="wsp:Required" xmlns="http://schemas.xmlsoap.org/ws/2002/12/secext";>
<wssp:TokenInfo>
<wssp:SecurityToken wse:IdentityToken="true">
<wssp:TokenType>http://schemas.xmlsoap.org/ws/2004/04/security/sc/sct</wssp:TokenType>
<wssp:Claims>
<wse:BaseToken>
<wssp:SecurityToken>
<wssp:TokenType>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#UsernameToken</wssp:TokenType>
</wssp:SecurityToken>
</wse:BaseToken>
</wssp:Claims>
</wssp:SecurityToken>
</wssp:TokenInfo>
<wssp:MessageParts Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part";>wsp:Body()</wssp:MessageParts>
</wssp:Integrity>
</wsp:Policy>
<wsp:Policy wsu:Id="Sign-SCT-1">
<!--MessagePredicate is used to require headers. This assertion should be used along with the Integrity assertion when the presence of the signed element is required. NOTE: this assertion does not do anything for enforcement (send-side) policy.-->
<wsp:MessagePredicate wsp:Usage="wsp:Required" Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part";>wsp:Body() wsp:Header(wsa:To) wsp:Header(wsa:Action) wsp:Header(wsa:MessageID) wse:Timestamp()</wsp:MessagePredicate>
<!--The Integrity assertion is used to ensure that the message is signed with SCT. Many Web services will also use the token for authorization, such as by using the <wse:Role> claim or specific SCT claims.-->
<wssp:Integrity wsp:Usage="wsp:Required">
<wssp:TokenInfo>
<!--The SecurityToken element within the TokenInfo element describes which token type must be used for Signing.-->
<wssp:SecurityToken>
<wssp:TokenType>http://schemas.xmlsoap.org/ws/2004/04/security/sc/dk</wssp:TokenType>
<wssp:Claims>
<wse:Parent>
<wssp:SecurityToken wse:IdentityToken="true">
<wssp:TokenType>http://schemas.xmlsoap.org/ws/2004/04/security/sc/sct</wssp:TokenType>
</wssp:SecurityToken>
</wse:Parent>
</wssp:Claims>
</wssp:SecurityToken>
</wssp:TokenInfo>
<wssp:MessageParts Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part";>wsp:Body() wsp:Header(wsa:Action) wsp:Header(wsa:FaultTo) wsp:Header(wsa:From) wsp:Header(wsa:MessageID) wsp:Header(wsa:RelatesTo) wsp:Header(wsa:ReplyTo) wsp:Header(wsa:To) wse:Timestamp()</wssp:MessageParts>
</wssp:Integrity>
</wsp:Policy>
</policies>
</policyDocument><ramp:RampartConfig xmlns:ramp="http://ws.apache.org/rampart/policy";>
<ramp:timestampTTL>500</ramp:timestampTTL>
<ramp:encryptionUser>NO</ramp:encryptionUser>
<ramp:passwordCallbackClass>org.tempuri.PWCallback</ramp:passwordCallbackClass>
</ramp:RampartConfig>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
