You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fx-dev@ws.apache.org by Dimuthu Leelarathne <mu...@opensource.lk> on 2004/11/01 04:17:11 UTC
RE: signing with DerivedKey based on UsernameToken - data for alg.
test
Hi Brian,
If you want to sign using the password assoiciated with the Username token
what you have to use is HMAC-SHA1 signature. Which is basically a hash
function. The standard is if you want to sign a SOAP message using a
symmetric key (eg. Password or any shared secret) then you have to use
HMAC-SHA1 signature. As I undersatand this is what I think you want to do.
The implementation is available at
org.apache.ws.security.conversation.ConversationManager.java
The method signature is::
public Document build(Document doc, Reference ref, byte[] sk, Vector parts)
throws WSSecurityException {
If you want to sign using derived keys then you have to start secure
conversation between two parties. Then it is a different story.
> What I've found about the signature with derived key: there are about
> three
> different descriptions about how to do it. Some say WSE uses 16 bytes as
> key
> material,others say 24 bytes, one say the key includes the creation time,
> some indicate that it is without the creation time.
You can read all about derived keys in WS-Secure Conversation
specification. Derivedkeys can have any no of key material bytes - the
point is the communication parties should agree first, according to
WS-Policy specification.
Currently available implemenatation at WSS4J doesn't support code to start
WS-Secure Converation using Username tokens. However we have made
provisions enable it.
Regards,
Dimuthu
--
Lanka Software Foundation http://www.opensource.lk
> Hey Werner,
>
> It sure isn't easy but hopefully were soon done and let's hope we will end
> op with a clear understanding that others can benefit from as well -
> should
> it be that my problem actually was something else :-)
>
> I've attached the text-file i got from the .NET developer, that he made
> with
> his MS trace tool. I'm sort of surprised that whitespaces can change the
> signature, i thought that canonical XML took care of that, sorry to find
> my
> knowledge so incomplete, but luckily it isn't me doing the coding here!
>
>
> Brgds Brian
>
>
> -----Original Message-----
> From: Werner Dittmann [mailto:Werner.Dittmann@t-online.de]
> Sent: Saturday, October 30, 2004 2:55 PM
> To: brian@www.sweetxml.org
> Cc: fx-dev@ws.apache.org
> Subject: Re: signing with DerivedKey based on UsernameToken - data for
> alg.
> test
>
>
> Brian,
>
> What I've found about the signature with derived key: there are about
> three
> different descriptions about how to do it. Some say WSE uses 16 bytes as
> key
> material,others say 24 bytes, one say the key includes the creation time,
> some indicate that it is without the creation time. Using the test program
> I
> can cycle through various options to check the signature.
>
> I've set up a test programm and checked several things. Unfortunatly I
> can't
> do all checks because the XML request was "pretty printed", i.e. contains
> blanks and tabs to format the output. This pretty printing prevents a
> signature check. Can you try to get such a request as a non-pretty printed
> version?
>
> Regards,
> Werner
>
> brian@www.sweetxml.org wrote:
>> Hey Werner
>>
>> I havn't had time to do any testing, but a had a guy doing a .NET
>> request without encryption son that we have data to check the algorithm:
> <wsse:UsernameToken
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurit
> y-utility-1.0.xsd"
> wsu:Id="SecurityToken-fc43cebf-ae98-4796-a099-026e4385c96b">
>> <wsse:Username>DOM\myname</wsse:Username>
>> <wsse:Password
> Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token
> -profile-1.0#PasswordText">mypass</wsse:Password>
>>
> <wsse:Nonce>EESnwJLAxbN+1ewmFjS7vw==</wsse:Nonce>
>>
> <wsu:Created>2004-10-27T07:53:08Z</wsu:Created>
>> </wsse:UsernameToken>
>>
>> <SignatureValue>T3uwLUIaZNWqTcvH0stfkt8CQ4g=</SignatureValue>
>>
>>
>> I've attached the complete request.
>>
>>
>> /Brian
>>
>>
>>
>> On Wed, Oct 27, 2004 at 09:28:35AM +0200, Dittmann Werner wrote:
>>
>>>Brian,
>>>
>>>do you use the WSE TP or WSE SP1? hervewy's blog says that WSE TP
>>>(technical preview) may have (or has) a bug that it uses the
>>>WS-Security label as ASCII, not as UTF-8. Our code uses UTF-8. IMHO it
>>>should not make a difference because the label uses ASCII codes only
>>>(not sure though...need to check it out somehow).
>>>
>>>In addition, hervewy's blog says that they use only 16 bytes of the
>>>hash as key material. Our P_Hash now produces 128 Bytes of key
>>>material (according to RFC for TLS). IMO this needs to be adjusted.
>>>I'll try to get more info about the algo an how it is applied by WSE.
>>>
>>>Regards,
>>>Werner
>>>
>>>
>>>>-----Ursprüngliche Nachricht-----
>>>>Von: brian@sweetxml.org [mailto:brian@sweetxml.org]
>>>>Gesendet: Mittwoch, 27. Oktober 2004 10:00
>>>>An: fx-dev@ws.apache.org
>>>>Betreff: RE: signing with DerivedKey based on UsernameToken
>>>>
>>>>
>>>>Werner,
>>>>
>>>>Thanks for keeping going :-) Here are a small catch up from
>>>>yesterday, but unfortunately still no break though, it's the
>>>>same exception as before:
>>>>
>>>>1) Namespace af Addressing. You are right that there was a
>>>>mismatch, thanks for pointing it out. I've looked into it and
>>>>the reason seems to be, that the addressing implemtation has
>>>>updated the namespace recently, and I have not had the time
>>>>to follow the spec. I had pasted that part of min client
>>>>deployer from another interop test, where it worked with WSE,
>>>>and looking back into the succesfull reqeust from a .NET WSE
>>>>client, I've confirmed that it's the
>>>>
>>>>xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"
>>>>
>>>>that WSE uses.
>>>>
>>>>2) Label. Sorry for the stupid question, I finally got the
>>>>curage to look into the code, and was surprised with how easy
>>>>it was to read/understand - well done!
>>>>
>>>>3) algorithm. From my level of understanding it looks
>>>>allright, the only resource that might have som new info is this:
>>>>http://www.eggheadcafe.com/ng/microsoft.public.dotnet.framewor
>>>
>>>k.webservices.enhancements/post105194.asp
>>>That describes the changes to the implementation in WSE from the TP to
>>>SP1. Today I'll try to get on of the .NET guys produce a request thats
>>>not encrypted, so we can have a direct check of algoritm, and it may
>>>turn out that it's some other thing thats bugging me.
>>>
>>>
>>>Brgds
>>>Brian
>>>
>>>
>>>
>>>
>>>
>>>
>>>Brian,
>>>
>>>the first error (Element not found) is because the signatureParts
>>>specify a wrong element name or namespace. I checked with the XML
>>>request you sent sometime ago and found that you specified a wrong
>>>namespace in signatureParts. The namespace should be
>>>http://schemas.xmlsoap.org/ws/2004/08/addressing
>>>
>>>and not
>>>
>>>http://schemas.xmlsoap.org/ws/2004/03/addressing
>>>
>>>For the second error I'll try to get some more info about
>>>the algorithms etc.
>>>
>>>Regards,
>>>Werner
>>>
>>>
>>>----------------------------------------------------------------------
>>>--
>>>
>>><?xml version="1.0" encoding="utf-8"?>
>>><soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecuri
> ty-secext-1.0.xsd"
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurit
> y-utility-1.0.xsd">
>>> <soap:Header>
>>> <wsa:Action
> wsu:Id="Id-8b02b27b-c25a-459a-a4df-a844b480147b">http://isb.oio.dk/oioservic
> e/service/public/2/GetDocumentByUrl</wsa:Action>
>>> <wsa:MessageID
> wsu:Id="Id-d9abd0e7-b2f7-43a6-913c-af97dd3dd681">uuid:e64aee56-d6f8-4960-93d
> 3-486818e60a43</wsa:MessageID>
>>> <wsa:ReplyTo
> wsu:Id="Id-a7a5ce82-b991-4d76-a6f9-ba51f3bde3ba">
>>>
> <wsa:Address>http://schemas.xmlsoap.org/ws/2004/03/addressing/role/anonymous
> </wsa:Address>
>>> </wsa:ReplyTo>
>>> <wsa:To
> wsu:Id="Id-7a148a95-bf4f-418e-b346-34f1850a747a">http://isb.oio.dk/oioservic
> e/service/public/2/documentmanager.asmx</wsa:To>
>>> <wsse:Security soap:mustUnderstand="1">
>>> <wsu:Timestamp
> wsu:Id="Timestamp-83a4dbaa-34ff-4640-855c-0d0c97fc5143">
>>>
> <wsu:Created>2004-10-27T07:53:08Z</wsu:Created>
>>>
> <wsu:Expires>2004-10-27T07:58:08Z</wsu:Expires>
>>> </wsu:Timestamp>
>>> <wsse:UsernameToken
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurit
> y-utility-1.0.xsd"
> wsu:Id="SecurityToken-fc43cebf-ae98-4796-a099-026e4385c96b">
>>> <wsse:Username>DOM\myname</wsse:Username>
>>> <wsse:Password
> Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token
> -profile-1.0#PasswordText">mypass</wsse:Password>
>>>
> <wsse:Nonce>EESnwJLAxbN+1ewmFjS7vw==</wsse:Nonce>
>>>
> <wsu:Created>2004-10-27T07:53:08Z</wsu:Created>
>>> </wsse:UsernameToken>
>>> <Signature
> xmlns="http://www.w3.org/2000/09/xmldsig#">
>>> <SignedInfo>
>>> <CanonicalizationMethod
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
>>> <SignatureMethod
> Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>
>>> <Reference
> URI="#Id-8b02b27b-c25a-459a-a4df-a844b480147b">
>>> <Transforms>
>>> <Transform
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
>>> </Transforms>
>>> <DigestMethod
> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>>>
> <DigestValue>5f/DlekD21FRY8CPIbhVUI4WlUU=</DigestValue>
>>> </Reference>
>>> <Reference
> URI="#Id-d9abd0e7-b2f7-43a6-913c-af97dd3dd681">
>>> <Transforms>
>>> <Transform
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
>>> </Transforms>
>>> <DigestMethod
> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>>>
> <DigestValue>pmcAyJ0DsGlZg6YG0oEIL/hiegA=</DigestValue>
>>> </Reference>
>>> <Reference
> URI="#Id-a7a5ce82-b991-4d76-a6f9-ba51f3bde3ba">
>>> <Transforms>
>>> <Transform
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
>>> </Transforms>
>>> <DigestMethod
> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>>>
> <DigestValue>AWMEowRtbhkxnytKxHISG5rKJZU=</DigestValue>
>>> </Reference>
>>> <Reference
> URI="#Id-7a148a95-bf4f-418e-b346-34f1850a747a">
>>> <Transforms>
>>> <Transform
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
>>> </Transforms>
>>> <DigestMethod
> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>>>
> <DigestValue>kCnWkPvg6kHs9iqqPmsppQnZtjQ=</DigestValue>
>>> </Reference>
>>> <Reference
> URI="#Timestamp-83a4dbaa-34ff-4640-855c-0d0c97fc5143">
>>> <Transforms>
>>> <Transform
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
>>> </Transforms>
>>> <DigestMethod
> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>>>
> <DigestValue>sAVzaMAg0UTonyJeqidnDZf0hso=</DigestValue>
>>> </Reference>
>>> <Reference
> URI="#Id-f063763f-6e9d-4682-a024-0546c28581d8">
>>> <Transforms>
>>> <Transform
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
>>> </Transforms>
>>> <DigestMethod
> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>>>
> <DigestValue>BtjdaiUHt96rdwH0WyeYhYrvCMY=</DigestValue>
>>> </Reference>
>>> </SignedInfo>
>>>
> <SignatureValue>T3uwLUIaZNWqTcvH0stfkt8CQ4g=</SignatureValue>
>>> <KeyInfo>
>>> <wsse:SecurityTokenReference>
>>> <wsse:Reference
> URI="#SecurityToken-fc43cebf-ae98-4796-a099-026e4385c96b"
> ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-
> token-profile-1.0#UsernameToken"/>
>>> </wsse:SecurityTokenReference>
>>> </KeyInfo>
>>> </Signature>
>>> </wsse:Security>
>>> </soap:Header>
>>> <soap:Body wsu:Id="Id-f063763f-6e9d-4682-a024-0546c28581d8">
>>> <DocumentUrl
> xmlns="http://isb.oio.dk/oioservice/service/DocumentManager/">http://rep.oio
> .dk/accul/ultest.xsd</DocumentUrl>
>>> </soap:Body>
>>></soap:Envelope>
>>>
>