You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rampart-dev@ws.apache.org by Nandana Mihindukulasooriya <na...@gmail.com> on 2009/05/06 11:16:34 UTC
Re: Having client send certificate to server for encryption without
signing
Hi Dennis,
If IncludeToken attribute is set to "AlwaysToRecipient" and if it
is referred from the message, it is added to the security header as a binary
token. But in the case of encryption only scenario, the clients certificate
in not referred within the SOAP message so it is not attached to the
security header. I will go through the spec again to makesure that this is
the correct behavior.
regards,
Nandana
On Thu, Apr 23, 2009 at 5:49 PM, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> Is it possible to have a Rampart client send its certificate to the server
> as part of a request when signing is not used? I'd like to be able to use
> encryption without signing, but that requires the client to send its
> certificate.
>
> From reading WS-SecurityPolicy 1.2, I thought this should force the client
> to send its certificate on every request:
>
> <sp:InitiatorToken>
> <wsp:Policy>
> <sp:X509Token sp:IncludeToken="
> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient
> "/>
> </wsp:Policy>
> </sp:InitiatorToken>
>
> but it appears to be ignored by Rampart unless signing is used. Am I
> misinterpreting WS-SP, or is this an error in Rampart?
>
> - Dennis
>
> --
> Dennis M. Sosnoski
> SOA and Web Services in Java
> Axis2 Training and Consulting
> http://www.sosnoski.com - http://www.sosnoski.co.nz
> Seattle, WA +1-425-939-0576 - Wellington, NZ +64-4-298-6117
>
>
--
Nandana Mihindukulasooriya
WSO2 inc.
http://nandana83.blogspot.com/
http://www.wso2.org
Re: Having client send certificate to server for encryption without
signing
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
Hi Nandana,
The wording of the specification would seem to indicate (at least by my
reading) that the token should be sent:
/5.1.1 Token Inclusion Values
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient
The token MUST be included in all messages sent from initiator to the
recipient. The token MUST NOT be included in messages sent from the
recipient to the initiator./
I don't see any references that say this only applies when the token is
considered necessary by the initiator. I don't know how other frameworks
interpret this, though, and the lack of good examples for WS-SP makes it
difficult to say for certain how this is supposed to work.
- Dennis
Nandana Mihindukulasooriya wrote:
> Hi Dennis,
> If IncludeToken attribute is set to "AlwaysToRecipient" and if it
> is referred from the message, it is added to the security header as a binary
> token. But in the case of encryption only scenario, the clients certificate
> in not referred within the SOAP message so it is not attached to the
> security header. I will go through the spec again to makesure that this is
> the correct behavior.
>
> regards,
> Nandana
>
> On Thu, Apr 23, 2009 at 5:49 PM, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>
>
>> Is it possible to have a Rampart client send its certificate to the server
>> as part of a request when signing is not used? I'd like to be able to use
>> encryption without signing, but that requires the client to send its
>> certificate.
>>
>> From reading WS-SecurityPolicy 1.2, I thought this should force the client
>> to send its certificate on every request:
>>
>> <sp:InitiatorToken>
>> <wsp:Policy>
>> <sp:X509Token sp:IncludeToken="
>> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient
>> "/>
>> </wsp:Policy>
>> </sp:InitiatorToken>
>>
>> but it appears to be ignored by Rampart unless signing is used. Am I
>> misinterpreting WS-SP, or is this an error in Rampart?
>>
>> - Dennis
>>
>> --
>> Dennis M. Sosnoski
>> SOA and Web Services in Java
>> Axis2 Training and Consulting
>> http://www.sosnoski.com - http://www.sosnoski.co.nz
>> Seattle, WA +1-425-939-0576 - Wellington, NZ +64-4-298-6117
>>
>>
>>
>
>
>