Re: Rampart one way only

[RonnieMJ]

I tried putting moving the Security phase to the end of that PhaseOrder (for
both InFaultFlow and InFault).  It didn't help.  Maybe it's because I'm
using axis2 1.3.

I'm loading my policies in one fail swoop from code (not from the
service.xml file).

options.setProperty(RampartMessageData.KEY_RAMPART_POLICY, 
loadPolicy(confDir + "/clientSecurityPolicy.xml"));
stub._getServiceClient().setOptions(options);


so I have 2 questions.
1.  Would I need to switch (back) to 1.4.1 to use message level security?
2.  Would I specify this in my code or my policy file?




Nunny wrote:
> 
> Hi Mary,
>   I  think best way to solve this problem is to use message level
> policies. You can attach policies at message level, so they will be
> effective either on in the in flow or our flow. But still we have the
> problem that we can't specify policies for fault flows, For example, if we
> specify a policy for in message it will be applicable for both in message
> and in fault messages.
>  In Axis2 , we have two kinds phases global phases and operation
> phases.
> This article [1] by Deepal explains the whole concept.   Phases before
> dispatch phases are known as global phases and they will be called for
> each
> and every message. Security is a global phase. We need security as a
> global
> phase become dispatching mechanism like body based dispatching which used
> to
> dispatch operations need messages to be decrypted before they can act on
> the
> message. But having the security phase doesn't have any effect if rampart
> is
> not engaged. As it is described in the article, it is the rampart module
> that adds handlers to the phase. Even if the Rampart is engaged, if the
> effective security policy of the message is null, then those handlers will
> not have any effect.
> 
> thanks,
> nandana
> 
> [1] - http://www.packtpub.com/article/handler-and-phase-in-apache-axis
> 
> On Sat, Oct 25, 2008 at 4:17 AM, Mary Thompson <[EMAIL PROTECTED]> wrote:
> 
>> I ran into the same problem when I switched to ws-policy. First I had to
>> add the security phase to infaultflow and then the unsigned fault
>> messages
>> were not acceptable. I "fixed" it by moving the security phase in the
>> infaultflow to the end the phase order after OperationInFaultPhase
>> effectively causing it to be ignored.
>>
>> I wonder if the piece of code that insists you add a security phase when
>> you don't want any security is wrong. Or if there is some way to indicate
>> a
>> null security phase.
>>
>> Mary Thompson
>>
>>
>>
>> RonnieMJ wrote:
>>
>>> Ok I added an axis2.xml file in my repo, however commenting out any
>>> Security
>>> phase causes errors indicating that the Security phase is missing.
>>>
>>> I'm wondering if you would ALSO have to remove any phase info from the
>>> modules.xml file in the rampart mar?
>>>
>>> In this case I'm the client, but receiving a response.  Wouldn't I want
>>> to
>>> remove the security phase from the InFlow not out?
>>>
>>>
>>>
>>> Chris82KS wrote:
>>>
>>>> Hello,
>>>> inside the axis2.xml you have the different flows (inFlow, OutFlow,
>>>> InFault and OutFault). Just remove the phase "Security" from the
>>>> OutFlow
>>>> and the OutFaultFlow.
>>>>
>>>> Greetings
>>>> Christian
>>>>
>>>>
>>>> - original Nachricht 
>>>>
>>>> Betreff: Rampart one way only
>>>> Gesendet: Do, 23. Okt 2008
>>>> Von: RonnieMJ<[EMAIL PROTECTED]>
>>>>
>>>>  Is it possible to have rampart NOT be concerned with security on a
>>>>> return
>>>>> message in a synchronous transaction?
>>>>>
>>>>> Example:
>>>>> I send to server X with security headers.  They return an OK message
>>>>> or
>>>>> a
>>>>> fault.  Neither of which would have security heading information.
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/Rampart-one-way-only-tp20133511p20133511.html
>>>>> Sent from the Axis - User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>> -
>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>>
>>>>>
>>>>>  --- original Nachricht Ende 
>>>>
>>>>
>>>> -
>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>
>>>>
>>>>
>>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
> 
> 
> -- 
> Nandana Mihindukulasooriya
> WSO2 inc.
> 
> http://nandana83.blogspot.com/
> http://www.wso2.org
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Rampart-one-way-only-tp20133511p20190479.html
Sent from the Axis - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Rampart one way only

[RonnieMJ]

Ok I added an axis2.xml file in my repo, however commenting out any Security
phase causes errors indicating that the Security phase is missing.

I'm wondering if you would ALSO have to remove any phase info from the
modules.xml file in the rampart mar?

In this case I'm the client, but receiving a response.  Wouldn't I want to
remove the security phase from the InFlow not out?



Chris82KS wrote:
> 
> Hello,
> inside the axis2.xml you have the different flows (inFlow, OutFlow,
> InFault and OutFault). Just remove the phase "Security" from the OutFlow
> and the OutFaultFlow.
> 
> Greetings
> Christian
> 
> 
> - original Nachricht 
> 
> Betreff: Rampart one way only
> Gesendet: Do, 23. Okt 2008
> Von: RonnieMJ<[EMAIL PROTECTED]>
> 
>> 
>> Is it possible to have rampart NOT be concerned with security on a return
>> message in a synchronous transaction?
>> 
>> Example:
>> I send to server X with security headers.  They return an OK message or a
>> fault.  Neither of which would have security heading information.
>> -- 
>> View this message in context:
>> http://www.nabble.com/Rampart-one-way-only-tp20133511p20133511.html
>> Sent from the Axis - User mailing list archive at Nabble.com.
>> 
>> 
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>> 
>> 
> 
> --- original Nachricht Ende 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Rampart-one-way-only-tp20133511p20137306.html
Sent from the Axis - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Rampart one way only

[RonnieMJ]

What if you're using a policy.xml file?  I haven't been using a custom axis2
file.  I wasn't sure if I needed to with using Policies.



Chris82KS wrote:
> 
> Hello,
> inside the axis2.xml you have the different flows (inFlow, OutFlow,
> InFault and OutFault). Just remove the phase "Security" from the OutFlow
> and the OutFaultFlow.
> 
> Greetings
> Christian
> 
> 
> - original Nachricht 
> 
> Betreff: Rampart one way only
> Gesendet: Do, 23. Okt 2008
> Von: RonnieMJ<[EMAIL PROTECTED]>
> 
>> 
>> Is it possible to have rampart NOT be concerned with security on a return
>> message in a synchronous transaction?
>> 
>> Example:
>> I send to server X with security headers.  They return an OK message or a
>> fault.  Neither of which would have security heading information.
>> -- 
>> View this message in context:
>> http://www.nabble.com/Rampart-one-way-only-tp20133511p20133511.html
>> Sent from the Axis - User mailing list archive at Nabble.com.
>> 
>> 
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>> 
>> 
> 
> --- original Nachricht Ende 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Rampart-one-way-only-tp20133511p20136376.html
Sent from the Axis - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Rampart one way only

[RonnieMJ]

Is it possible to have rampart NOT be concerned with security on a return
message in a synchronous transaction?

Example:
I send to server X with security headers.  They return an OK message or a
fault.  Neither of which would have security heading information.
-- 
View this message in context: 
http://www.nabble.com/Rampart-one-way-only-tp20133511p20133511.html
Sent from the Axis - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: mustUnderstand attribute not declared

[RonnieMJ]

You might try posting the SOAP message.  From your post I can't tell if it's
an addressing section or security related.



Karl Moss wrote:
> 
> Just a little more information:
> 
> I have tried both Axis2 versions 1.3 and 1.4 and get the same error
> message.
> 
> Karl.
> 
> -Original Message-
> From: Karl Moss [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, October 22, 2008 2:11 PM
> To: axis-user@ws.apache.org
> Subject: mustUnderstand attribute not declared
> 
> I'm somewhat new to Axis2 and running into a problem. I'm using the
> Exchange Web Services wsdl and attempting to invoke a method on the stub.
> I appear to be authenticating fine, but am getting the exception:
> 
> org.apache.axis2.AxisFault: The request failed schema validation: The
> 'http://schemas.xmlsoap.org/soap/envelope/:mustUnderstand' attribute is
> not declared.
> 
> I've tried to set the ADD_MUST_UNDERSTAND_TO_ADDRESSING_HEADERS to my
> MessageContext properties, but no luck.
> 
> Any ideas?
> 
> Thanks,
> 
> Karl.
> 
> 
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/mustUnderstand-attribute-not-declared-tp20116637p20133355.html
Sent from the Axis - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Rampart, turning off mustUnderstand="true" in Header

[RonnieMJ]

Simon,

I have the same sort of problem (sort of) in that while the first server I'm
talking to as a client requires the security, the second (back end) server
doesn't understand it.

You can see this thread - 
http://www.nabble.com/Rampart-1.4-mustUnderstand-td19926442.html
http://www.nabble.com/Rampart-1.4-mustUnderstand-td19926442.html 

To finally get this to work, we had to modify the source code for ramart
just for our installation.

Basically manually setting it in the RampartMessageData class:
this.secHeader = new WSSecHeader();
secHeader.setMustUnderstand(false);// inserted

Not at all attractive, but it worked...  good for a one off solution I
guess.  


Simon-2716 wrote:
> 
> Hello,
> 
>  
> 
> I am sending a usernametoken and automatically the mustUnderstand
> attribute
> is set to true in the Secuirty header. My counterpart service does
> understand security headers, but somehow an exception is thrown, that the
> mustunderstand check failed. Is it possible to tell my client to NOT add
> the
> mustUnderstand="true" attribute?
> 
>  
> 
> Thanks for your help,
> 
> Regards Simon
> 
>  
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Rampart%2C-turning-off-mustUnderstand%3D%22true%22-in-Header-tp20113579p20116281.html
Sent from the Axis - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Rampart 1.4 mustUnderstand

[RonnieMJ]

Well that was kinda my point to the company that we're integrating with. 
They don't pull it off (and could).  But getting them to change isn't going
to happen anytime soon.  I guess that they're not really into using custom
code to pull it off when the actor/role would be able to do it.  It does
pass the whole message.


Nunny wrote:
> 
> Hi Ronnie,
>Got you you requirement. I think in that case, it will  be better
> if
> we can use soap actor / role. I will take a look at how much time/effort
> it
> will take to fix the  issue  [1]. I am interested in to know how your
> security firewall implemented. Does it pass the message as it to the real
> service ? So how something like decryption is handled ? Can't you just
> detach the security header [2] from the message before sending to the
> ultimate endpoint as it anyway doesn't understand it and not expected to
> process it.
> 
> thanks,
> nandana
> 
> [1] - http://issues.apache.org/jira/browse/RAMPART-16
> [2] -
> http://nandana83.blogspot.com/2008/10/how-to-expose-web-service-protected-by.html
> 
> On Fri, Oct 17, 2008 at 2:o27 AM, RonnieMJ <[EMAIL PROTECTED]>
> wrote:
> 
>> i
>> I see what you're saying, and I have seen this as an issue that others
>> have
>> expressed, however it's not quite the issue I'm referring to.
>>
>> My issue turns out to be that as a client, I send to some service.  That
>> service is not the ultimate receiver endpoint.  It is more of simply a
>> security endpoint on a firewall.  After verifying the security is ok,
>> that
>> server forwards it to the ultimate receiver endpoint.  Problem is that
>> THIS
>> server doesn't understand security, and returns a fault.  The
>> mustUnderstand
>> fault I get (Exception during processing: javax.xml.soap.SOAPException:
>> Unable to handle mustUnderstand header: wsse:Security (see Fault Detail
>> for
>> stacktrace)) is thrown by the server and not by rampart.
>>
>> So it turns out to be the inability to EITHER specify mustUnderstand = 0
>> OR
>> specify an actor (soap 1.1) or role (soap 1.2).  If I were able to
>> specify
>> "next" as the actor for the security header, this wouldn't be an issue
>> (or
>> if I was able to set mustUnderstand=0).
>>
>> I would say it's more this
>> http://issues.apache.org/jira/browse/RAMPART-16
>> JIRA .
>>
>> Or this  https://issues.apache.org/jira/browse/AXIS2-3982 JIRA .
>>
>> Either one would actually work I believe.
>>
>>
>>
>> Nunny wrote:
>> >
>> > Hi,
>> >   The reason for this is due to the implementation logic. In Rampart
>> 1.3,
>> > rampart processes the empty security header and set it as processed.
>> But
>> > in
>> > Rampart 1.4, before going to the processing, Rampart evaluates the
>> policy
>> > and check whether it is expecting a security header. And if it is not
>> > expecting a security header it, just  returns.  So in the latter case ,
>> > the
>> > security header is not flagged as process. This causes AxisEngine to
>> cough
>> > as there are must understand headers not processed.
>> >   We will fix this issue [1], so this no longer be a problem.
>> > thanks,
>> > nandana
>> >
>> > [1] - http://issues.apache.org/jira/browse/RAMPART-197
>> >
>> > On Wed, Oct 15, 2008 at 12:21 PM, Taariq Levack
>> > <[EMAIL PROTECTED]>wrote:
>> >
>> >> In my case it still says mustUnderstand=1, but it tolerates the empty
>> >> header which 1.4 does not.
>> >>
>> >> -Original Message-
>> >> From: RonnieMJ [mailto:[EMAIL PROTECTED]
>> >> Sent: 15 October 2008 01:30
>> >> To: axis-user@ws.apache.org
>> >> Subject: RE: Rampart 1.4 mustUnderstand
>> >>
>> >>
>> >> I switched back to axis 1.3 with rampart 1.3.  Still getting
>> >> mustUnderstand=1.  I see others with the issue when using their own
>> >> axis2.xml, but I'm using the default axis2.xml that comes with axis. 
>> I
>> >> simply load the client policy (attached).  Is it something in my
>> policy
>> >> that
>> >> causes mustUnderstand=1?  I wouldn't think so.
>> >>
>> >>
>> >>
>> >> Taariq Levack wrote:
>> >> >
>> >> > Had the same issue recently, the security header coming back from
>> the
>> >> &g

Re: Rampart 1.4 mustUnderstand

[RonnieMJ]

I see what you're saying, and I have seen this as an issue that others have
expressed, however it's not quite the issue I'm referring to.

My issue turns out to be that as a client, I send to some service.  That
service is not the ultimate receiver endpoint.  It is more of simply a
security endpoint on a firewall.  After verifying the security is ok, that
server forwards it to the ultimate receiver endpoint.  Problem is that THIS
server doesn't understand security, and returns a fault.  The mustUnderstand
fault I get (Exception during processing: javax.xml.soap.SOAPException:
Unable to handle mustUnderstand header: wsse:Security (see Fault Detail for
stacktrace)) is thrown by the server and not by rampart.

So it turns out to be the inability to EITHER specify mustUnderstand = 0 OR
specify an actor (soap 1.1) or role (soap 1.2).  If I were able to specify
"next" as the actor for the security header, this wouldn't be an issue (or
if I was able to set mustUnderstand=0).

I would say it's more this  http://issues.apache.org/jira/browse/RAMPART-16
JIRA .  

Or this  https://issues.apache.org/jira/browse/AXIS2-3982 JIRA .

Either one would actually work I believe.



Nunny wrote:
> 
> Hi,
>   The reason for this is due to the implementation logic. In Rampart 1.3,
> rampart processes the empty security header and set it as processed. But
> in
> Rampart 1.4, before going to the processing, Rampart evaluates the policy
> and check whether it is expecting a security header. And if it is not
> expecting a security header it, just  returns.  So in the latter case ,
> the
> security header is not flagged as process. This causes AxisEngine to cough
> as there are must understand headers not processed.
>   We will fix this issue [1], so this no longer be a problem.
> thanks,
> nandana
> 
> [1] - http://issues.apache.org/jira/browse/RAMPART-197
> 
> On Wed, Oct 15, 2008 at 12:21 PM, Taariq Levack
> <[EMAIL PROTECTED]>wrote:
> 
>> In my case it still says mustUnderstand=1, but it tolerates the empty
>> header which 1.4 does not.
>>
>> -Original Message-
>> From: RonnieMJ [mailto:[EMAIL PROTECTED]
>> Sent: 15 October 2008 01:30
>> To: axis-user@ws.apache.org
>> Subject: RE: Rampart 1.4 mustUnderstand
>>
>>
>> I switched back to axis 1.3 with rampart 1.3.  Still getting
>> mustUnderstand=1.  I see others with the issue when using their own
>> axis2.xml, but I'm using the default axis2.xml that comes with axis.  I
>> simply load the client policy (attached).  Is it something in my policy
>> that
>> causes mustUnderstand=1?  I wouldn't think so.
>>
>>
>>
>> Taariq Levack wrote:
>> >
>> > Had the same issue recently, the security header coming back from the
>> > service was empty in my case.
>> >
>> > For now I'm using 1.3 until the issue I raised is resolved.
>> > Try the same code with Axis 1.3 and Rampart 1.3 and see if that works
>> > for you.
>> >
>> > Taariq
>> >
>> > -Original Message-
>> > From: RonnieMJ [mailto:[EMAIL PROTECTED]
>> > Sent: 10 October 2008 23:32
>> > To: axis-user@ws.apache.org
>> > Subject: Rampart 1.4 mustUnderstand
>> >
>> >
>> > Does rampart version 1.4 default mustUnderstand to 1?  I'm getting the
>> > famous
>> > error, and am using a policy to set my configurations in code (client
>> > side
>> > ONLY).
>> >
>> > My wsse:security tag ends up as mustunderstand="1".
>> > > >
>> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wsse
>> > curity-secext-1.0.xsd"
>> > soapenv:mustUnderstand="1">
>> >
>> > The security isn't set in the WSDL.  I am using axis2 1.4.1.
>> >
>> > I've seen the WSDL2Constants flag, but I'm not using WSDL2Constants.
>> >
>> > Just the plain old:
>> >
>> > options.setProperty(RampartMessageData.KEY_RAMPART_POLICY,
>> > loadPolicy(confDir + "/clientSecurityPolicy.xml"));
>> >
>> > stub._getServiceClient().setOptions(options);
>> >
>> >
>> > stub._getServiceClient().engageModule("rampart");
>> >
>> >
>> > I also don't have access to or control over what is used on the
>> service
>> > side
>> > (external).
>> >
>> > --
>> > View this message in context:
>> >
>> http://www.nabble.com/Rampart-1.4-mus

Rampart and Actor

[RonnieMJ]

Does rampart (1.4 or 1.3) support the use of specifying an actor?  I notice
this  http://issues.apache.org/jira/browse/RAMPART-16 JIRA  but it's pretty
old.

Basically I've found out that my mustUnderstand issue is due to the ultimate
receiver not being able to handle security headers, and rampart puts
mustUnderstand="1" in the Security header.  It initially goes through the
first endpoint correctly.
-- 
View this message in context: 
http://www.nabble.com/Rampart-and-Actor-tp20016173p20016173.html
Sent from the Axis - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Rampart 1.4 mustUnderstand

[RonnieMJ]

The Oasis 1.0 specification states:
All compliant implementations MUST declare which profiles they support and
MUST be able to
process a  element including any sub-elements which may be
defined by that profile.

but it then says:
When a  header includes a mustUnderstand="true" attribute:...

The first would make me think that you HAD to have mustUnderstand="true" in
the Security header.  The latter would make me think that it's optional...




RonnieMJ wrote:
> 
> Does rampart version 1.4 default mustUnderstand to 1?  I'm getting the
> famous error, and am using a policy to set my configurations in code
> (client side ONLY).
> 
> My wsse:security tag ends up as mustunderstand="1".
>  xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";
> soapenv:mustUnderstand="1">
> 
> The security isn't set in the WSDL.  I am using axis2 1.4.1.
> 
> I've seen the WSDL2Constants flag, but I'm not using WSDL2Constants.  
> 
> Just the plain old:
> 
> options.setProperty(RampartMessageData.KEY_RAMPART_POLICY, 
> loadPolicy(confDir + "/clientSecurityPolicy.xml"));
>   stub._getServiceClient().setOptions(options);
> 
> 
> stub._getServiceClient().engageModule("rampart");
> 
> 
> I also don't have access to or control over what is used on the service
> side (external).
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Rampart-1.4-mustUnderstand-tp19926442p20014731.html
Sent from the Axis - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Rampart and WSS 1.0 DRAFT

[RonnieMJ]

Is there any way to use the WSS 1.0 Draft specification with rampart (pre
Oasis - http://schemas.xmlsoap.org/ws/2002/07/secext)?   I realize that one
wouldn't WANT to do this, but I'm wondering if it's possible.  
-- 
View this message in context: 
http://www.nabble.com/Rampart-and-WSS-1.0-DRAFT-tp19985451p19985451.html
Sent from the Axis - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Rampart 1.4 mustUnderstand

[RonnieMJ]

I switched back to axis 1.3 with rampart 1.3.  Still getting
mustUnderstand=1.  I see others with the issue when using their own
axis2.xml, but I'm using the default axis2.xml that comes with axis.  I
simply load the client policy (attached).  Is it something in my policy that
causes mustUnderstand=1?  I wouldn't think so.



Taariq Levack wrote:
> 
> Had the same issue recently, the security header coming back from the
> service was empty in my case.
> 
> For now I'm using 1.3 until the issue I raised is resolved.
> Try the same code with Axis 1.3 and Rampart 1.3 and see if that works
> for you.
> 
> Taariq
> 
> -Original Message-
> From: RonnieMJ [mailto:[EMAIL PROTECTED] 
> Sent: 10 October 2008 23:32
> To: axis-user@ws.apache.org
> Subject: Rampart 1.4 mustUnderstand
> 
> 
> Does rampart version 1.4 default mustUnderstand to 1?  I'm getting the
> famous
> error, and am using a policy to set my configurations in code (client
> side
> ONLY).
> 
> My wsse:security tag ends up as mustunderstand="1".
>  xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wsse
> curity-secext-1.0.xsd"
> soapenv:mustUnderstand="1">
> 
> The security isn't set in the WSDL.  I am using axis2 1.4.1.
> 
> I've seen the WSDL2Constants flag, but I'm not using WSDL2Constants.  
> 
> Just the plain old:
> 
> options.setProperty(RampartMessageData.KEY_RAMPART_POLICY, 
> loadPolicy(confDir + "/clientSecurityPolicy.xml"));
>   
> stub._getServiceClient().setOptions(options);
> 
> 
> stub._getServiceClient().engageModule("rampart");
> 
> 
> I also don't have access to or control over what is used on the service
> side
> (external).
> 
> -- 
> View this message in context:
> http://www.nabble.com/Rampart-1.4-mustUnderstand-tp19926442p19926442.htm
> l
> Sent from the Axis - User mailing list archive at Nabble.com.
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 
http://www.nabble.com/file/p19984135/clientSecurityPolicyExternal.xml
clientSecurityPolicyExternal.xml 
-- 
View this message in context: 
http://www.nabble.com/Rampart-1.4-mustUnderstand-tp19926442p19984135.html
Sent from the Axis - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Rampart 1.4 mustUnderstand

[RonnieMJ]

Does rampart version 1.4 default mustUnderstand to 1?  I'm getting the famous
error, and am using a policy to set my configurations in code (client side
ONLY).

My wsse:security tag ends up as mustunderstand="1".
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";
soapenv:mustUnderstand="1">

The security isn't set in the WSDL.  I am using axis2 1.4.1.

I've seen the WSDL2Constants flag, but I'm not using WSDL2Constants.  

Just the plain old:

options.setProperty(RampartMessageData.KEY_RAMPART_POLICY, 
loadPolicy(confDir + "/clientSecurityPolicy.xml"));
stub._getServiceClient().setOptions(options);


stub._getServiceClient().engageModule("rampart");


I also don't have access to or control over what is used on the service side
(external).

-- 
View this message in context: 
http://www.nabble.com/Rampart-1.4-mustUnderstand-tp19926442p19926442.html
Sent from the Axis - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Rampart Username and signed certificate

[RonnieMJ]

I finally figured it out.  I needed to use TransportBinding with an Endorsing
Supporting token of an X509 certificate and a SignedSupportingToken of the
username.  I didn't realize that it didn't need Asymmetric binding.



RonnieMJ wrote:
> 
> Ok the vendor has gotten back to me indicating that they don't see the
> password.  Funny, I don't quite see it either.  I've tried setting
> passwordType, but it doesn't seem to do it (although it's deprecated on
> 1.4, which I'm using).  
> 
> I do see this in my own logs:
> 
> 2008-10-08 14:09:47,014 [Timer-0   ] DEBUG EnvelopeIdResolver -
> enter engineResolve, look for: #UsernameToken-30587319
> 2008-10-08 14:09:47,015 [Timer-0   ] DEBUG StAXUtils  -
> XMLStreamWriter is com.sun.xml.internal.stream.writers.XMLStreamWriterImpl
> 2008-10-08 14:09:47,019 [Timer-0   ] DEBUG EnvelopeIdResolver -
> exit engineResolve, result: XMLSignatureInput/Element/ xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
> wsu:Id="UsernameToken-30587319">
>   userNameWasHere
>Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText";>passwordWasHere
>  exclude null comments:false/null
> 2008-10-08 14:09:47,020 [Timer-0   ] DEBUG ElementProxy   -
> setElement("ds:Transform", "null")
> 
> 
> But I don't see it anything like that in the message.  The username is
> encrypted (guessing)?
> IF the digestValue is the username:
> 
>   
>Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#";>
>   
>    Algorithm="http://www.w3.org/2000/09/xmldsig#sha1";>
>   
> T2XSh+9LCbwfDzbPzw=
>   
> 
> I don't see the password...
> 
> 
> 
> 
> 
> RonnieMJ wrote:
>> 
>> It worked with SignedSupportingTokens or just SupportingTokens?  Mine
>> works fine with SignedSupportingTokens, our end service just won't take
>> it.
>> 
>> 
>> 
>> Mary Thompson wrote:
>>> 
>>> Nandana,
>>>Your example works correctly in my tomcat/axis environment. Now I 
>>> just have to figure out why mine doesn't.  Maybe  there is something 
>>> missing in our service skeleton class.
>>> 
>>> Mary
>>> 
>>> Nandana Mihindukulasooriya wrote:
>>>> Hi,
>>>> 
>>>> I've tried it with SignedSupportingTokens (or even just
>>>> SupportingTokens)
>>>> below the binding (as a top level) a few times.  It ends up making
>>>> the token
>>>> still embedded and encrypted (not a plain old Username token). 
>>>> 
>>>> 
>>>> Yes, when a username token is used as supporting token with symmetric 
>>>> binding or an asymmetric binding it is encrypted due security 
>>>> considerations. You can't control this using policy. If we want to 
>>>> control this we might need to introduce a custom flag in to Rampart 
>>>> configuration.
>>>> 
>>>>  Using just
>>>> "SupportingTokens" (without the Signed) removes it entirely. 
>>>> 
>>>> 
>>>> This should be a bug if it removes it completely. Please create a JIRA 
>>>> for this under Apache Rampart [1]. 
>>>>  
>>>> 
>>>> Here's my most recent message:
>>>> 
>>>> 
>>>> Was this most recent message a successful one ? In that message, it 
>>>> seems the Username Token is encrypted.
>>>> 
>>>> thanks,
>>>> nandana
>>>> 
>>>> [1] - http://issues.apache.org/jira/browse/Rampart
>>>> 
>>>>  
>>>> 
>>>> On Tue, Oct 7, 2008 at 9:34 AM, keith chapman
>>>> <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>wrote:
>>>> 
>>>>  >
>>>>  >
>>>>  > On Tue, Oct 7, 2008 at 8:50 AM, Samisa Abeysinghe <
>>>>  > [EMAIL PROTECTED]
>>>> <mailto:[EMAIL PROTECTED]>>
>>>> wrote:
>>>&

WSSecurityPolicy ID values

[RonnieMJ]

Does the wsu:ID tag of a Policy file have any specific meaning?  I didn't
think that it did, but just want to make sure.  I have yet to find a place
that has a bunch of possible values, and the ID tag is usually just a
reference type tag.

Thanks.
-- 
View this message in context: 
http://www.nabble.com/WSSecurityPolicy-ID-values-tp19900669p19900669.html
Sent from the Axis - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Rampart Username and signed certificate

[RonnieMJ]

Shouldn't the password be viewable?  I put it in as passwordText (although
I'm not sure this should work with 1.4), but it doesn't show.  I'm guessing
the digest value is the username (encrypted).  See other post for full XML.



Nunny wrote:
> 
> Hi,
> 
> I've tried it with SignedSupportingTokens (or even just SupportingTokens)
>> below the binding (as a top level) a few times.  It ends up making the
>> token
>> still embedded and encrypted (not a plain old Username token).
> 
> 
> Yes, when a username token is used as supporting token with symmetric
> binding or an asymmetric binding it is encrypted due security
> considerations. You can't control this using policy. If we want to control
> this we might need to introduce a custom flag in to Rampart configuration.
> 
>  Using just
>> "SupportingTokens" (without the Signed) removes it entirely.
> 
> 
> This should be a bug if it removes it completely. Please create a JIRA for
> this under Apache Rampart [1].
> 
> 
>> Here's my most recent message:
> 
> 
> Was this most recent message a successful one ? In that message, it seems
> the Username Token is encrypted.
> 
> thanks,
> nandana
> 
> [1] - http://issues.apache.org/jira/browse/Rampart
> 
> 
> 
>> On Tue, Oct 7, 2008 at 9:34 AM, keith chapman
>> <[EMAIL PROTECTED]>wrote:
>>
>> >
>> >
>> > On Tue, Oct 7, 2008 at 8:50 AM, Samisa Abeysinghe <
>> > [EMAIL PROTECTED]> wrote:
>> >
>> >> Nandana Mihindukulasooriya wrote:
>> >>
>> >>> Hi Ronnie,
>> >>>   Please change the policy as given below.
>> >>>
>> >>
>> >> But should not this policy come from the service?
>> >
>> > Ideally yes. ;)
>> >
>>
>> I just assumed that the service doesn't have a policy and security
>> requirements are published out of band.
>>
>> " I know that I need to send both a usernameToken and sign the header
>> with
>> a
>> certificate. I'm fairly sure I've just got the policy file slightly off.
>>  Any suggestions ? "
>>
>> But if the WSDL publishes the security requirements via policy, there is
>> no
>> need for us to manually create policies and attach them. If you are using
>> the Axis2 cord generator, it will do this for you. Please take a look at
>> this tutorial [1].
>>
>> thanks,
>> nandana
>>
>> [1] - http://wso2.org/library/3415
>>
>> Samisa...
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Rampart-Username-and-signed-certificate-tp19843845p19859682.html
>> Sent from the Axis - User mailing list archive at Nabble.com.
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
> 
> 
> -- 
> Nandana Mihindukulasooriya
> WSO2 inc.
> 
> http://nandana83.blogspot.com/
> http://www.wso2.org
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Rampart-Username-and-signed-certificate-tp19843845p19899774.html
Sent from the Axis - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Rampart Username and signed certificate

[RonnieMJ]

Ok the vendor has gotten back to me indicating that they don't see the
password.  Funny, I don't quite see it either.  I've tried setting
passwordType, but it doesn't seem to do it (although it's deprecated on 1.4,
which I'm using).  

I do see this in my own logs:

2008-10-08 14:09:47,014 [Timer-0   ] DEBUG EnvelopeIdResolver -
enter engineResolve, look for: #UsernameToken-30587319
2008-10-08 14:09:47,015 [Timer-0   ] DEBUG StAXUtils  -
XMLStreamWriter is com.sun.xml.internal.stream.writers.XMLStreamWriterImpl
2008-10-08 14:09:47,019 [Timer-0   ] DEBUG EnvelopeIdResolver - exit
engineResolve, result: XMLSignatureInput/Element/http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
wsu:Id="UsernameToken-30587319">
userNameWasHere
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText";>passwordWasHere
 exclude null comments:false/null
2008-10-08 14:09:47,020 [Timer-0   ] DEBUG ElementProxy   -
setElement("ds:Transform", "null")


But I don't see it anything like that in the message.  The username is
encrypted (guessing)?
IF the digestValue is the username:


http://www.w3.org/2001/10/xml-exc-c14n#";>

http://www.w3.org/2000/09/xmldsig#sha1";>
    
T2XSh+9LCbwfDzbPzw=


I don't see the password...





RonnieMJ wrote:
> 
> It worked with SignedSupportingTokens or just SupportingTokens?  Mine
> works fine with SignedSupportingTokens, our end service just won't take
> it.
> 
> 
> 
> Mary Thompson wrote:
>> 
>> Nandana,
>>Your example works correctly in my tomcat/axis environment. Now I 
>> just have to figure out why mine doesn't.  Maybe  there is something 
>> missing in our service skeleton class.
>> 
>> Mary
>> 
>> Nandana Mihindukulasooriya wrote:
>>> Hi,
>>> 
>>> I've tried it with SignedSupportingTokens (or even just
>>> SupportingTokens)
>>> below the binding (as a top level) a few times.  It ends up making
>>> the token
>>> still embedded and encrypted (not a plain old Username token). 
>>> 
>>> 
>>> Yes, when a username token is used as supporting token with symmetric 
>>> binding or an asymmetric binding it is encrypted due security 
>>> considerations. You can't control this using policy. If we want to 
>>> control this we might need to introduce a custom flag in to Rampart 
>>> configuration.
>>> 
>>>  Using just
>>> "SupportingTokens" (without the Signed) removes it entirely. 
>>> 
>>> 
>>> This should be a bug if it removes it completely. Please create a JIRA 
>>> for this under Apache Rampart [1]. 
>>>  
>>> 
>>> Here's my most recent message:
>>> 
>>> 
>>> Was this most recent message a successful one ? In that message, it 
>>> seems the Username Token is encrypted.
>>> 
>>> thanks,
>>> nandana
>>> 
>>> [1] - http://issues.apache.org/jira/browse/Rampart
>>> 
>>>  
>>> 
>>> On Tue, Oct 7, 2008 at 9:34 AM, keith chapman
>>> <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>wrote:
>>> 
>>>  >
>>>  >
>>>  > On Tue, Oct 7, 2008 at 8:50 AM, Samisa Abeysinghe <
>>>  > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
>>> wrote:
>>>  >
>>>  >> Nandana Mihindukulasooriya wrote:
>>>  >>
>>>  >>> Hi Ronnie,
>>>  >>>   Please change the policy as given below.
>>>  >>>
>>>  >>
>>>  >> But should not this policy come from the service?
>>>  >
>>>  > Ideally yes. ;)
>>>  >
>>> 
>>> I just assumed that the service doesn't have a policy and security
>>> requirements are published out of band.
>>> 
>>> " I know that I need to send both a usernameToken and sign the
>>> header with a
>>> certificate. I

Re: Rampart Username and signed certificate

[RonnieMJ]

Nandana,

I don't think I processed your message fully last night.  You're saying that
it shouldn't matter if you say "SignedSupportingTokens" or
"SupportingTokens" if we're using symmetric or asymmetric binding because it
SHOULD encrypt both?

That would mean that I don't really have the capability to create the
attached header (which is my goal)?



Nunny wrote:
> 
> Hi,
> 
> I've tried it with SignedSupportingTokens (or even just SupportingTokens)
>> below the binding (as a top level) a few times.  It ends up making the
>> token
>> still embedded and encrypted (not a plain old Username token).
> 
> 
> Yes, when a username token is used as supporting token with symmetric
> binding or an asymmetric binding it is encrypted due security
> considerations. You can't control this using policy. If we want to control
> this we might need to introduce a custom flag in to Rampart configuration.
> 
>  Using just
>> "SupportingTokens" (without the Signed) removes it entirely.
> 
> 
> This should be a bug if it removes it completely. Please create a JIRA for
> this under Apache Rampart [1].
> 
> 
>> Here's my most recent message:
> 
> 
> Was this most recent message a successful one ? In that message, it seems
> the Username Token is encrypted.
> 
> thanks,
> nandana
> 
> [1] - http://issues.apache.org/jira/browse/Rampart
> 
> 
> 
>> On Tue, Oct 7, 2008 at 9:34 AM, keith chapman
>> <[EMAIL PROTECTED]>wrote:
>>
>> >
>> >
>> > On Tue, Oct 7, 2008 at 8:50 AM, Samisa Abeysinghe <
>> > [EMAIL PROTECTED]> wrote:
>> >
>> >> Nandana Mihindukulasooriya wrote:
>> >>
>> >>> Hi Ronnie,
>> >>>   Please change the policy as given below.
>> >>>
>> >>
>> >> But should not this policy come from the service?
>> >
>> > Ideally yes. ;)
>> >
>>
>> I just assumed that the service doesn't have a policy and security
>> requirements are published out of band.
>>
>> " I know that I need to send both a usernameToken and sign the header
>> with
>> a
>> certificate. I'm fairly sure I've just got the policy file slightly off.
>>  Any suggestions ? "
>>
>> But if the WSDL publishes the security requirements via policy, there is
>> no
>> need for us to manually create policies and attach them. If you are using
>> the Axis2 cord generator, it will do this for you. Please take a look at
>> this tutorial [1].
>>
>> thanks,
>> nandana
>>
>> [1] - http://wso2.org/library/3415
>>
>> Samisa...
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Rampart-Username-and-signed-certificate-tp19843845p19859682.html
>> Sent from the Axis - User mailing list archive at Nabble.com.
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
> 
> 
> -- 
> Nandana Mihindukulasooriya
> WSO2 inc.
> 
> http://nandana83.blogspot.com/
> http://www.wso2.org
> 
> 
http://www.nabble.com/file/p19879853/exampleHeader.xml exampleHeader.xml 
-- 
View this message in context: 
http://www.nabble.com/Rampart-Username-and-signed-certificate-tp19843845p19879853.html
Sent from the Axis - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Rampart Username and signed certificate

[RonnieMJ]

It worked with SignedSupportingTokens or just SupportingTokens?  Mine works
fine with SignedSupportingTokens, our end service just won't take it.



Mary Thompson wrote:
> 
> Nandana,
>Your example works correctly in my tomcat/axis environment. Now I 
> just have to figure out why mine doesn't.  Maybe  there is something 
> missing in our service skeleton class.
> 
> Mary
> 
> Nandana Mihindukulasooriya wrote:
>> Hi,
>> 
>> I've tried it with SignedSupportingTokens (or even just
>> SupportingTokens)
>> below the binding (as a top level) a few times.  It ends up making
>> the token
>> still embedded and encrypted (not a plain old Username token). 
>> 
>> 
>> Yes, when a username token is used as supporting token with symmetric 
>> binding or an asymmetric binding it is encrypted due security 
>> considerations. You can't control this using policy. If we want to 
>> control this we might need to introduce a custom flag in to Rampart 
>> configuration.
>> 
>>  Using just
>> "SupportingTokens" (without the Signed) removes it entirely. 
>> 
>> 
>> This should be a bug if it removes it completely. Please create a JIRA 
>> for this under Apache Rampart [1]. 
>>  
>> 
>> Here's my most recent message:
>> 
>> 
>> Was this most recent message a successful one ? In that message, it 
>> seems the Username Token is encrypted.
>> 
>> thanks,
>> nandana
>> 
>> [1] - http://issues.apache.org/jira/browse/Rampart
>> 
>>  
>> 
>> On Tue, Oct 7, 2008 at 9:34 AM, keith chapman
>> <[EMAIL PROTECTED] >wrote:
>> 
>>  >
>>  >
>>  > On Tue, Oct 7, 2008 at 8:50 AM, Samisa Abeysinghe <
>>  > [EMAIL PROTECTED] >
>> wrote:
>>  >
>>  >> Nandana Mihindukulasooriya wrote:
>>  >>
>>  >>> Hi Ronnie,
>>  >>>   Please change the policy as given below.
>>  >>>
>>  >>
>>  >> But should not this policy come from the service?
>>  >
>>  > Ideally yes. ;)
>>  >
>> 
>> I just assumed that the service doesn't have a policy and security
>> requirements are published out of band.
>> 
>> " I know that I need to send both a usernameToken and sign the
>> header with a
>> certificate. I'm fairly sure I've just got the policy file slightly
>> off.
>>  Any suggestions ? "
>> 
>> But if the WSDL publishes the security requirements via policy,
>> there is no
>> need for us to manually create policies and attach them. If you are
>> using
>> the Axis2 cord generator, it will do this for you. Please take a look
>> at
>> this tutorial [1].
>> 
>> thanks,
>> nandana
>> 
>> [1] - http://wso2.org/library/3415
>> 
>> Samisa...
>> 
>> --
>> View this message in context:
>>
>> http://www.nabble.com/Rampart-Username-and-signed-certificate-tp19843845p19859682.html
>> Sent from the Axis - User mailing list archive at Nabble.com.
>> 
>> 
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> 
>> For additional commands, e-mail: [EMAIL PROTECTED]
>> 
>> 
>> 
>> 
>> 
>> -- 
>> Nandana Mihindukulasooriya  
>> WSO2 inc.
>> 
>> http://nandana83.blogspot.com/
>> http://www.wso2.org
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Rampart-Username-and-signed-certificate-tp19843845p19879575.html
Sent from the Axis - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Rampart Username and signed certificate

[RonnieMJ]

Thanks Nandana,

No the most recent message wasn't accepted (ASSUMEDLY due to the username
token being encrypted).  I'll check with the other side (other company) to
see if they have more detail as to why it wasn't accepted.



Nunny wrote:
> 
> Hi,
> 
> I've tried it with SignedSupportingTokens (or even just SupportingTokens)
>> below the binding (as a top level) a few times.  It ends up making the
>> token
>> still embedded and encrypted (not a plain old Username token).
> 
> 
> Yes, when a username token is used as supporting token with symmetric
> binding or an asymmetric binding it is encrypted due security
> considerations. You can't control this using policy. If we want to control
> this we might need to introduce a custom flag in to Rampart configuration.
> 
>  Using just
>> "SupportingTokens" (without the Signed) removes it entirely.
> 
> 
> This should be a bug if it removes it completely. Please create a JIRA for
> this under Apache Rampart [1].
> 
> 
>> Here's my most recent message:
> 
> 
> Was this most recent message a successful one ? In that message, it seems
> the Username Token is encrypted.
> 
> thanks,
> nandana
> 
> [1] - http://issues.apache.org/jira/browse/Rampart
> 
> 
> 
>> On Tue, Oct 7, 2008 at 9:34 AM, keith chapman
>> <[EMAIL PROTECTED]>wrote:
>>
>> >
>> >
>> > On Tue, Oct 7, 2008 at 8:50 AM, Samisa Abeysinghe <
>> > [EMAIL PROTECTED]> wrote:
>> >
>> >> Nandana Mihindukulasooriya wrote:
>> >>
>> >>> Hi Ronnie,
>> >>>   Please change the policy as given below.
>> >>>
>> >>
>> >> But should not this policy come from the service?
>> >
>> > Ideally yes. ;)
>> >
>>
>> I just assumed that the service doesn't have a policy and security
>> requirements are published out of band.
>>
>> " I know that I need to send both a usernameToken and sign the header
>> with
>> a
>> certificate. I'm fairly sure I've just got the policy file slightly off.
>>  Any suggestions ? "
>>
>> But if the WSDL publishes the security requirements via policy, there is
>> no
>> need for us to manually create policies and attach them. If you are using
>> the Axis2 cord generator, it will do this for you. Please take a look at
>> this tutorial [1].
>>
>> thanks,
>> nandana
>>
>> [1] - http://wso2.org/library/3415
>>
>> Samisa...
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Rampart-Username-and-signed-certificate-tp19843845p19859682.html
>> Sent from the Axis - User mailing list archive at Nabble.com.
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
> 
> 
> -- 
> Nandana Mihindukulasooriya
> WSO2 inc.
> 
> http://nandana83.blogspot.com/
> http://www.wso2.org
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Rampart-Username-and-signed-certificate-tp19843845p19872561.html
Sent from the Axis - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Rampart Username and signed certificate

[RonnieMJ]

Unfortunately the WSDL does not have ANY security considerations in it.  I
don't have control over that WSDL either.  

I've tried it with SignedSupportingTokens (or even just SupportingTokens)
below the binding (as a top level) a few times.  It ends up making the token
still embedded and encrypted (not a plain old Username token).  Using just
"SupportingTokens" (without the Signed) removes it entirely.  I'm trying to
just put Usernametoken as the original example.  The error I receive from
them is:
soap:Server.75612An error
has occurred authenticating based on Credentials

I am flying a little blind in that the WSDL doesn't indicate what should be
there security wise, but I do have some examples to guide me (examples that
were sent to the service that were successful).
Here's my most recent message:



http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#";>

http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";
soapenv:mustUnderstand="1">

http://www.w3.org/2001/04/xmlenc#rsa-1_5";>
http://www.w3.org/2000/09/xmldsig#";>

http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary";
ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509SubjectKeyIdentifier";>7WzTz2ucSMRogbHUMQuxv7uOMHU=




qRTX199B2f/nYZH072qnHpbNk9CaELavKRFIEC08FeJPBHMxT4MP8TUuBOF07GAbSCmV+x7R3fKKrXFlzsFogEkHMMN5MGIHm703TqgE01N6qXBkNCOgW66lll5lXIOjailqYcA4X+o9dKUL4GbazpXMSZ001zHMcZzDMYtxf/g=





http://www.w3.org/2001/04/xmlenc#Element";>
http://www.w3.org/2001/04/xmlenc#aes128-cbc";>
http://www.w3.org/2000/09/xmldsig#";>






bhhmBf6B2eYvFKBWJWB6MtSo5IKw9z6KwDPV4XKU6UCchMBkNFlWJcSRK+I/h2MhTlLHRpK4cUII
R8DxFshi


http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary";
ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3";
wsu:Id="CertId-18314596">MIIERDCCAm1jXj9w==
http://www.w3.org/2000/09/xmldsig#";
Id="Signature-30702379">

http://www.w3.org/2001/10/xml-exc-c14n#";>
http://www.w3.org/2000/09/xmldsig#rsa-sha1";>


http://www.w3.org/2001/10/xml-exc-c14n#";>

http://www.w3.org/2000/09/xmldsig#sha1";>

jwNsqR/y1GbSLbp/B8a9GCXLVLw=



http://www.w3.org/2001/10/xml-exc-c14n#";>

http://www.w3.org/2000/09/xmldsig#sha1";>

NyG+Wk5lnuvnO23ZYsfWeJFZWCY=




ZJj1RorLDpEmZ8CHi8xaAuyt3XEo16ZZmUkylPJS4rWA71WpFPenuzfr+KfIFTW0Nlnwlo3lQh31
pzYDi4ydyVXJAt24c6s=


http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
wsu:Id="STRId-3841429">
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3";>





http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility

Re: Rampart Username and signed certificate

[RonnieMJ]

I don't actually get an exception (well I do get a soap fault for not having
all of the right headers from their server).

The message usually gets sent out simply without the username token.  If I
DO get the username token to go, it's as a signedsupportingtoken (which is
not what they want).



Samisa Abeysinghe-2 wrote:
> 
> What is the exception that you get?
> 
> Samisa...
> 
> RonnieMJ wrote:
>> I'm pretty new to WS, and especially the security piece, but I'm using
>> rampart 1.4 using policy files to try to function as a client to an
>> existing
>> (external to my company) web service.
>>
>> I know that I need to send both a usernameToken and sign the header with
>> a
>> certificate.  I've been able to do EITHER, but so far haven't been able
>> to
>> do both.
>>
>> I've tried it about 20 different ways, but my most recent attempt is:
>>
>>
>> > 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/2004/09/policy";>
>>  
>>  > xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy";>
>>  
>>  
>>  
>>  > sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient";>
>>  
>>  
>> 
>>  
>>  
>>  
>>  
>>  
>>  
>>  > sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Never";>
>>  
>>  
>> 
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>>  > sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient";
>> />
>>  
>>  
>>  
>>  
>>
>>
>>  > xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy";>
>>  
>>  
>>  
>>  
>>  
>>
>>
>>  > xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy";>
>>  
>>  
>>
>>  > xmlns:ramp="http://ws.apache.org/rampart/policy";>
>>  user
>>  user
>>  
>> com.xo.vzn_asr.business.util.PWCBHandler
>>
>>  
>>  > provider="org.apache.ws.security.components.crypto.Merlin">
>>  > name="org.apache.ws.security.crypto.merlin.keystore.type">jks
>>  > name="org.apache.ws.security.crypto.merlin.file">client.jks
>>  > name="org.apache.ws.security.crypto.merlin.keystore.alias">user
>>  > name="org.apache.ws.security.crypto.merlin.keystore.password">keypassword
>>  
>>  
>>  
>>
>>  
>> 
>>
>>
>>

Rampart Username and signed certificate

[RonnieMJ]

I'm pretty new to WS, and especially the security piece, but I'm using
rampart 1.4 using policy files to try to function as a client to an existing
(external to my company) web service.

I know that I need to send both a usernameToken and sign the header with a
certificate.  I've been able to do EITHER, but so far haven't been able to
do both.

I've tried it about 20 different ways, but my most recent attempt is:


http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy";>

http://schemas.xmlsoap.org/ws/2005/07/securitypolicy";>



http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient";>









http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Never";>




















http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient";
/>






http://schemas.xmlsoap.org/ws/2005/07/securitypolicy";>







http://schemas.xmlsoap.org/ws/2005/07/securitypolicy";>



http://ws.apache.org/rampart/policy";>
user
user

com.xo.vzn_asr.business.util.PWCBHandler



jks
client.jks
user
keypassword









I expect the final header output to be something like:



XXX

binaryTokenHere


http://www.w3.org/2001/10/xml-exc-c14n#"/>
http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>









http://www.w3.org/2001/10/xml-exc-c14n#"/>

http://www.w3.org/2000/09/xmldsig#sha1"/>














I'm fairly sure I've just got the policy file slightly off.  Any
suggestions?  Thanks for any reply.
-- 
View this message in context: 
http://www.nabble.com/Rampart-Username-and-signed-certificate-tp19843845p19843845.html
Sent from the Axis - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]