You are viewing a plain text version of this content. The canonical link for it is here.
Posted to wss4j-dev@ws.apache.org by Glen Mazza <gl...@gmail.com> on 2008/06/23 00:08:14 UTC
Using UsernameTokens--also need to sign the SOAP message?
Hello, I have an architectural question about using UsernameTokens (which I'm
trying to do with CXF, which of course uses WSS4J behind the scenes). If we
are using the UsernameToken profile, I can see why we need to encrypt the
message with the server's public key (for confidentiality), but am unsure if
we need to also sign the message with the client's private key. Is it
redundant with UsernameToken profile to also sign the SOAP request? My
first guess, is that by definition, one is using Usernames and Passwords for
authentication, and hence would not need signing of the message as well, but
am unsure here.
Thanks,
Glen
--
View this message in context: http://www.nabble.com/Using-UsernameTokens--also-need-to-sign-the-SOAP-message--tp18059742p18059742.html
Sent from the WSS4J mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: Using UsernameTokens--also need to sign the SOAP message?
Posted by José Ferreiro <jo...@gmail.com>.
Santosh,
This is a follow up to Werner.
Look carefully at the example Client_deploy.wssd.
wss4j-bin-1.5.X\wss4j\interop\org\apache\ws\axis\oasis\Client_deploy.wsdd
Hope this helps.
Jose Ferreiro
On 7/21/08, Dittmann, Werner (NSN - DE/Muenich) <we...@nsn.com>
wrote:
>
> Santosh,
>
> looking at the word '9e141676-2400-4c6d-ab87-1d5af61729b3' :
> this is the usual notation of a UUID as generated by sfotware.
> It doe not mean anything but being a unique id (Universal Unique
> ID). This has nothing to do with password or username.
>
> UsernameToken is the action to use in Axis deployment file, please have
> a look at the interop tests in the according directory of WSS4J.
>
> Regards,
> Werner
>
> > -----Ursprüngliche Nachricht-----
> > Von: ext sh_santosh [mailto:santosh.ncstk@gmail.com]
> > Gesendet: Montag, 21. Juli 2008 06:53
> > An: wss4j-dev@ws.apache.org
> > Betreff: Re: Using UsernameTokens--also need to sign the SOAP message?
> >
> >
> > Hi Werner,
> >
> > What about this word -'9e141676-2400-4c6d-ab87-1d5af61729b3'
> > inside
> > the 'SecurityToken-9e141676-2400-4c6d-ab87-1d5af61729b3' ?????
> >
> > I think it's code that is generate by algorithm on place of
> > plainText for
> > password.
> >
> > 1 question........by seeing the required security header, what kind of
> > security profile and action i should use.
> >
> > pls refer just above post.
> >
> > Regards
> > Santosh
> >
> >
> >
> >
> >
> >
> > Werner Dittmann wrote:
> > >
> > > you do not need to generate this. The identifiers are
> > generated by WSS4J
> > > (or .Net WSE)
> > > to identify particular tokens or tags. The identifiers are
> > unique inside
> > > on request or
> > > response. WSS4J or other WSS implementation may use the
> > identifiers to
> > > reference the
> > > tage or tokens in other tag, for example to sign or
> > encrypt. This all is
> > > specified
> > > in the OASIS Web Service Security specifictions. Id are
> > just strings (as
> > > far as I can
> > > remember the should be build accoriding to NMTOKENS - but I
> > may err here).
> > >
> > > Every implementation has its own way to generate Id names, .Net WSE
> > > generated UUID
> > > and appends this to a string, WSS4J uses another way to
> > generate an Id.
> > >
> > > You don't need to care about this - it's all inside the WSS
> > > implementation.
> > >
> > > Regards,
> > > Werner
> > >
> > > sh_santosh schrieb:
> > >> Dear all,
> > >>
> > >> Hi Jose / all,
> > >>
> > >> just one word away.
> > >>
> > >> I am NOT able generate
> > >> 'SecurityToken-9e141676-2400-4c6d-ab87-1d5af61729b3'
> > >> inside the wsse:UsernameToken tag.
> > >> In place of this i am able to generate only '
> > >> wsu:Id="UsernameToken-2691004"
> > >> '
> > >>
> > >> <wsse:UsernameToken
> > >>
> > xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401
> > -wss-wssecurity-utility-1.0.xsd"
> > >>
> > >> wsu:Id="SecurityToken-9e141676-2400-4c6d-ab87-1d5af61729b3">
> > >>
> > >> What is this 'SecurityToken-9e141676-2400-4c6d-ab87-1d5af61729b3' ?
> > >>
> > >> How can I generate it in Java (using Axis 1.3 and wss4j) ?
> > >>
> > >> Required Security Header by other end( .Net WSE 3.0) ----
> > >>
> > >> <?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/08/addressing"
> > >>
> > >>
> > xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-20040
> 1-wss-wssecurity-secext-1.0.xsd"
> > >>
> > >>
> > xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401
> > -wss-wssecurity-utility-1.0.xsd">
> > >> <soap:Header>
> > >> <wsa:Action>
> > >>
> > http://www.test.com/api/ws/internal/testInfo
> > >> </wsa:Action>
> > >> <wsa:MessageID>
> > >>
> > urn:uuid:ca7e475b-484a-4bb8-974f-eb573438bb43
> > >> </wsa:MessageID>
> > >> <wsa:ReplyTo>
> > >> <wsa:Address>
> > >>
> > >> http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous
> > >> </wsa:Address>
> > >> </wsa:ReplyTo>
> > >> <wsa:To>
> > >>
> > http://localhost:8080/testapi/testwsapi.asmx
> > >> </wsa:To>
> > >> <wsse:Security soap:mustUnderstand="1">
> > >> <wsu:Timestamp
> > >>
> > >> wsu:Id="Timestamp-c70b72e2-561c-4b18-bc4b-acf8c3896b14">
> > >>
> > >> <wsu:Created>2008-02-28T15:33:56Z</wsu:Created>
> > >>
> > >> <wsu:Expires>2008-02-28T15:38:56Z</wsu:Expires>
> > >> </wsu:Timestamp>
> > >> <wsse:UsernameToken
> > >>
> > >>
> > xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401
> > -wss-wssecurity-utility-1.0.xsd"
> > >>
> > >> wsu:Id="SecurityToken-9e141676-2400-4c6d-ab87-1d5af61729b3">
> > >>
> > >> <wsse:Username>santosh.ncstk@gmail.com</wsse:Username>
> > >> <wsse:Password
> > >>
> > >>
> > Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
> > username-token-profile-1.0#PasswordText">
> > >> SomePassword
> > >> </wsse:Password>
> > >>
> > >> <wsse:Nonce>5SImW1gykzSPdeiWzcCdaQ==</wsse:Nonce>
> > >>
> > >> <wsu:Created>2008-02-28T15:33:56Z</wsu:Created>
> > >> </wsse:UsernameToken>
> > >> </wsse:Security>
> > >> </soap:Header>
> > >> <soap:Body>
> > >> <SAN_Info
> > >>
> > >> xmlns="http://www.test.com/api/testing/ws/internal">
> > >> <SAN_Request VendorId="TestVendor"
> > >> VendorPassword="SomePassword"
> > >>
> > >> xmlns="http://www.test.com/api/testing/testinforequest">
> > >> <Brand>SANBUS</Brand>
> > >> <TourCode>GE</TourCode>
> > >> <Code>80135</Code>
> > >> </SAN_Request>
> > >> </SAN_Info>
> > >> </soap:Body>
> > >> </soap:Envelope>
> > >>
> > >> Generated Security header By my side (Java- Axis 1.3 and wss4j
> > >> )-----------------
> > >>
> > >> <?xml version="1.0" encoding="UTF-8"?>
> > >> <soapenv:Envelope
> > >> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
> > >>
> > xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"
> > >> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> > >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
> > >> <soapenv:Header>
> > >> <wsse:Security
> > >>
> > >>
> > xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-20040
> 1-wss-wssecurity-secext-1.0.xsd"
> > >> soapenv:mustUnderstand="1">
> > >> <wsse:UsernameToken
> > >>
> > >>
> > xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401
> > -wss-wssecurity-utility-1.0.xsd"
> > >> wsu:Id="UsernameToken-2691004">
> > >> <wsse:Username>
> > >> santosh.ncstk@gmail.com
> > >> </wsse:Username>
> > >> <wsse:Password
> > >>
> > >>
> > Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
> > username-token-profile-1.0#PasswordText">
> > >> SomePassword
> > >> </wsse:Password>
> > >>
> > >> <wsse:Nonce>bGmGuPDxQw2kkR5R0zC/hA==</wsse:Nonce>
> > >>
> > >> <wsu:Created>2008-07-10T16:46:47.046Z</wsu:Created>
> > >> </wsse:UsernameToken>
> > >> <wsu:Timestamp
> > >>
> > >>
> > xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401
> > -wss-wssecurity-utility-1.0.xsd"
> > >> wsu:Id="Timestamp-25899876">
> > >>
> > >> <wsu:Created>2008-07-10T16:46:47.015Z</wsu:Created>
> > >>
> > >> <wsu:Expires>2008-07-10T16:51:47.015Z</wsu:Expires>
> > >> </wsu:Timestamp>
> > >> </wsse:Security>
> > >> <wsa:MessageID soapenv:mustUnderstand="0">
> > >> uuid:c83b29b0-4e9f-11dd-8e1f-d019b0e90563
> > >> </wsa:MessageID>
> > >> <wsa:To soapenv:mustUnderstand="0">
> > >>
> > http://localhost:8080/testapi/testwsapi.asmx
> > >> </wsa:To>
> > >> <wsa:Action soapenv:mustUnderstand="0">
> > >>
> > http://www.test.com/api/testing/testinforequest
> > >> </wsa:Action>
> > >> <wsa:From soapenv:mustUnderstand="0">
> > >> <wsa:Address>
> > >>
> > >> http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous
> > >> </wsa:Address>
> > >> </wsa:From>
> > >> <wsa:ReplyTo soapenv:mustUnderstand="0">
> > >> <wsa:Address>
> > >>
> > >> http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous
> > >> </wsa:Address>
> > >> </wsa:ReplyTo>
> > >> </soapenv:Header>
> > >> <soapenv:Body>
> > >> <SAN_Info
> > >>
> > >> xmlns="http://www.test.com/api/testing/ws/internal">
> > >> <SAN_Request VendorId="TestVendor"
> > >> VendorPassword="SomePassword"
> > >>
> > >> xmlns="http://www.test.com/api/testing/testinforequest">
> > >> <Brand>SANBUS</Brand>
> > >> <TourCode>GE</TourCode>
> > >> <Code>80135</Code>
> > >> </SAN_Request>
> > >> </SAN_Info>
> > >> </soapenv:Body>
> > >> </soapenv:Envelope>
> > >>
> > >>
> > >> My client-config.wsdd ---------
> > >>
> > >> <?xml version="1.0" encoding="UTF-8"?>
> > >> <deployment xmlns="http://xml.apache.org/axis/wsdd/"
> > >> xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
> > >> <transport name="http"
> > >> pivot="java:org.apache.axis.transport.http.HTTPSender"/>
> > >> <globalConfiguration>
> > >> <requestFlow>
> > >> <handler
> > type="java:org.apache.ws.axis.security.WSDoAllSender" >
> > >> <parameter name="action" value="Timestamp UsernameToken"/>
> > >> <parameter name="user" value="santosh.ncstk@gmail.com"/>
> > >> <parameter name="passwordCallbackClass"
> > >> value="com.api.testing.ws.internal.PWCallback"/>
> > >> <parameter name="passwordType" value="PasswordText"/>
> > >> <parameter name="password" value="ppx13Z11"/>
> > >> <parameter name="mustUnderstand" value="true" />
> > >> <parameter name="addUTElements" value="Nonce Created"/>
> > >> </handler>
> > >> </requestFlow>
> > >> </globalConfiguration>
> > >> </deployment>
> > >>
> > >>
> > >> By seeing the security header, we can say that it is
> > >> username-token-profile-1.0.
> > >>
> > >> How to solve this.
> > >>
> > >>
> > >>
> > >> Please help me.
> > >>
> > >>
> > >>
> > >> Regards
> > >> Santosh
> > >>
> > >>
> > >>
> > >>
> > >> Fred Dushin-4 wrote:
> > >>> Assuming you are signing the UsernameToken, you'd want a
> > nonce in the
> > >>> username token to thwart replay attacks.
> > >>>
> > >>> Note that the WSS4J runtime does not support nonce caching or
> > >>> detection or replayed requests, so you'd have to implement this,
> > >>> yourself.
> > >>>
> > >>> Obviously, you'd also need to sign and encrypt the message (and
> > >>> response, likely) in order to get the same cryptographic
> > level of
> > >>> protection as you'd otherwise get from SSL. I can't
> > think of a case
> > >>> where you'd want to sign and encrypt the token, only, and
> > not the
> > >>> message, but I haven't given it much thought, either.
> > >>>
> > >>> In general, though, if you're using a transport protocol
> > that supports
> > >>> SSL (e.g., HTTP), you're better off using it, because you'd then
> > >>> benefit from the symmetric key negotiated in the SSL
> > handshake (hence
> > >>> getting far better performance). Also, if you're
> > bothering to use a
> > >>> private key and cert on the client side to sign the
> > message, you can
> > >>> get an added level of protection by using client authentication,
> > >>> through the SSL protocol. And if you're doing that, the
> > motivation
> > >>> for using a username and password diminishes. (Though if
> > you do use a
> > >>> username and password, even with SSL client
> > authentication, you'll
> > >>> likely still want to use a nonce to thwart replay; it
> > entirely depends
> > >>> on your trust model, at the server side.)
> > >>>
> > >>> Had to review some of this with the Iona security folks
> > (Colm, Donal
> > >>> Arundel, Eamonn Dwyer); thanks to them for setting me
> > straight on this.
> > >>>
> > >>> -Fred
> > >>>
> > >>> On Jul 3, 2008, at 8:36 AM, Glen Mazza wrote:
> > >>>
> > >>>> Thanks, here's another question. If I'm using the
> > UsernameToken
> > >>>> profile, and
> > >>>> I sign and encrypt the message, is it recommended to
> > also use SSL on
> > >>>> the
> > >>>> transport layer, or would that be redundant? I would guess the
> > >>>> answer is to
> > >>>> use SSL but *not* basic authentication, because the BA
> > part is more
> > >>>> or less
> > >>>> the same as provided by the username token information.
> > >>>>
> > >>>> Glen
> > >>>>
> > >>>>
> > >>>> Robert Wierschke-2 wrote:
> > >>>>> Hi,
> > >>>>>
> > >>>>> when you additionally sign the SOAP message the
> > recipient can be
> > >>>>> sure that
> > >>>>> the message was not altered in transit. This cannot be
> > achieved
> > >>>>> with just
> > >>>>> adding a UsernameToken.
> > >>>>>
> > >>>>> regards
> > >>>>> robert
> > >>>>>
> > >>>>> 2008/6/23 Glen Mazza <gl...@gmail.com>:
> > >>>>>
> > >>>>>> Hello, I have an architectural question about using
> > UsernameTokens
> > >>>>>> (which
> > >>>>>> I'm
> > >>>>>> trying to do with CXF, which of course uses WSS4J behind the
> > >>>>>> scenes). If
> > >>>>>> we
> > >>>>>> are using the UsernameToken profile, I can see why we need to
> > >>>>>> encrypt the
> > >>>>>> message with the server's public key (for
> > confidentiality), but am
> > >>>>>> unsure
> > >>>>>> if
> > >>>>>> we need to also sign the message with the client's
> > private key.
> > >>>>>> Is it
> > >>>>>> redundant with UsernameToken profile to also sign the SOAP
> > >>>>>> request? My
> > >>>>>> first guess, is that by definition, one is using
> > Usernames and
> > >>>>>> Passwords
> > >>>>>> for
> > >>>>>> authentication, and hence would not need signing of
> > the message as
> > >>>>>> well,
> > >>>>>> but
> > >>>>>> am unsure here.
> > >>>>>>
> > >>>>>> Thanks,
> > >>>>>> Glen
> > >>>>>> --
> > >>>>>> View this message in context:
> > >>>>>>
> > http://www.nabble.com/Using-UsernameTokens--also-need-to-sign-
> > the-SOAP-message--tp18059742p18059742.html
> > >>>>>> Sent from the WSS4J mailing list archive at Nabble.com.
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > ---------------------------------------------------------------------
> > >>>>>> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> > >>>>>> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>> --
> > >>>> View this message in context:
> > >>>>
> > http://www.nabble.com/Using-UsernameTokens--also-need-to-sign-
> > the-SOAP-message--tp18059742p18258267.html
> > >>>> Sent from the WSS4J mailing list archive at Nabble.com.
> > >>>>
> > >>>>
> > >>>>
> > ---------------------------------------------------------------------
> > >>>> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> > >>>> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> > >>>>
> > >>>>
> > >>>
> > >>>
> > ---------------------------------------------------------------------
> > >>> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> > >>> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> > >>>
> > >>>
> > >>>
> > >>
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> > >
> > >
> > >
> >
> > --
> > View this message in context:
> > http://www.nabble.com/Using-UsernameTokens--also-need-to-sign-
> > the-SOAP-message--tp18059742p18562179.html
> > Sent from the WSS4J mailing list archive at Nabble.com.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>
--
José Ferreiro
EPFL Communication Systems engineer
ing.sys.com.dipl.EPFL
AW: Using UsernameTokens--also need to sign the SOAP message?
Posted by "Dittmann, Werner (NSN - DE/Muenich)" <we...@nsn.com>.
Santosh,
looking at the word '9e141676-2400-4c6d-ab87-1d5af61729b3' :
this is the usual notation of a UUID as generated by sfotware.
It doe not mean anything but being a unique id (Universal Unique
ID). This has nothing to do with password or username.
UsernameToken is the action to use in Axis deployment file, please have
a look at the interop tests in the according directory of WSS4J.
Regards,
Werner
> -----Ursprüngliche Nachricht-----
> Von: ext sh_santosh [mailto:santosh.ncstk@gmail.com]
> Gesendet: Montag, 21. Juli 2008 06:53
> An: wss4j-dev@ws.apache.org
> Betreff: Re: Using UsernameTokens--also need to sign the SOAP message?
>
>
> Hi Werner,
>
> What about this word -'9e141676-2400-4c6d-ab87-1d5af61729b3'
> inside
> the 'SecurityToken-9e141676-2400-4c6d-ab87-1d5af61729b3' ?????
>
> I think it's code that is generate by algorithm on place of
> plainText for
> password.
>
> 1 question........by seeing the required security header, what kind of
> security profile and action i should use.
>
> pls refer just above post.
>
> Regards
> Santosh
>
>
>
>
>
>
> Werner Dittmann wrote:
> >
> > you do not need to generate this. The identifiers are
> generated by WSS4J
> > (or .Net WSE)
> > to identify particular tokens or tags. The identifiers are
> unique inside
> > on request or
> > response. WSS4J or other WSS implementation may use the
> identifiers to
> > reference the
> > tage or tokens in other tag, for example to sign or
> encrypt. This all is
> > specified
> > in the OASIS Web Service Security specifictions. Id are
> just strings (as
> > far as I can
> > remember the should be build accoriding to NMTOKENS - but I
> may err here).
> >
> > Every implementation has its own way to generate Id names, .Net WSE
> > generated UUID
> > and appends this to a string, WSS4J uses another way to
> generate an Id.
> >
> > You don't need to care about this - it's all inside the WSS
> > implementation.
> >
> > Regards,
> > Werner
> >
> > sh_santosh schrieb:
> >> Dear all,
> >>
> >> Hi Jose / all,
> >>
> >> just one word away.
> >>
> >> I am NOT able generate
> >> 'SecurityToken-9e141676-2400-4c6d-ab87-1d5af61729b3'
> >> inside the wsse:UsernameToken tag.
> >> In place of this i am able to generate only '
> >> wsu:Id="UsernameToken-2691004"
> >> '
> >>
> >> <wsse:UsernameToken
> >>
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401
> -wss-wssecurity-utility-1.0.xsd"
> >>
> >> wsu:Id="SecurityToken-9e141676-2400-4c6d-ab87-1d5af61729b3">
> >>
> >> What is this 'SecurityToken-9e141676-2400-4c6d-ab87-1d5af61729b3' ?
> >>
> >> How can I generate it in Java (using Axis 1.3 and wss4j) ?
> >>
> >> Required Security Header by other end( .Net WSE 3.0) ----
> >>
> >> <?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/08/addressing"
> >>
> >>
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-20040
1-wss-wssecurity-secext-1.0.xsd"
> >>
> >>
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401
> -wss-wssecurity-utility-1.0.xsd">
> >> <soap:Header>
> >> <wsa:Action>
> >>
> http://www.test.com/api/ws/internal/testInfo
> >> </wsa:Action>
> >> <wsa:MessageID>
> >>
> urn:uuid:ca7e475b-484a-4bb8-974f-eb573438bb43
> >> </wsa:MessageID>
> >> <wsa:ReplyTo>
> >> <wsa:Address>
> >>
> >> http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous
> >> </wsa:Address>
> >> </wsa:ReplyTo>
> >> <wsa:To>
> >>
> http://localhost:8080/testapi/testwsapi.asmx
> >> </wsa:To>
> >> <wsse:Security soap:mustUnderstand="1">
> >> <wsu:Timestamp
> >>
> >> wsu:Id="Timestamp-c70b72e2-561c-4b18-bc4b-acf8c3896b14">
> >>
> >> <wsu:Created>2008-02-28T15:33:56Z</wsu:Created>
> >>
> >> <wsu:Expires>2008-02-28T15:38:56Z</wsu:Expires>
> >> </wsu:Timestamp>
> >> <wsse:UsernameToken
> >>
> >>
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401
> -wss-wssecurity-utility-1.0.xsd"
> >>
> >> wsu:Id="SecurityToken-9e141676-2400-4c6d-ab87-1d5af61729b3">
> >>
> >> <wsse:Username>santosh.ncstk@gmail.com</wsse:Username>
> >> <wsse:Password
> >>
> >>
> Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
> username-token-profile-1.0#PasswordText">
> >> SomePassword
> >> </wsse:Password>
> >>
> >> <wsse:Nonce>5SImW1gykzSPdeiWzcCdaQ==</wsse:Nonce>
> >>
> >> <wsu:Created>2008-02-28T15:33:56Z</wsu:Created>
> >> </wsse:UsernameToken>
> >> </wsse:Security>
> >> </soap:Header>
> >> <soap:Body>
> >> <SAN_Info
> >>
> >> xmlns="http://www.test.com/api/testing/ws/internal">
> >> <SAN_Request VendorId="TestVendor"
> >> VendorPassword="SomePassword"
> >>
> >> xmlns="http://www.test.com/api/testing/testinforequest">
> >> <Brand>SANBUS</Brand>
> >> <TourCode>GE</TourCode>
> >> <Code>80135</Code>
> >> </SAN_Request>
> >> </SAN_Info>
> >> </soap:Body>
> >> </soap:Envelope>
> >>
> >> Generated Security header By my side (Java- Axis 1.3 and wss4j
> >> )-----------------
> >>
> >> <?xml version="1.0" encoding="UTF-8"?>
> >> <soapenv:Envelope
> >> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
> >>
> xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"
> >> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
> >> <soapenv:Header>
> >> <wsse:Security
> >>
> >>
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-20040
1-wss-wssecurity-secext-1.0.xsd"
> >> soapenv:mustUnderstand="1">
> >> <wsse:UsernameToken
> >>
> >>
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401
> -wss-wssecurity-utility-1.0.xsd"
> >> wsu:Id="UsernameToken-2691004">
> >> <wsse:Username>
> >> santosh.ncstk@gmail.com
> >> </wsse:Username>
> >> <wsse:Password
> >>
> >>
> Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
> username-token-profile-1.0#PasswordText">
> >> SomePassword
> >> </wsse:Password>
> >>
> >> <wsse:Nonce>bGmGuPDxQw2kkR5R0zC/hA==</wsse:Nonce>
> >>
> >> <wsu:Created>2008-07-10T16:46:47.046Z</wsu:Created>
> >> </wsse:UsernameToken>
> >> <wsu:Timestamp
> >>
> >>
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401
> -wss-wssecurity-utility-1.0.xsd"
> >> wsu:Id="Timestamp-25899876">
> >>
> >> <wsu:Created>2008-07-10T16:46:47.015Z</wsu:Created>
> >>
> >> <wsu:Expires>2008-07-10T16:51:47.015Z</wsu:Expires>
> >> </wsu:Timestamp>
> >> </wsse:Security>
> >> <wsa:MessageID soapenv:mustUnderstand="0">
> >> uuid:c83b29b0-4e9f-11dd-8e1f-d019b0e90563
> >> </wsa:MessageID>
> >> <wsa:To soapenv:mustUnderstand="0">
> >>
> http://localhost:8080/testapi/testwsapi.asmx
> >> </wsa:To>
> >> <wsa:Action soapenv:mustUnderstand="0">
> >>
> http://www.test.com/api/testing/testinforequest
> >> </wsa:Action>
> >> <wsa:From soapenv:mustUnderstand="0">
> >> <wsa:Address>
> >>
> >> http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous
> >> </wsa:Address>
> >> </wsa:From>
> >> <wsa:ReplyTo soapenv:mustUnderstand="0">
> >> <wsa:Address>
> >>
> >> http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous
> >> </wsa:Address>
> >> </wsa:ReplyTo>
> >> </soapenv:Header>
> >> <soapenv:Body>
> >> <SAN_Info
> >>
> >> xmlns="http://www.test.com/api/testing/ws/internal">
> >> <SAN_Request VendorId="TestVendor"
> >> VendorPassword="SomePassword"
> >>
> >> xmlns="http://www.test.com/api/testing/testinforequest">
> >> <Brand>SANBUS</Brand>
> >> <TourCode>GE</TourCode>
> >> <Code>80135</Code>
> >> </SAN_Request>
> >> </SAN_Info>
> >> </soapenv:Body>
> >> </soapenv:Envelope>
> >>
> >>
> >> My client-config.wsdd ---------
> >>
> >> <?xml version="1.0" encoding="UTF-8"?>
> >> <deployment xmlns="http://xml.apache.org/axis/wsdd/"
> >> xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
> >> <transport name="http"
> >> pivot="java:org.apache.axis.transport.http.HTTPSender"/>
> >> <globalConfiguration>
> >> <requestFlow>
> >> <handler
> type="java:org.apache.ws.axis.security.WSDoAllSender" >
> >> <parameter name="action" value="Timestamp UsernameToken"/>
> >> <parameter name="user" value="santosh.ncstk@gmail.com"/>
> >> <parameter name="passwordCallbackClass"
> >> value="com.api.testing.ws.internal.PWCallback"/>
> >> <parameter name="passwordType" value="PasswordText"/>
> >> <parameter name="password" value="ppx13Z11"/>
> >> <parameter name="mustUnderstand" value="true" />
> >> <parameter name="addUTElements" value="Nonce Created"/>
> >> </handler>
> >> </requestFlow>
> >> </globalConfiguration>
> >> </deployment>
> >>
> >>
> >> By seeing the security header, we can say that it is
> >> username-token-profile-1.0.
> >>
> >> How to solve this.
> >>
> >>
> >>
> >> Please help me.
> >>
> >>
> >>
> >> Regards
> >> Santosh
> >>
> >>
> >>
> >>
> >> Fred Dushin-4 wrote:
> >>> Assuming you are signing the UsernameToken, you'd want a
> nonce in the
> >>> username token to thwart replay attacks.
> >>>
> >>> Note that the WSS4J runtime does not support nonce caching or
> >>> detection or replayed requests, so you'd have to implement this,
> >>> yourself.
> >>>
> >>> Obviously, you'd also need to sign and encrypt the message (and
> >>> response, likely) in order to get the same cryptographic
> level of
> >>> protection as you'd otherwise get from SSL. I can't
> think of a case
> >>> where you'd want to sign and encrypt the token, only, and
> not the
> >>> message, but I haven't given it much thought, either.
> >>>
> >>> In general, though, if you're using a transport protocol
> that supports
> >>> SSL (e.g., HTTP), you're better off using it, because you'd then
> >>> benefit from the symmetric key negotiated in the SSL
> handshake (hence
> >>> getting far better performance). Also, if you're
> bothering to use a
> >>> private key and cert on the client side to sign the
> message, you can
> >>> get an added level of protection by using client authentication,
> >>> through the SSL protocol. And if you're doing that, the
> motivation
> >>> for using a username and password diminishes. (Though if
> you do use a
> >>> username and password, even with SSL client
> authentication, you'll
> >>> likely still want to use a nonce to thwart replay; it
> entirely depends
> >>> on your trust model, at the server side.)
> >>>
> >>> Had to review some of this with the Iona security folks
> (Colm, Donal
> >>> Arundel, Eamonn Dwyer); thanks to them for setting me
> straight on this.
> >>>
> >>> -Fred
> >>>
> >>> On Jul 3, 2008, at 8:36 AM, Glen Mazza wrote:
> >>>
> >>>> Thanks, here's another question. If I'm using the
> UsernameToken
> >>>> profile, and
> >>>> I sign and encrypt the message, is it recommended to
> also use SSL on
> >>>> the
> >>>> transport layer, or would that be redundant? I would guess the
> >>>> answer is to
> >>>> use SSL but *not* basic authentication, because the BA
> part is more
> >>>> or less
> >>>> the same as provided by the username token information.
> >>>>
> >>>> Glen
> >>>>
> >>>>
> >>>> Robert Wierschke-2 wrote:
> >>>>> Hi,
> >>>>>
> >>>>> when you additionally sign the SOAP message the
> recipient can be
> >>>>> sure that
> >>>>> the message was not altered in transit. This cannot be
> achieved
> >>>>> with just
> >>>>> adding a UsernameToken.
> >>>>>
> >>>>> regards
> >>>>> robert
> >>>>>
> >>>>> 2008/6/23 Glen Mazza <gl...@gmail.com>:
> >>>>>
> >>>>>> Hello, I have an architectural question about using
> UsernameTokens
> >>>>>> (which
> >>>>>> I'm
> >>>>>> trying to do with CXF, which of course uses WSS4J behind the
> >>>>>> scenes). If
> >>>>>> we
> >>>>>> are using the UsernameToken profile, I can see why we need to
> >>>>>> encrypt the
> >>>>>> message with the server's public key (for
> confidentiality), but am
> >>>>>> unsure
> >>>>>> if
> >>>>>> we need to also sign the message with the client's
> private key.
> >>>>>> Is it
> >>>>>> redundant with UsernameToken profile to also sign the SOAP
> >>>>>> request? My
> >>>>>> first guess, is that by definition, one is using
> Usernames and
> >>>>>> Passwords
> >>>>>> for
> >>>>>> authentication, and hence would not need signing of
> the message as
> >>>>>> well,
> >>>>>> but
> >>>>>> am unsure here.
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Glen
> >>>>>> --
> >>>>>> View this message in context:
> >>>>>>
> http://www.nabble.com/Using-UsernameTokens--also-need-to-sign-
> the-SOAP-message--tp18059742p18059742.html
> >>>>>> Sent from the WSS4J mailing list archive at Nabble.com.
> >>>>>>
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> >>>>>> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> >>>>>>
> >>>>>>
> >>>>>
> >>>> --
> >>>> View this message in context:
> >>>>
> http://www.nabble.com/Using-UsernameTokens--also-need-to-sign-
> the-SOAP-message--tp18059742p18258267.html
> >>>> Sent from the WSS4J mailing list archive at Nabble.com.
> >>>>
> >>>>
> >>>>
> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> >>>> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> >>>>
> >>>>
> >>>
> >>>
> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> >>> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> >>>
> >>>
> >>>
> >>
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Using-UsernameTokens--also-need-to-sign-
> the-SOAP-message--tp18059742p18562179.html
> Sent from the WSS4J mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: Using UsernameTokens--also need to sign the SOAP message?
Posted by sh_santosh <sa...@gmail.com>.
Hi Jose,
Required SOAP header by Provider (.Net ) ---------
<?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/08/addressing"
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">
<soap:Header>
<wsa:Action>
http://www.test.com/api/ws/internal/testInfo
</wsa:Action>
<wsa:MessageID>
urn:uuid:ca7e475b-484a-4bb8-974f-eb573438bb43
</wsa:MessageID>
<wsa:ReplyTo>
<wsa:Address>
http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous
</wsa:Address>
</wsa:ReplyTo>
<wsa:To>
http://localhost:8080/testapi/testwsapi.asmx
</wsa:To>
<wsse:Security soap:mustUnderstand="1">
<wsu:Timestamp
wsu:Id="Timestamp-c70b72e2-561c-4b18-bc4b-acf8c3896b14">
<wsu:Created>2008-02-28T15:33:56Z</wsu:Created>
<wsu:Expires>2008-02-28T15:38:56Z</wsu:Expires>
</wsu:Timestamp>
<wsse:UsernameToken
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
wsu:Id="SecurityToken-9e141676-2400-4c6d-ab87-1d5af61729b3">
<wsse:Username>santosh.ncstk@gmail.com</wsse:Username>
<wsse:Password
Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">
SomePassword
</wsse:Password>
<wsse:Nonce>5SImW1gykzSPdeiWzcCdaQ==</wsse:Nonce>
<wsu:Created>2008-02-28T15:33:56Z</wsu:Created>
</wsse:UsernameToken>
</wsse:Security>
</soap:Header>
<soap:Body>
<SAN_Info
xmlns="http://www.test.com/api/testing/ws/internal">
<SAN_Request VendorId="TestVendor"
VendorPassword="SomePassword"
xmlns="http://www.test.com/api/testing/testinforequest">
<Brand>SANBUS</Brand>
<TourCode>GE</TourCode>
<Code>80135</Code>
</SAN_Request>
</SAN_Info>
</soap:Body>
</soap:Envelope>
My client-config -
My client-config.wsdd ---------
<?xml version="1.0" encoding="UTF-8"?>
<deployment xmlns="http://xml.apache.org/axis/wsdd/"
xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
<transport name="http"
pivot="java:org.apache.axis.transport.http.HTTPSender"/>
<globalConfiguration>
<requestFlow>
<handler type="java:org.apache.ws.axis.security.WSDoAllSender" >
<parameter name="action" value="Timestamp UsernameToken"/>
<parameter name="user" value="santosh.ncstk@gmail.com"/>
<parameter name="passwordCallbackClass"
value="com.api.testing.ws.internal.PWCallback"/>
<parameter name="passwordType" value="PasswordText"/>
<parameter name="password" value="ppx13Z11"/>
<parameter name="mustUnderstand" value="true" />
<parameter name="addUTElements" value="Nonce Created"/>
</handler>
</requestFlow>
</globalConfiguration>
</deployment>
Please suggest which security profile and action i should use to solve this
issue.
How to use SHA1 algorithm in UsernameToken ???
I don't understand, when i able to generate same header as provider said
then why not i am able to access thier system.
Regards
Santosh
José Ferreiro wrote:
>
> Hello Santosh,
>
> Your line:
>
> <wsse:UsernameToken xmlns:wsu="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
> wsu:Id="SecurityToken-9e141676-2400-4c6d-ab87-1d5af61729b3">
> is based on the namespace:
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>
> you may open the URL by double clicking in the link:
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>
> By reading the provided documentation it follows that the attribute ID:
>
> <xsd:attribute name="Id" type="xsd:ID">
> <xsd:annotation>
> <xsd:documentation>This global attribute supports annotating
> arbitrary elements with an ID.</xsd:documentation>
> </xsd:annotation>
> </xsd:attribute>
>
> Then we may conclude that this type defines the fault code value for
> Timestamp message expiration
> (wsu:Id="SecurityToken-9e141676-2400-4c6d-ab87-1d5af61729b3).
>
>
> Hope this helps.
>
> Jose Ferreiro
>
>
> On 7/21/08, sh_santosh <sa...@gmail.com> wrote:
>>
>>
>> Hi Werner,
>>
>> What about this word -'9e141676-2400-4c6d-ab87-1d5af61729b3' inside
>> the 'SecurityToken-9e141676-2400-4c6d-ab87-1d5af61729b3' ?????
>>
>> I think it's code that is generate by algorithm on place of plainText for
>> password.
>>
>> 1 question........by seeing the required security header, what kind of
>> security profile and action i should use.
>>
>> pls refer just above post.
>>
>> Regards
>> Santosh
>>
>>
>>
>>
>>
>>
>> Werner Dittmann wrote:
>> >
>> > you do not need to generate this. The identifiers are generated by
>> WSS4J
>> > (or .Net WSE)
>> > to identify particular tokens or tags. The identifiers are unique
>> inside
>> > on request or
>> > response. WSS4J or other WSS implementation may use the identifiers to
>> > reference the
>> > tage or tokens in other tag, for example to sign or encrypt. This all
>> is
>> > specified
>> > in the OASIS Web Service Security specifictions. Id are just strings
>> (as
>> > far as I can
>> > remember the should be build accoriding to NMTOKENS - but I may err
>> here).
>> >
>> > Every implementation has its own way to generate Id names, .Net WSE
>> > generated UUID
>> > and appends this to a string, WSS4J uses another way to generate an Id.
>> >
>> > You don't need to care about this - it's all inside the WSS
>> > implementation.
>> >
>> > Regards,
>> > Werner
>> >
>> > sh_santosh schrieb:
>> >> Dear all,
>> >>
>> >> Hi Jose / all,
>> >>
>> >> just one word away.
>> >>
>> >> I am NOT able generate
>> >> 'SecurityToken-9e141676-2400-4c6d-ab87-1d5af61729b3'
>> >> inside the wsse:UsernameToken tag.
>> >> In place of this i am able to generate only '
>> >> wsu:Id="UsernameToken-2691004"
>> >> '
>> >>
>> >> <wsse:UsernameToken
>> >> xmlns:wsu="
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>> "
>> >>
>> >> wsu:Id="SecurityToken-9e141676-2400-4c6d-ab87-1d5af61729b3">
>> >>
>> >> What is this 'SecurityToken-9e141676-2400-4c6d-ab87-1d5af61729b3' ?
>> >>
>> >> How can I generate it in Java (using Axis 1.3 and wss4j) ?
>> >>
>> >> Required Security Header by other end( .Net WSE 3.0) ----
>> >>
>> >> <?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/08/addressing"
>> >>
>> >> 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
>> ">
>> >> <soap:Header>
>> >> <wsa:Action>
>> >> http://www.test.com/api/ws/internal/testInfo
>> >> </wsa:Action>
>> >> <wsa:MessageID>
>> >> urn:uuid:ca7e475b-484a-4bb8-974f-eb573438bb43
>> >> </wsa:MessageID>
>> >> <wsa:ReplyTo>
>> >> <wsa:Address>
>> >>
>> >> http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous
>> >> </wsa:Address>
>> >> </wsa:ReplyTo>
>> >> <wsa:To>
>> >> http://localhost:8080/testapi/testwsapi.asmx
>> >> </wsa:To>
>> >> <wsse:Security soap:mustUnderstand="1">
>> >> <wsu:Timestamp
>> >>
>> >> wsu:Id="Timestamp-c70b72e2-561c-4b18-bc4b-acf8c3896b14">
>> >>
>> >> <wsu:Created>2008-02-28T15:33:56Z</wsu:Created>
>> >>
>> >> <wsu:Expires>2008-02-28T15:38:56Z</wsu:Expires>
>> >> </wsu:Timestamp>
>> >> <wsse:UsernameToken
>> >>
>> >> xmlns:wsu="
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>> "
>> >>
>> >> wsu:Id="SecurityToken-9e141676-2400-4c6d-ab87-1d5af61729b3">
>> >>
>> >> <wsse:Username>santosh.ncstk@gmail.com</wsse:Username>
>> >> <wsse:Password
>> >>
>> >> Type="
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText
>> ">
>> >> SomePassword
>> >> </wsse:Password>
>> >>
>> >> <wsse:Nonce>5SImW1gykzSPdeiWzcCdaQ==</wsse:Nonce>
>> >>
>> >> <wsu:Created>2008-02-28T15:33:56Z</wsu:Created>
>> >> </wsse:UsernameToken>
>> >> </wsse:Security>
>> >> </soap:Header>
>> >> <soap:Body>
>> >> <SAN_Info
>> >>
>> >> xmlns="http://www.test.com/api/testing/ws/internal">
>> >> <SAN_Request VendorId="TestVendor"
>> >> VendorPassword="SomePassword"
>> >>
>> >> xmlns="http://www.test.com/api/testing/testinforequest">
>> >> <Brand>SANBUS</Brand>
>> >> <TourCode>GE</TourCode>
>> >> <Code>80135</Code>
>> >> </SAN_Request>
>> >> </SAN_Info>
>> >> </soap:Body>
>> >> </soap:Envelope>
>> >>
>> >> Generated Security header By my side (Java- Axis 1.3 and wss4j
>> >> )-----------------
>> >>
>> >> <?xml version="1.0" encoding="UTF-8"?>
>> >> <soapenv:Envelope
>> >> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
>> >> xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"
>> >> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
>> >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
>> >> <soapenv:Header>
>> >> <wsse:Security
>> >>
>> >> xmlns:wsse="
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>> "
>> >> soapenv:mustUnderstand="1">
>> >> <wsse:UsernameToken
>> >>
>> >> xmlns:wsu="
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>> "
>> >> wsu:Id="UsernameToken-2691004">
>> >> <wsse:Username>
>> >> santosh.ncstk@gmail.com
>> >> </wsse:Username>
>> >> <wsse:Password
>> >>
>> >> Type="
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText
>> ">
>> >> SomePassword
>> >> </wsse:Password>
>> >>
>> >> <wsse:Nonce>bGmGuPDxQw2kkR5R0zC/hA==</wsse:Nonce>
>> >>
>> >> <wsu:Created>2008-07-10T16:46:47.046Z</wsu:Created>
>> >> </wsse:UsernameToken>
>> >> <wsu:Timestamp
>> >>
>> >> xmlns:wsu="
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>> "
>> >> wsu:Id="Timestamp-25899876">
>> >>
>> >> <wsu:Created>2008-07-10T16:46:47.015Z</wsu:Created>
>> >>
>> >> <wsu:Expires>2008-07-10T16:51:47.015Z</wsu:Expires>
>> >> </wsu:Timestamp>
>> >> </wsse:Security>
>> >> <wsa:MessageID soapenv:mustUnderstand="0">
>> >> uuid:c83b29b0-4e9f-11dd-8e1f-d019b0e90563
>> >> </wsa:MessageID>
>> >> <wsa:To soapenv:mustUnderstand="0">
>> >> http://localhost:8080/testapi/testwsapi.asmx
>> >> </wsa:To>
>> >> <wsa:Action soapenv:mustUnderstand="0">
>> >>
>> http://www.test.com/api/testing/testinforequest
>> >> </wsa:Action>
>> >> <wsa:From soapenv:mustUnderstand="0">
>> >> <wsa:Address>
>> >>
>> >> http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous
>> >> </wsa:Address>
>> >> </wsa:From>
>> >> <wsa:ReplyTo soapenv:mustUnderstand="0">
>> >> <wsa:Address>
>> >>
>> >> http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous
>> >> </wsa:Address>
>> >> </wsa:ReplyTo>
>> >> </soapenv:Header>
>> >> <soapenv:Body>
>> >> <SAN_Info
>> >>
>> >> xmlns="http://www.test.com/api/testing/ws/internal">
>> >> <SAN_Request VendorId="TestVendor"
>> >> VendorPassword="SomePassword"
>> >>
>> >> xmlns="http://www.test.com/api/testing/testinforequest">
>> >> <Brand>SANBUS</Brand>
>> >> <TourCode>GE</TourCode>
>> >> <Code>80135</Code>
>> >> </SAN_Request>
>> >> </SAN_Info>
>> >> </soapenv:Body>
>> >> </soapenv:Envelope>
>> >>
>> >>
>> >> My client-config.wsdd ---------
>> >>
>> >> <?xml version="1.0" encoding="UTF-8"?>
>> >> <deployment xmlns="http://xml.apache.org/axis/wsdd/"
>> >> xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
>> >> <transport name="http"
>> >> pivot="java:org.apache.axis.transport.http.HTTPSender"/>
>> >> <globalConfiguration>
>> >> <requestFlow>
>> >> <handler type="java:org.apache.ws.axis.security.WSDoAllSender" >
>> >> <parameter name="action" value="Timestamp UsernameToken"/>
>> >> <parameter name="user" value="santosh.ncstk@gmail.com"/>
>> >> <parameter name="passwordCallbackClass"
>> >> value="com.api.testing.ws.internal.PWCallback"/>
>> >> <parameter name="passwordType" value="PasswordText"/>
>> >> <parameter name="password" value="ppx13Z11"/>
>> >> <parameter name="mustUnderstand" value="true" />
>> >> <parameter name="addUTElements" value="Nonce Created"/>
>> >> </handler>
>> >> </requestFlow>
>> >> </globalConfiguration>
>> >> </deployment>
>> >>
>> >>
>> >> By seeing the security header, we can say that it is
>> >> username-token-profile-1.0.
>> >>
>> >> How to solve this.
>> >>
>> >>
>> >>
>> >> Please help me.
>> >>
>> >>
>> >>
>> >> Regards
>> >> Santosh
>> >>
>> >>
>> >>
>> >>
>> >> Fred Dushin-4 wrote:
>> >>> Assuming you are signing the UsernameToken, you'd want a nonce in the
>> >>> username token to thwart replay attacks.
>> >>>
>> >>> Note that the WSS4J runtime does not support nonce caching or
>> >>> detection or replayed requests, so you'd have to implement this,
>> >>> yourself.
>> >>>
>> >>> Obviously, you'd also need to sign and encrypt the message (and
>> >>> response, likely) in order to get the same cryptographic level of
>> >>> protection as you'd otherwise get from SSL. I can't think of a case
>> >>> where you'd want to sign and encrypt the token, only, and not the
>> >>> message, but I haven't given it much thought, either.
>> >>>
>> >>> In general, though, if you're using a transport protocol that
>> supports
>> >>> SSL (e.g., HTTP), you're better off using it, because you'd then
>> >>> benefit from the symmetric key negotiated in the SSL handshake (hence
>> >>> getting far better performance). Also, if you're bothering to use a
>> >>> private key and cert on the client side to sign the message, you can
>> >>> get an added level of protection by using client authentication,
>> >>> through the SSL protocol. And if you're doing that, the motivation
>> >>> for using a username and password diminishes. (Though if you do use
>> a
>> >>> username and password, even with SSL client authentication, you'll
>> >>> likely still want to use a nonce to thwart replay; it entirely
>> depends
>> >>> on your trust model, at the server side.)
>> >>>
>> >>> Had to review some of this with the Iona security folks (Colm, Donal
>> >>> Arundel, Eamonn Dwyer); thanks to them for setting me straight on
>> this.
>> >>>
>> >>> -Fred
>> >>>
>> >>> On Jul 3, 2008, at 8:36 AM, Glen Mazza wrote:
>> >>>
>> >>>> Thanks, here's another question. If I'm using the UsernameToken
>> >>>> profile, and
>> >>>> I sign and encrypt the message, is it recommended to also use SSL on
>> >>>> the
>> >>>> transport layer, or would that be redundant? I would guess the
>> >>>> answer is to
>> >>>> use SSL but *not* basic authentication, because the BA part is more
>> >>>> or less
>> >>>> the same as provided by the username token information.
>> >>>>
>> >>>> Glen
>> >>>>
>> >>>>
>> >>>> Robert Wierschke-2 wrote:
>> >>>>> Hi,
>> >>>>>
>> >>>>> when you additionally sign the SOAP message the recipient can be
>> >>>>> sure that
>> >>>>> the message was not altered in transit. This cannot be achieved
>> >>>>> with just
>> >>>>> adding a UsernameToken.
>> >>>>>
>> >>>>> regards
>> >>>>> robert
>> >>>>>
>> >>>>> 2008/6/23 Glen Mazza <gl...@gmail.com>:
>> >>>>>
>> >>>>>> Hello, I have an architectural question about using UsernameTokens
>> >>>>>> (which
>> >>>>>> I'm
>> >>>>>> trying to do with CXF, which of course uses WSS4J behind the
>> >>>>>> scenes). If
>> >>>>>> we
>> >>>>>> are using the UsernameToken profile, I can see why we need to
>> >>>>>> encrypt the
>> >>>>>> message with the server's public key (for confidentiality), but am
>> >>>>>> unsure
>> >>>>>> if
>> >>>>>> we need to also sign the message with the client's private key.
>> >>>>>> Is it
>> >>>>>> redundant with UsernameToken profile to also sign the SOAP
>> >>>>>> request? My
>> >>>>>> first guess, is that by definition, one is using Usernames and
>> >>>>>> Passwords
>> >>>>>> for
>> >>>>>> authentication, and hence would not need signing of the message as
>> >>>>>> well,
>> >>>>>> but
>> >>>>>> am unsure here.
>> >>>>>>
>> >>>>>> Thanks,
>> >>>>>> Glen
>> >>>>>> --
>> >>>>>> View this message in context:
>> >>>>>>
>> http://www.nabble.com/Using-UsernameTokens--also-need-to-sign-the-SOAP-message--tp18059742p18059742.html
>> >>>>>> Sent from the WSS4J mailing list archive at Nabble.com.
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> ---------------------------------------------------------------------
>> >>>>>> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>> >>>>>> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>> --
>> >>>> View this message in context:
>> >>>>
>> http://www.nabble.com/Using-UsernameTokens--also-need-to-sign-the-SOAP-message--tp18059742p18258267.html
>> >>>> Sent from the WSS4J mailing list archive at Nabble.com.
>> >>>>
>> >>>>
>> >>>>
>> ---------------------------------------------------------------------
>> >>>> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>> >>>> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>> >>>>
>> >>>>
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>> >>> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>> >>>
>> >>>
>> >>>
>> >>
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Using-UsernameTokens--also-need-to-sign-the-SOAP-message--tp18059742p18562179.html
>> Sent from the WSS4J mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>>
>>
>
>
> --
> José Ferreiro
> EPFL Communication Systems engineer
> ing.sys.com.dipl.EPFL
>
> "Think little goals and expect little achievements. Think big goals and
> win
> big success." David Joseph Schwartz
>
>
--
View this message in context: http://www.nabble.com/Using-UsernameTokens--also-need-to-sign-the-SOAP-message--tp18059742p18563794.html
Sent from the WSS4J mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: Using UsernameTokens--also need to sign the SOAP message?
Posted by José Ferreiro <jo...@gmail.com>.
Hello Santosh,
Your line:
<wsse:UsernameToken xmlns:wsu="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
wsu:Id="SecurityToken-9e141676-2400-4c6d-ab87-1d5af61729b3">
is based on the namespace:
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
you may open the URL by double clicking in the link:
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
By reading the provided documentation it follows that the attribute ID:
<xsd:attribute name="Id" type="xsd:ID">
<xsd:annotation>
<xsd:documentation>This global attribute supports annotating
arbitrary elements with an ID.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
Then we may conclude that this type defines the fault code value for
Timestamp message expiration
(wsu:Id="SecurityToken-9e141676-2400-4c6d-ab87-1d5af61729b3).
Hope this helps.
Jose Ferreiro
On 7/21/08, sh_santosh <sa...@gmail.com> wrote:
>
>
> Hi Werner,
>
> What about this word -'9e141676-2400-4c6d-ab87-1d5af61729b3' inside
> the 'SecurityToken-9e141676-2400-4c6d-ab87-1d5af61729b3' ?????
>
> I think it's code that is generate by algorithm on place of plainText for
> password.
>
> 1 question........by seeing the required security header, what kind of
> security profile and action i should use.
>
> pls refer just above post.
>
> Regards
> Santosh
>
>
>
>
>
>
> Werner Dittmann wrote:
> >
> > you do not need to generate this. The identifiers are generated by WSS4J
> > (or .Net WSE)
> > to identify particular tokens or tags. The identifiers are unique inside
> > on request or
> > response. WSS4J or other WSS implementation may use the identifiers to
> > reference the
> > tage or tokens in other tag, for example to sign or encrypt. This all is
> > specified
> > in the OASIS Web Service Security specifictions. Id are just strings (as
> > far as I can
> > remember the should be build accoriding to NMTOKENS - but I may err
> here).
> >
> > Every implementation has its own way to generate Id names, .Net WSE
> > generated UUID
> > and appends this to a string, WSS4J uses another way to generate an Id.
> >
> > You don't need to care about this - it's all inside the WSS
> > implementation.
> >
> > Regards,
> > Werner
> >
> > sh_santosh schrieb:
> >> Dear all,
> >>
> >> Hi Jose / all,
> >>
> >> just one word away.
> >>
> >> I am NOT able generate
> >> 'SecurityToken-9e141676-2400-4c6d-ab87-1d5af61729b3'
> >> inside the wsse:UsernameToken tag.
> >> In place of this i am able to generate only '
> >> wsu:Id="UsernameToken-2691004"
> >> '
> >>
> >> <wsse:UsernameToken
> >> xmlns:wsu="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> "
> >>
> >> wsu:Id="SecurityToken-9e141676-2400-4c6d-ab87-1d5af61729b3">
> >>
> >> What is this 'SecurityToken-9e141676-2400-4c6d-ab87-1d5af61729b3' ?
> >>
> >> How can I generate it in Java (using Axis 1.3 and wss4j) ?
> >>
> >> Required Security Header by other end( .Net WSE 3.0) ----
> >>
> >> <?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/08/addressing"
> >>
> >> 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
> ">
> >> <soap:Header>
> >> <wsa:Action>
> >> http://www.test.com/api/ws/internal/testInfo
> >> </wsa:Action>
> >> <wsa:MessageID>
> >> urn:uuid:ca7e475b-484a-4bb8-974f-eb573438bb43
> >> </wsa:MessageID>
> >> <wsa:ReplyTo>
> >> <wsa:Address>
> >>
> >> http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous
> >> </wsa:Address>
> >> </wsa:ReplyTo>
> >> <wsa:To>
> >> http://localhost:8080/testapi/testwsapi.asmx
> >> </wsa:To>
> >> <wsse:Security soap:mustUnderstand="1">
> >> <wsu:Timestamp
> >>
> >> wsu:Id="Timestamp-c70b72e2-561c-4b18-bc4b-acf8c3896b14">
> >>
> >> <wsu:Created>2008-02-28T15:33:56Z</wsu:Created>
> >>
> >> <wsu:Expires>2008-02-28T15:38:56Z</wsu:Expires>
> >> </wsu:Timestamp>
> >> <wsse:UsernameToken
> >>
> >> xmlns:wsu="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> "
> >>
> >> wsu:Id="SecurityToken-9e141676-2400-4c6d-ab87-1d5af61729b3">
> >>
> >> <wsse:Username>santosh.ncstk@gmail.com</wsse:Username>
> >> <wsse:Password
> >>
> >> Type="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText
> ">
> >> SomePassword
> >> </wsse:Password>
> >>
> >> <wsse:Nonce>5SImW1gykzSPdeiWzcCdaQ==</wsse:Nonce>
> >>
> >> <wsu:Created>2008-02-28T15:33:56Z</wsu:Created>
> >> </wsse:UsernameToken>
> >> </wsse:Security>
> >> </soap:Header>
> >> <soap:Body>
> >> <SAN_Info
> >>
> >> xmlns="http://www.test.com/api/testing/ws/internal">
> >> <SAN_Request VendorId="TestVendor"
> >> VendorPassword="SomePassword"
> >>
> >> xmlns="http://www.test.com/api/testing/testinforequest">
> >> <Brand>SANBUS</Brand>
> >> <TourCode>GE</TourCode>
> >> <Code>80135</Code>
> >> </SAN_Request>
> >> </SAN_Info>
> >> </soap:Body>
> >> </soap:Envelope>
> >>
> >> Generated Security header By my side (Java- Axis 1.3 and wss4j
> >> )-----------------
> >>
> >> <?xml version="1.0" encoding="UTF-8"?>
> >> <soapenv:Envelope
> >> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
> >> xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"
> >> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
> >> <soapenv:Header>
> >> <wsse:Security
> >>
> >> xmlns:wsse="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> "
> >> soapenv:mustUnderstand="1">
> >> <wsse:UsernameToken
> >>
> >> xmlns:wsu="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> "
> >> wsu:Id="UsernameToken-2691004">
> >> <wsse:Username>
> >> santosh.ncstk@gmail.com
> >> </wsse:Username>
> >> <wsse:Password
> >>
> >> Type="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText
> ">
> >> SomePassword
> >> </wsse:Password>
> >>
> >> <wsse:Nonce>bGmGuPDxQw2kkR5R0zC/hA==</wsse:Nonce>
> >>
> >> <wsu:Created>2008-07-10T16:46:47.046Z</wsu:Created>
> >> </wsse:UsernameToken>
> >> <wsu:Timestamp
> >>
> >> xmlns:wsu="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> "
> >> wsu:Id="Timestamp-25899876">
> >>
> >> <wsu:Created>2008-07-10T16:46:47.015Z</wsu:Created>
> >>
> >> <wsu:Expires>2008-07-10T16:51:47.015Z</wsu:Expires>
> >> </wsu:Timestamp>
> >> </wsse:Security>
> >> <wsa:MessageID soapenv:mustUnderstand="0">
> >> uuid:c83b29b0-4e9f-11dd-8e1f-d019b0e90563
> >> </wsa:MessageID>
> >> <wsa:To soapenv:mustUnderstand="0">
> >> http://localhost:8080/testapi/testwsapi.asmx
> >> </wsa:To>
> >> <wsa:Action soapenv:mustUnderstand="0">
> >> http://www.test.com/api/testing/testinforequest
> >> </wsa:Action>
> >> <wsa:From soapenv:mustUnderstand="0">
> >> <wsa:Address>
> >>
> >> http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous
> >> </wsa:Address>
> >> </wsa:From>
> >> <wsa:ReplyTo soapenv:mustUnderstand="0">
> >> <wsa:Address>
> >>
> >> http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous
> >> </wsa:Address>
> >> </wsa:ReplyTo>
> >> </soapenv:Header>
> >> <soapenv:Body>
> >> <SAN_Info
> >>
> >> xmlns="http://www.test.com/api/testing/ws/internal">
> >> <SAN_Request VendorId="TestVendor"
> >> VendorPassword="SomePassword"
> >>
> >> xmlns="http://www.test.com/api/testing/testinforequest">
> >> <Brand>SANBUS</Brand>
> >> <TourCode>GE</TourCode>
> >> <Code>80135</Code>
> >> </SAN_Request>
> >> </SAN_Info>
> >> </soapenv:Body>
> >> </soapenv:Envelope>
> >>
> >>
> >> My client-config.wsdd ---------
> >>
> >> <?xml version="1.0" encoding="UTF-8"?>
> >> <deployment xmlns="http://xml.apache.org/axis/wsdd/"
> >> xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
> >> <transport name="http"
> >> pivot="java:org.apache.axis.transport.http.HTTPSender"/>
> >> <globalConfiguration>
> >> <requestFlow>
> >> <handler type="java:org.apache.ws.axis.security.WSDoAllSender" >
> >> <parameter name="action" value="Timestamp UsernameToken"/>
> >> <parameter name="user" value="santosh.ncstk@gmail.com"/>
> >> <parameter name="passwordCallbackClass"
> >> value="com.api.testing.ws.internal.PWCallback"/>
> >> <parameter name="passwordType" value="PasswordText"/>
> >> <parameter name="password" value="ppx13Z11"/>
> >> <parameter name="mustUnderstand" value="true" />
> >> <parameter name="addUTElements" value="Nonce Created"/>
> >> </handler>
> >> </requestFlow>
> >> </globalConfiguration>
> >> </deployment>
> >>
> >>
> >> By seeing the security header, we can say that it is
> >> username-token-profile-1.0.
> >>
> >> How to solve this.
> >>
> >>
> >>
> >> Please help me.
> >>
> >>
> >>
> >> Regards
> >> Santosh
> >>
> >>
> >>
> >>
> >> Fred Dushin-4 wrote:
> >>> Assuming you are signing the UsernameToken, you'd want a nonce in the
> >>> username token to thwart replay attacks.
> >>>
> >>> Note that the WSS4J runtime does not support nonce caching or
> >>> detection or replayed requests, so you'd have to implement this,
> >>> yourself.
> >>>
> >>> Obviously, you'd also need to sign and encrypt the message (and
> >>> response, likely) in order to get the same cryptographic level of
> >>> protection as you'd otherwise get from SSL. I can't think of a case
> >>> where you'd want to sign and encrypt the token, only, and not the
> >>> message, but I haven't given it much thought, either.
> >>>
> >>> In general, though, if you're using a transport protocol that supports
> >>> SSL (e.g., HTTP), you're better off using it, because you'd then
> >>> benefit from the symmetric key negotiated in the SSL handshake (hence
> >>> getting far better performance). Also, if you're bothering to use a
> >>> private key and cert on the client side to sign the message, you can
> >>> get an added level of protection by using client authentication,
> >>> through the SSL protocol. And if you're doing that, the motivation
> >>> for using a username and password diminishes. (Though if you do use a
> >>> username and password, even with SSL client authentication, you'll
> >>> likely still want to use a nonce to thwart replay; it entirely depends
> >>> on your trust model, at the server side.)
> >>>
> >>> Had to review some of this with the Iona security folks (Colm, Donal
> >>> Arundel, Eamonn Dwyer); thanks to them for setting me straight on this.
> >>>
> >>> -Fred
> >>>
> >>> On Jul 3, 2008, at 8:36 AM, Glen Mazza wrote:
> >>>
> >>>> Thanks, here's another question. If I'm using the UsernameToken
> >>>> profile, and
> >>>> I sign and encrypt the message, is it recommended to also use SSL on
> >>>> the
> >>>> transport layer, or would that be redundant? I would guess the
> >>>> answer is to
> >>>> use SSL but *not* basic authentication, because the BA part is more
> >>>> or less
> >>>> the same as provided by the username token information.
> >>>>
> >>>> Glen
> >>>>
> >>>>
> >>>> Robert Wierschke-2 wrote:
> >>>>> Hi,
> >>>>>
> >>>>> when you additionally sign the SOAP message the recipient can be
> >>>>> sure that
> >>>>> the message was not altered in transit. This cannot be achieved
> >>>>> with just
> >>>>> adding a UsernameToken.
> >>>>>
> >>>>> regards
> >>>>> robert
> >>>>>
> >>>>> 2008/6/23 Glen Mazza <gl...@gmail.com>:
> >>>>>
> >>>>>> Hello, I have an architectural question about using UsernameTokens
> >>>>>> (which
> >>>>>> I'm
> >>>>>> trying to do with CXF, which of course uses WSS4J behind the
> >>>>>> scenes). If
> >>>>>> we
> >>>>>> are using the UsernameToken profile, I can see why we need to
> >>>>>> encrypt the
> >>>>>> message with the server's public key (for confidentiality), but am
> >>>>>> unsure
> >>>>>> if
> >>>>>> we need to also sign the message with the client's private key.
> >>>>>> Is it
> >>>>>> redundant with UsernameToken profile to also sign the SOAP
> >>>>>> request? My
> >>>>>> first guess, is that by definition, one is using Usernames and
> >>>>>> Passwords
> >>>>>> for
> >>>>>> authentication, and hence would not need signing of the message as
> >>>>>> well,
> >>>>>> but
> >>>>>> am unsure here.
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Glen
> >>>>>> --
> >>>>>> View this message in context:
> >>>>>>
> http://www.nabble.com/Using-UsernameTokens--also-need-to-sign-the-SOAP-message--tp18059742p18059742.html
> >>>>>> Sent from the WSS4J mailing list archive at Nabble.com.
> >>>>>>
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> >>>>>> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> >>>>>>
> >>>>>>
> >>>>>
> >>>> --
> >>>> View this message in context:
> >>>>
> http://www.nabble.com/Using-UsernameTokens--also-need-to-sign-the-SOAP-message--tp18059742p18258267.html
> >>>> Sent from the WSS4J mailing list archive at Nabble.com.
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> >>>> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> >>>>
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> >>> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> >>>
> >>>
> >>>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Using-UsernameTokens--also-need-to-sign-the-SOAP-message--tp18059742p18562179.html
> Sent from the WSS4J mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>
--
José Ferreiro
EPFL Communication Systems engineer
ing.sys.com.dipl.EPFL
"Think little goals and expect little achievements. Think big goals and win
big success." David Joseph Schwartz
Re: Using UsernameTokens--also need to sign the SOAP message?
Posted by sh_santosh <sa...@gmail.com>.
Hi Werner,
What about this word -'9e141676-2400-4c6d-ab87-1d5af61729b3' inside
the 'SecurityToken-9e141676-2400-4c6d-ab87-1d5af61729b3' ?????
I think it's code that is generate by algorithm on place of plainText for
password.
1 question........by seeing the required security header, what kind of
security profile and action i should use.
pls refer just above post.
Regards
Santosh
Werner Dittmann wrote:
>
> you do not need to generate this. The identifiers are generated by WSS4J
> (or .Net WSE)
> to identify particular tokens or tags. The identifiers are unique inside
> on request or
> response. WSS4J or other WSS implementation may use the identifiers to
> reference the
> tage or tokens in other tag, for example to sign or encrypt. This all is
> specified
> in the OASIS Web Service Security specifictions. Id are just strings (as
> far as I can
> remember the should be build accoriding to NMTOKENS - but I may err here).
>
> Every implementation has its own way to generate Id names, .Net WSE
> generated UUID
> and appends this to a string, WSS4J uses another way to generate an Id.
>
> You don't need to care about this - it's all inside the WSS
> implementation.
>
> Regards,
> Werner
>
> sh_santosh schrieb:
>> Dear all,
>>
>> Hi Jose / all,
>>
>> just one word away.
>>
>> I am NOT able generate
>> 'SecurityToken-9e141676-2400-4c6d-ab87-1d5af61729b3'
>> inside the wsse:UsernameToken tag.
>> In place of this i am able to generate only '
>> wsu:Id="UsernameToken-2691004"
>> '
>>
>> <wsse:UsernameToken
>> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
>>
>> wsu:Id="SecurityToken-9e141676-2400-4c6d-ab87-1d5af61729b3">
>>
>> What is this 'SecurityToken-9e141676-2400-4c6d-ab87-1d5af61729b3' ?
>>
>> How can I generate it in Java (using Axis 1.3 and wss4j) ?
>>
>> Required Security Header by other end( .Net WSE 3.0) ----
>>
>> <?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/08/addressing"
>>
>> 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">
>> <soap:Header>
>> <wsa:Action>
>> http://www.test.com/api/ws/internal/testInfo
>> </wsa:Action>
>> <wsa:MessageID>
>> urn:uuid:ca7e475b-484a-4bb8-974f-eb573438bb43
>> </wsa:MessageID>
>> <wsa:ReplyTo>
>> <wsa:Address>
>>
>> http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous
>> </wsa:Address>
>> </wsa:ReplyTo>
>> <wsa:To>
>> http://localhost:8080/testapi/testwsapi.asmx
>> </wsa:To>
>> <wsse:Security soap:mustUnderstand="1">
>> <wsu:Timestamp
>>
>> wsu:Id="Timestamp-c70b72e2-561c-4b18-bc4b-acf8c3896b14">
>>
>> <wsu:Created>2008-02-28T15:33:56Z</wsu:Created>
>>
>> <wsu:Expires>2008-02-28T15:38:56Z</wsu:Expires>
>> </wsu:Timestamp>
>> <wsse:UsernameToken
>>
>> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
>>
>> wsu:Id="SecurityToken-9e141676-2400-4c6d-ab87-1d5af61729b3">
>>
>> <wsse:Username>santosh.ncstk@gmail.com</wsse:Username>
>> <wsse:Password
>>
>> Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">
>> SomePassword
>> </wsse:Password>
>>
>> <wsse:Nonce>5SImW1gykzSPdeiWzcCdaQ==</wsse:Nonce>
>>
>> <wsu:Created>2008-02-28T15:33:56Z</wsu:Created>
>> </wsse:UsernameToken>
>> </wsse:Security>
>> </soap:Header>
>> <soap:Body>
>> <SAN_Info
>>
>> xmlns="http://www.test.com/api/testing/ws/internal">
>> <SAN_Request VendorId="TestVendor"
>> VendorPassword="SomePassword"
>>
>> xmlns="http://www.test.com/api/testing/testinforequest">
>> <Brand>SANBUS</Brand>
>> <TourCode>GE</TourCode>
>> <Code>80135</Code>
>> </SAN_Request>
>> </SAN_Info>
>> </soap:Body>
>> </soap:Envelope>
>>
>> Generated Security header By my side (Java- Axis 1.3 and wss4j
>> )-----------------
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <soapenv:Envelope
>> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
>> xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"
>> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
>> <soapenv:Header>
>> <wsse:Security
>>
>> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
>> soapenv:mustUnderstand="1">
>> <wsse:UsernameToken
>>
>> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
>> wsu:Id="UsernameToken-2691004">
>> <wsse:Username>
>> santosh.ncstk@gmail.com
>> </wsse:Username>
>> <wsse:Password
>>
>> Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">
>> SomePassword
>> </wsse:Password>
>>
>> <wsse:Nonce>bGmGuPDxQw2kkR5R0zC/hA==</wsse:Nonce>
>>
>> <wsu:Created>2008-07-10T16:46:47.046Z</wsu:Created>
>> </wsse:UsernameToken>
>> <wsu:Timestamp
>>
>> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
>> wsu:Id="Timestamp-25899876">
>>
>> <wsu:Created>2008-07-10T16:46:47.015Z</wsu:Created>
>>
>> <wsu:Expires>2008-07-10T16:51:47.015Z</wsu:Expires>
>> </wsu:Timestamp>
>> </wsse:Security>
>> <wsa:MessageID soapenv:mustUnderstand="0">
>> uuid:c83b29b0-4e9f-11dd-8e1f-d019b0e90563
>> </wsa:MessageID>
>> <wsa:To soapenv:mustUnderstand="0">
>> http://localhost:8080/testapi/testwsapi.asmx
>> </wsa:To>
>> <wsa:Action soapenv:mustUnderstand="0">
>> http://www.test.com/api/testing/testinforequest
>> </wsa:Action>
>> <wsa:From soapenv:mustUnderstand="0">
>> <wsa:Address>
>>
>> http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous
>> </wsa:Address>
>> </wsa:From>
>> <wsa:ReplyTo soapenv:mustUnderstand="0">
>> <wsa:Address>
>>
>> http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous
>> </wsa:Address>
>> </wsa:ReplyTo>
>> </soapenv:Header>
>> <soapenv:Body>
>> <SAN_Info
>>
>> xmlns="http://www.test.com/api/testing/ws/internal">
>> <SAN_Request VendorId="TestVendor"
>> VendorPassword="SomePassword"
>>
>> xmlns="http://www.test.com/api/testing/testinforequest">
>> <Brand>SANBUS</Brand>
>> <TourCode>GE</TourCode>
>> <Code>80135</Code>
>> </SAN_Request>
>> </SAN_Info>
>> </soapenv:Body>
>> </soapenv:Envelope>
>>
>>
>> My client-config.wsdd ---------
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <deployment xmlns="http://xml.apache.org/axis/wsdd/"
>> xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
>> <transport name="http"
>> pivot="java:org.apache.axis.transport.http.HTTPSender"/>
>> <globalConfiguration>
>> <requestFlow>
>> <handler type="java:org.apache.ws.axis.security.WSDoAllSender" >
>> <parameter name="action" value="Timestamp UsernameToken"/>
>> <parameter name="user" value="santosh.ncstk@gmail.com"/>
>> <parameter name="passwordCallbackClass"
>> value="com.api.testing.ws.internal.PWCallback"/>
>> <parameter name="passwordType" value="PasswordText"/>
>> <parameter name="password" value="ppx13Z11"/>
>> <parameter name="mustUnderstand" value="true" />
>> <parameter name="addUTElements" value="Nonce Created"/>
>> </handler>
>> </requestFlow>
>> </globalConfiguration>
>> </deployment>
>>
>>
>> By seeing the security header, we can say that it is
>> username-token-profile-1.0.
>>
>> How to solve this.
>>
>>
>>
>> Please help me.
>>
>>
>>
>> Regards
>> Santosh
>>
>>
>>
>>
>> Fred Dushin-4 wrote:
>>> Assuming you are signing the UsernameToken, you'd want a nonce in the
>>> username token to thwart replay attacks.
>>>
>>> Note that the WSS4J runtime does not support nonce caching or
>>> detection or replayed requests, so you'd have to implement this,
>>> yourself.
>>>
>>> Obviously, you'd also need to sign and encrypt the message (and
>>> response, likely) in order to get the same cryptographic level of
>>> protection as you'd otherwise get from SSL. I can't think of a case
>>> where you'd want to sign and encrypt the token, only, and not the
>>> message, but I haven't given it much thought, either.
>>>
>>> In general, though, if you're using a transport protocol that supports
>>> SSL (e.g., HTTP), you're better off using it, because you'd then
>>> benefit from the symmetric key negotiated in the SSL handshake (hence
>>> getting far better performance). Also, if you're bothering to use a
>>> private key and cert on the client side to sign the message, you can
>>> get an added level of protection by using client authentication,
>>> through the SSL protocol. And if you're doing that, the motivation
>>> for using a username and password diminishes. (Though if you do use a
>>> username and password, even with SSL client authentication, you'll
>>> likely still want to use a nonce to thwart replay; it entirely depends
>>> on your trust model, at the server side.)
>>>
>>> Had to review some of this with the Iona security folks (Colm, Donal
>>> Arundel, Eamonn Dwyer); thanks to them for setting me straight on this.
>>>
>>> -Fred
>>>
>>> On Jul 3, 2008, at 8:36 AM, Glen Mazza wrote:
>>>
>>>> Thanks, here's another question. If I'm using the UsernameToken
>>>> profile, and
>>>> I sign and encrypt the message, is it recommended to also use SSL on
>>>> the
>>>> transport layer, or would that be redundant? I would guess the
>>>> answer is to
>>>> use SSL but *not* basic authentication, because the BA part is more
>>>> or less
>>>> the same as provided by the username token information.
>>>>
>>>> Glen
>>>>
>>>>
>>>> Robert Wierschke-2 wrote:
>>>>> Hi,
>>>>>
>>>>> when you additionally sign the SOAP message the recipient can be
>>>>> sure that
>>>>> the message was not altered in transit. This cannot be achieved
>>>>> with just
>>>>> adding a UsernameToken.
>>>>>
>>>>> regards
>>>>> robert
>>>>>
>>>>> 2008/6/23 Glen Mazza <gl...@gmail.com>:
>>>>>
>>>>>> Hello, I have an architectural question about using UsernameTokens
>>>>>> (which
>>>>>> I'm
>>>>>> trying to do with CXF, which of course uses WSS4J behind the
>>>>>> scenes). If
>>>>>> we
>>>>>> are using the UsernameToken profile, I can see why we need to
>>>>>> encrypt the
>>>>>> message with the server's public key (for confidentiality), but am
>>>>>> unsure
>>>>>> if
>>>>>> we need to also sign the message with the client's private key.
>>>>>> Is it
>>>>>> redundant with UsernameToken profile to also sign the SOAP
>>>>>> request? My
>>>>>> first guess, is that by definition, one is using Usernames and
>>>>>> Passwords
>>>>>> for
>>>>>> authentication, and hence would not need signing of the message as
>>>>>> well,
>>>>>> but
>>>>>> am unsure here.
>>>>>>
>>>>>> Thanks,
>>>>>> Glen
>>>>>> --
>>>>>> View this message in context:
>>>>>> http://www.nabble.com/Using-UsernameTokens--also-need-to-sign-the-SOAP-message--tp18059742p18059742.html
>>>>>> Sent from the WSS4J mailing list archive at Nabble.com.
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>>>>>> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>>>>>>
>>>>>>
>>>>>
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/Using-UsernameTokens--also-need-to-sign-the-SOAP-message--tp18059742p18258267.html
>>>> Sent from the WSS4J mailing list archive at Nabble.com.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>>>
>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Using-UsernameTokens--also-need-to-sign-the-SOAP-message--tp18059742p18562179.html
Sent from the WSS4J mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: Using UsernameTokens--also need to sign the SOAP message?
Posted by Werner Dittmann <We...@t-online.de>.
you do not need to generate this. The identifiers are generated by WSS4J (or .Net WSE)
to identify particular tokens or tags. The identifiers are unique inside on request or
response. WSS4J or other WSS implementation may use the identifiers to reference the
tage or tokens in other tag, for example to sign or encrypt. This all is specified
in the OASIS Web Service Security specifictions. Id are just strings (as far as I can
remember the should be build accoriding to NMTOKENS - but I may err here).
Every implementation has its own way to generate Id names, .Net WSE generated UUID
and appends this to a string, WSS4J uses another way to generate an Id.
You don't need to care about this - it's all inside the WSS implementation.
Regards,
Werner
sh_santosh schrieb:
> Dear all,
>
> Hi Jose / all,
>
> just one word away.
>
> I am NOT able generate 'SecurityToken-9e141676-2400-4c6d-ab87-1d5af61729b3'
> inside the wsse:UsernameToken tag.
> In place of this i am able to generate only ' wsu:Id="UsernameToken-2691004"
> '
>
> <wsse:UsernameToken
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
>
> wsu:Id="SecurityToken-9e141676-2400-4c6d-ab87-1d5af61729b3">
>
> What is this 'SecurityToken-9e141676-2400-4c6d-ab87-1d5af61729b3' ?
>
> How can I generate it in Java (using Axis 1.3 and wss4j) ?
>
> Required Security Header by other end( .Net WSE 3.0) ----
>
> <?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/08/addressing"
>
> 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">
> <soap:Header>
> <wsa:Action>
> http://www.test.com/api/ws/internal/testInfo
> </wsa:Action>
> <wsa:MessageID>
> urn:uuid:ca7e475b-484a-4bb8-974f-eb573438bb43
> </wsa:MessageID>
> <wsa:ReplyTo>
> <wsa:Address>
>
> http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous
> </wsa:Address>
> </wsa:ReplyTo>
> <wsa:To>
> http://localhost:8080/testapi/testwsapi.asmx
> </wsa:To>
> <wsse:Security soap:mustUnderstand="1">
> <wsu:Timestamp
>
> wsu:Id="Timestamp-c70b72e2-561c-4b18-bc4b-acf8c3896b14">
>
> <wsu:Created>2008-02-28T15:33:56Z</wsu:Created>
>
> <wsu:Expires>2008-02-28T15:38:56Z</wsu:Expires>
> </wsu:Timestamp>
> <wsse:UsernameToken
>
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
>
> wsu:Id="SecurityToken-9e141676-2400-4c6d-ab87-1d5af61729b3">
>
> <wsse:Username>santosh.ncstk@gmail.com</wsse:Username>
> <wsse:Password
>
> Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">
> SomePassword
> </wsse:Password>
>
> <wsse:Nonce>5SImW1gykzSPdeiWzcCdaQ==</wsse:Nonce>
>
> <wsu:Created>2008-02-28T15:33:56Z</wsu:Created>
> </wsse:UsernameToken>
> </wsse:Security>
> </soap:Header>
> <soap:Body>
> <SAN_Info
> xmlns="http://www.test.com/api/testing/ws/internal">
> <SAN_Request VendorId="TestVendor"
> VendorPassword="SomePassword"
>
> xmlns="http://www.test.com/api/testing/testinforequest">
> <Brand>SANBUS</Brand>
> <TourCode>GE</TourCode>
> <Code>80135</Code>
> </SAN_Request>
> </SAN_Info>
> </soap:Body>
> </soap:Envelope>
>
> Generated Security header By my side (Java- Axis 1.3 and wss4j
> )-----------------
>
> <?xml version="1.0" encoding="UTF-8"?>
> <soapenv:Envelope
> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
> xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
> <soapenv:Header>
> <wsse:Security
>
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
> soapenv:mustUnderstand="1">
> <wsse:UsernameToken
>
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
> wsu:Id="UsernameToken-2691004">
> <wsse:Username>
> santosh.ncstk@gmail.com
> </wsse:Username>
> <wsse:Password
>
> Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">
> SomePassword
> </wsse:Password>
>
> <wsse:Nonce>bGmGuPDxQw2kkR5R0zC/hA==</wsse:Nonce>
>
> <wsu:Created>2008-07-10T16:46:47.046Z</wsu:Created>
> </wsse:UsernameToken>
> <wsu:Timestamp
>
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
> wsu:Id="Timestamp-25899876">
>
> <wsu:Created>2008-07-10T16:46:47.015Z</wsu:Created>
>
> <wsu:Expires>2008-07-10T16:51:47.015Z</wsu:Expires>
> </wsu:Timestamp>
> </wsse:Security>
> <wsa:MessageID soapenv:mustUnderstand="0">
> uuid:c83b29b0-4e9f-11dd-8e1f-d019b0e90563
> </wsa:MessageID>
> <wsa:To soapenv:mustUnderstand="0">
> http://localhost:8080/testapi/testwsapi.asmx
> </wsa:To>
> <wsa:Action soapenv:mustUnderstand="0">
> http://www.test.com/api/testing/testinforequest
> </wsa:Action>
> <wsa:From soapenv:mustUnderstand="0">
> <wsa:Address>
>
> http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous
> </wsa:Address>
> </wsa:From>
> <wsa:ReplyTo soapenv:mustUnderstand="0">
> <wsa:Address>
>
> http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous
> </wsa:Address>
> </wsa:ReplyTo>
> </soapenv:Header>
> <soapenv:Body>
> <SAN_Info
> xmlns="http://www.test.com/api/testing/ws/internal">
> <SAN_Request VendorId="TestVendor"
> VendorPassword="SomePassword"
>
> xmlns="http://www.test.com/api/testing/testinforequest">
> <Brand>SANBUS</Brand>
> <TourCode>GE</TourCode>
> <Code>80135</Code>
> </SAN_Request>
> </SAN_Info>
> </soapenv:Body>
> </soapenv:Envelope>
>
>
> My client-config.wsdd ---------
>
> <?xml version="1.0" encoding="UTF-8"?>
> <deployment xmlns="http://xml.apache.org/axis/wsdd/"
> xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
> <transport name="http"
> pivot="java:org.apache.axis.transport.http.HTTPSender"/>
> <globalConfiguration>
> <requestFlow>
> <handler type="java:org.apache.ws.axis.security.WSDoAllSender" >
> <parameter name="action" value="Timestamp UsernameToken"/>
> <parameter name="user" value="santosh.ncstk@gmail.com"/>
> <parameter name="passwordCallbackClass"
> value="com.api.testing.ws.internal.PWCallback"/>
> <parameter name="passwordType" value="PasswordText"/>
> <parameter name="password" value="ppx13Z11"/>
> <parameter name="mustUnderstand" value="true" />
> <parameter name="addUTElements" value="Nonce Created"/>
> </handler>
> </requestFlow>
> </globalConfiguration>
> </deployment>
>
>
> By seeing the security header, we can say that it is
> username-token-profile-1.0.
>
> How to solve this.
>
>
>
> Please help me.
>
>
>
> Regards
> Santosh
>
>
>
>
> Fred Dushin-4 wrote:
>> Assuming you are signing the UsernameToken, you'd want a nonce in the
>> username token to thwart replay attacks.
>>
>> Note that the WSS4J runtime does not support nonce caching or
>> detection or replayed requests, so you'd have to implement this,
>> yourself.
>>
>> Obviously, you'd also need to sign and encrypt the message (and
>> response, likely) in order to get the same cryptographic level of
>> protection as you'd otherwise get from SSL. I can't think of a case
>> where you'd want to sign and encrypt the token, only, and not the
>> message, but I haven't given it much thought, either.
>>
>> In general, though, if you're using a transport protocol that supports
>> SSL (e.g., HTTP), you're better off using it, because you'd then
>> benefit from the symmetric key negotiated in the SSL handshake (hence
>> getting far better performance). Also, if you're bothering to use a
>> private key and cert on the client side to sign the message, you can
>> get an added level of protection by using client authentication,
>> through the SSL protocol. And if you're doing that, the motivation
>> for using a username and password diminishes. (Though if you do use a
>> username and password, even with SSL client authentication, you'll
>> likely still want to use a nonce to thwart replay; it entirely depends
>> on your trust model, at the server side.)
>>
>> Had to review some of this with the Iona security folks (Colm, Donal
>> Arundel, Eamonn Dwyer); thanks to them for setting me straight on this.
>>
>> -Fred
>>
>> On Jul 3, 2008, at 8:36 AM, Glen Mazza wrote:
>>
>>> Thanks, here's another question. If I'm using the UsernameToken
>>> profile, and
>>> I sign and encrypt the message, is it recommended to also use SSL on
>>> the
>>> transport layer, or would that be redundant? I would guess the
>>> answer is to
>>> use SSL but *not* basic authentication, because the BA part is more
>>> or less
>>> the same as provided by the username token information.
>>>
>>> Glen
>>>
>>>
>>> Robert Wierschke-2 wrote:
>>>> Hi,
>>>>
>>>> when you additionally sign the SOAP message the recipient can be
>>>> sure that
>>>> the message was not altered in transit. This cannot be achieved
>>>> with just
>>>> adding a UsernameToken.
>>>>
>>>> regards
>>>> robert
>>>>
>>>> 2008/6/23 Glen Mazza <gl...@gmail.com>:
>>>>
>>>>> Hello, I have an architectural question about using UsernameTokens
>>>>> (which
>>>>> I'm
>>>>> trying to do with CXF, which of course uses WSS4J behind the
>>>>> scenes). If
>>>>> we
>>>>> are using the UsernameToken profile, I can see why we need to
>>>>> encrypt the
>>>>> message with the server's public key (for confidentiality), but am
>>>>> unsure
>>>>> if
>>>>> we need to also sign the message with the client's private key.
>>>>> Is it
>>>>> redundant with UsernameToken profile to also sign the SOAP
>>>>> request? My
>>>>> first guess, is that by definition, one is using Usernames and
>>>>> Passwords
>>>>> for
>>>>> authentication, and hence would not need signing of the message as
>>>>> well,
>>>>> but
>>>>> am unsure here.
>>>>>
>>>>> Thanks,
>>>>> Glen
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/Using-UsernameTokens--also-need-to-sign-the-SOAP-message--tp18059742p18059742.html
>>>>> Sent from the WSS4J mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>>>>> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>>>>>
>>>>>
>>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Using-UsernameTokens--also-need-to-sign-the-SOAP-message--tp18059742p18258267.html
>>> Sent from the WSS4J mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: Using UsernameTokens--also need to sign the SOAP message?
Posted by sh_santosh <sa...@gmail.com>.
Dear all,
Hi Jose / all,
just one word away.
I am NOT able generate 'SecurityToken-9e141676-2400-4c6d-ab87-1d5af61729b3'
inside the wsse:UsernameToken tag.
In place of this i am able to generate only ' wsu:Id="UsernameToken-2691004"
'
<wsse:UsernameToken
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
wsu:Id="SecurityToken-9e141676-2400-4c6d-ab87-1d5af61729b3">
What is this 'SecurityToken-9e141676-2400-4c6d-ab87-1d5af61729b3' ?
How can I generate it in Java (using Axis 1.3 and wss4j) ?
Required Security Header by other end( .Net WSE 3.0) ----
<?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/08/addressing"
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">
<soap:Header>
<wsa:Action>
http://www.test.com/api/ws/internal/testInfo
</wsa:Action>
<wsa:MessageID>
urn:uuid:ca7e475b-484a-4bb8-974f-eb573438bb43
</wsa:MessageID>
<wsa:ReplyTo>
<wsa:Address>
http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous
</wsa:Address>
</wsa:ReplyTo>
<wsa:To>
http://localhost:8080/testapi/testwsapi.asmx
</wsa:To>
<wsse:Security soap:mustUnderstand="1">
<wsu:Timestamp
wsu:Id="Timestamp-c70b72e2-561c-4b18-bc4b-acf8c3896b14">
<wsu:Created>2008-02-28T15:33:56Z</wsu:Created>
<wsu:Expires>2008-02-28T15:38:56Z</wsu:Expires>
</wsu:Timestamp>
<wsse:UsernameToken
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
wsu:Id="SecurityToken-9e141676-2400-4c6d-ab87-1d5af61729b3">
<wsse:Username>santosh.ncstk@gmail.com</wsse:Username>
<wsse:Password
Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">
SomePassword
</wsse:Password>
<wsse:Nonce>5SImW1gykzSPdeiWzcCdaQ==</wsse:Nonce>
<wsu:Created>2008-02-28T15:33:56Z</wsu:Created>
</wsse:UsernameToken>
</wsse:Security>
</soap:Header>
<soap:Body>
<SAN_Info
xmlns="http://www.test.com/api/testing/ws/internal">
<SAN_Request VendorId="TestVendor"
VendorPassword="SomePassword"
xmlns="http://www.test.com/api/testing/testinforequest">
<Brand>SANBUS</Brand>
<TourCode>GE</TourCode>
<Code>80135</Code>
</SAN_Request>
</SAN_Info>
</soap:Body>
</soap:Envelope>
Generated Security header By my side (Java- Axis 1.3 and wss4j
)-----------------
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header>
<wsse:Security
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
soapenv:mustUnderstand="1">
<wsse:UsernameToken
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
wsu:Id="UsernameToken-2691004">
<wsse:Username>
santosh.ncstk@gmail.com
</wsse:Username>
<wsse:Password
Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">
SomePassword
</wsse:Password>
<wsse:Nonce>bGmGuPDxQw2kkR5R0zC/hA==</wsse:Nonce>
<wsu:Created>2008-07-10T16:46:47.046Z</wsu:Created>
</wsse:UsernameToken>
<wsu:Timestamp
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
wsu:Id="Timestamp-25899876">
<wsu:Created>2008-07-10T16:46:47.015Z</wsu:Created>
<wsu:Expires>2008-07-10T16:51:47.015Z</wsu:Expires>
</wsu:Timestamp>
</wsse:Security>
<wsa:MessageID soapenv:mustUnderstand="0">
uuid:c83b29b0-4e9f-11dd-8e1f-d019b0e90563
</wsa:MessageID>
<wsa:To soapenv:mustUnderstand="0">
http://localhost:8080/testapi/testwsapi.asmx
</wsa:To>
<wsa:Action soapenv:mustUnderstand="0">
http://www.test.com/api/testing/testinforequest
</wsa:Action>
<wsa:From soapenv:mustUnderstand="0">
<wsa:Address>
http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous
</wsa:Address>
</wsa:From>
<wsa:ReplyTo soapenv:mustUnderstand="0">
<wsa:Address>
http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous
</wsa:Address>
</wsa:ReplyTo>
</soapenv:Header>
<soapenv:Body>
<SAN_Info
xmlns="http://www.test.com/api/testing/ws/internal">
<SAN_Request VendorId="TestVendor"
VendorPassword="SomePassword"
xmlns="http://www.test.com/api/testing/testinforequest">
<Brand>SANBUS</Brand>
<TourCode>GE</TourCode>
<Code>80135</Code>
</SAN_Request>
</SAN_Info>
</soapenv:Body>
</soapenv:Envelope>
My client-config.wsdd ---------
<?xml version="1.0" encoding="UTF-8"?>
<deployment xmlns="http://xml.apache.org/axis/wsdd/"
xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
<transport name="http"
pivot="java:org.apache.axis.transport.http.HTTPSender"/>
<globalConfiguration>
<requestFlow>
<handler type="java:org.apache.ws.axis.security.WSDoAllSender" >
<parameter name="action" value="Timestamp UsernameToken"/>
<parameter name="user" value="santosh.ncstk@gmail.com"/>
<parameter name="passwordCallbackClass"
value="com.api.testing.ws.internal.PWCallback"/>
<parameter name="passwordType" value="PasswordText"/>
<parameter name="password" value="ppx13Z11"/>
<parameter name="mustUnderstand" value="true" />
<parameter name="addUTElements" value="Nonce Created"/>
</handler>
</requestFlow>
</globalConfiguration>
</deployment>
By seeing the security header, we can say that it is
username-token-profile-1.0.
How to solve this.
Please help me.
Regards
Santosh
Fred Dushin-4 wrote:
>
> Assuming you are signing the UsernameToken, you'd want a nonce in the
> username token to thwart replay attacks.
>
> Note that the WSS4J runtime does not support nonce caching or
> detection or replayed requests, so you'd have to implement this,
> yourself.
>
> Obviously, you'd also need to sign and encrypt the message (and
> response, likely) in order to get the same cryptographic level of
> protection as you'd otherwise get from SSL. I can't think of a case
> where you'd want to sign and encrypt the token, only, and not the
> message, but I haven't given it much thought, either.
>
> In general, though, if you're using a transport protocol that supports
> SSL (e.g., HTTP), you're better off using it, because you'd then
> benefit from the symmetric key negotiated in the SSL handshake (hence
> getting far better performance). Also, if you're bothering to use a
> private key and cert on the client side to sign the message, you can
> get an added level of protection by using client authentication,
> through the SSL protocol. And if you're doing that, the motivation
> for using a username and password diminishes. (Though if you do use a
> username and password, even with SSL client authentication, you'll
> likely still want to use a nonce to thwart replay; it entirely depends
> on your trust model, at the server side.)
>
> Had to review some of this with the Iona security folks (Colm, Donal
> Arundel, Eamonn Dwyer); thanks to them for setting me straight on this.
>
> -Fred
>
> On Jul 3, 2008, at 8:36 AM, Glen Mazza wrote:
>
>>
>> Thanks, here's another question. If I'm using the UsernameToken
>> profile, and
>> I sign and encrypt the message, is it recommended to also use SSL on
>> the
>> transport layer, or would that be redundant? I would guess the
>> answer is to
>> use SSL but *not* basic authentication, because the BA part is more
>> or less
>> the same as provided by the username token information.
>>
>> Glen
>>
>>
>> Robert Wierschke-2 wrote:
>>>
>>> Hi,
>>>
>>> when you additionally sign the SOAP message the recipient can be
>>> sure that
>>> the message was not altered in transit. This cannot be achieved
>>> with just
>>> adding a UsernameToken.
>>>
>>> regards
>>> robert
>>>
>>> 2008/6/23 Glen Mazza <gl...@gmail.com>:
>>>
>>>>
>>>> Hello, I have an architectural question about using UsernameTokens
>>>> (which
>>>> I'm
>>>> trying to do with CXF, which of course uses WSS4J behind the
>>>> scenes). If
>>>> we
>>>> are using the UsernameToken profile, I can see why we need to
>>>> encrypt the
>>>> message with the server's public key (for confidentiality), but am
>>>> unsure
>>>> if
>>>> we need to also sign the message with the client's private key.
>>>> Is it
>>>> redundant with UsernameToken profile to also sign the SOAP
>>>> request? My
>>>> first guess, is that by definition, one is using Usernames and
>>>> Passwords
>>>> for
>>>> authentication, and hence would not need signing of the message as
>>>> well,
>>>> but
>>>> am unsure here.
>>>>
>>>> Thanks,
>>>> Glen
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/Using-UsernameTokens--also-need-to-sign-the-SOAP-message--tp18059742p18059742.html
>>>> Sent from the WSS4J mailing list archive at Nabble.com.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>>>>
>>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Using-UsernameTokens--also-need-to-sign-the-SOAP-message--tp18059742p18258267.html
>> Sent from the WSS4J mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Using-UsernameTokens--also-need-to-sign-the-SOAP-message--tp18059742p18544864.html
Sent from the WSS4J mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: Using UsernameTokens--also need to sign the SOAP message?
Posted by Glen Mazza <gl...@gmail.com>.
Thanks for all the great information Fred, both here and on the CXF-dev
list...it's been very helpful.
Regards,
Glen
Fred Dushin-4 wrote:
>
> Assuming you are signing the UsernameToken, you'd want a nonce in the
> username token to thwart replay attacks.
>
> Note that the WSS4J runtime does not support nonce caching or
> detection or replayed requests, so you'd have to implement this,
> yourself.
>
> Obviously, you'd also need to sign and encrypt the message (and
> response, likely) in order to get the same cryptographic level of
> protection as you'd otherwise get from SSL. I can't think of a case
> where you'd want to sign and encrypt the token, only, and not the
> message, but I haven't given it much thought, either.
>
> In general, though, if you're using a transport protocol that supports
> SSL (e.g., HTTP), you're better off using it, because you'd then
> benefit from the symmetric key negotiated in the SSL handshake (hence
> getting far better performance). Also, if you're bothering to use a
> private key and cert on the client side to sign the message, you can
> get an added level of protection by using client authentication,
> through the SSL protocol. And if you're doing that, the motivation
> for using a username and password diminishes. (Though if you do use a
> username and password, even with SSL client authentication, you'll
> likely still want to use a nonce to thwart replay; it entirely depends
> on your trust model, at the server side.)
>
> Had to review some of this with the Iona security folks (Colm, Donal
> Arundel, Eamonn Dwyer); thanks to them for setting me straight on this.
>
> -Fred
>
> On Jul 3, 2008, at 8:36 AM, Glen Mazza wrote:
>
>>
>> Thanks, here's another question. If I'm using the UsernameToken
>> profile, and
>> I sign and encrypt the message, is it recommended to also use SSL on
>> the
>> transport layer, or would that be redundant? I would guess the
>> answer is to
>> use SSL but *not* basic authentication, because the BA part is more
>> or less
>> the same as provided by the username token information.
>>
>> Glen
>>
>>
>> Robert Wierschke-2 wrote:
>>>
>>> Hi,
>>>
>>> when you additionally sign the SOAP message the recipient can be
>>> sure that
>>> the message was not altered in transit. This cannot be achieved
>>> with just
>>> adding a UsernameToken.
>>>
>>> regards
>>> robert
>>>
>>> 2008/6/23 Glen Mazza <gl...@gmail.com>:
>>>
>>>>
>>>> Hello, I have an architectural question about using UsernameTokens
>>>> (which
>>>> I'm
>>>> trying to do with CXF, which of course uses WSS4J behind the
>>>> scenes). If
>>>> we
>>>> are using the UsernameToken profile, I can see why we need to
>>>> encrypt the
>>>> message with the server's public key (for confidentiality), but am
>>>> unsure
>>>> if
>>>> we need to also sign the message with the client's private key.
>>>> Is it
>>>> redundant with UsernameToken profile to also sign the SOAP
>>>> request? My
>>>> first guess, is that by definition, one is using Usernames and
>>>> Passwords
>>>> for
>>>> authentication, and hence would not need signing of the message as
>>>> well,
>>>> but
>>>> am unsure here.
>>>>
>>>> Thanks,
>>>> Glen
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/Using-UsernameTokens--also-need-to-sign-the-SOAP-message--tp18059742p18059742.html
>>>> Sent from the WSS4J mailing list archive at Nabble.com.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>>>>
>>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Using-UsernameTokens--also-need-to-sign-the-SOAP-message--tp18059742p18258267.html
>> Sent from the WSS4J mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Using-UsernameTokens--also-need-to-sign-the-SOAP-message--tp18059742p18263047.html
Sent from the WSS4J mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: Using UsernameTokens--also need to sign the SOAP message?
Posted by Fred Dushin <fa...@apache.org>.
Assuming you are signing the UsernameToken, you'd want a nonce in the
username token to thwart replay attacks.
Note that the WSS4J runtime does not support nonce caching or
detection or replayed requests, so you'd have to implement this,
yourself.
Obviously, you'd also need to sign and encrypt the message (and
response, likely) in order to get the same cryptographic level of
protection as you'd otherwise get from SSL. I can't think of a case
where you'd want to sign and encrypt the token, only, and not the
message, but I haven't given it much thought, either.
In general, though, if you're using a transport protocol that supports
SSL (e.g., HTTP), you're better off using it, because you'd then
benefit from the symmetric key negotiated in the SSL handshake (hence
getting far better performance). Also, if you're bothering to use a
private key and cert on the client side to sign the message, you can
get an added level of protection by using client authentication,
through the SSL protocol. And if you're doing that, the motivation
for using a username and password diminishes. (Though if you do use a
username and password, even with SSL client authentication, you'll
likely still want to use a nonce to thwart replay; it entirely depends
on your trust model, at the server side.)
Had to review some of this with the Iona security folks (Colm, Donal
Arundel, Eamonn Dwyer); thanks to them for setting me straight on this.
-Fred
On Jul 3, 2008, at 8:36 AM, Glen Mazza wrote:
>
> Thanks, here's another question. If I'm using the UsernameToken
> profile, and
> I sign and encrypt the message, is it recommended to also use SSL on
> the
> transport layer, or would that be redundant? I would guess the
> answer is to
> use SSL but *not* basic authentication, because the BA part is more
> or less
> the same as provided by the username token information.
>
> Glen
>
>
> Robert Wierschke-2 wrote:
>>
>> Hi,
>>
>> when you additionally sign the SOAP message the recipient can be
>> sure that
>> the message was not altered in transit. This cannot be achieved
>> with just
>> adding a UsernameToken.
>>
>> regards
>> robert
>>
>> 2008/6/23 Glen Mazza <gl...@gmail.com>:
>>
>>>
>>> Hello, I have an architectural question about using UsernameTokens
>>> (which
>>> I'm
>>> trying to do with CXF, which of course uses WSS4J behind the
>>> scenes). If
>>> we
>>> are using the UsernameToken profile, I can see why we need to
>>> encrypt the
>>> message with the server's public key (for confidentiality), but am
>>> unsure
>>> if
>>> we need to also sign the message with the client's private key.
>>> Is it
>>> redundant with UsernameToken profile to also sign the SOAP
>>> request? My
>>> first guess, is that by definition, one is using Usernames and
>>> Passwords
>>> for
>>> authentication, and hence would not need signing of the message as
>>> well,
>>> but
>>> am unsure here.
>>>
>>> Thanks,
>>> Glen
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Using-UsernameTokens--also-need-to-sign-the-SOAP-message--tp18059742p18059742.html
>>> Sent from the WSS4J mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>>>
>>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Using-UsernameTokens--also-need-to-sign-the-SOAP-message--tp18059742p18258267.html
> Sent from the WSS4J mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: Using UsernameTokens--also need to sign the SOAP message?
Posted by Glen Mazza <gl...@gmail.com>.
Thanks, here's another question. If I'm using the UsernameToken profile, and
I sign and encrypt the message, is it recommended to also use SSL on the
transport layer, or would that be redundant? I would guess the answer is to
use SSL but *not* basic authentication, because the BA part is more or less
the same as provided by the username token information.
Glen
Robert Wierschke-2 wrote:
>
> Hi,
>
> when you additionally sign the SOAP message the recipient can be sure that
> the message was not altered in transit. This cannot be achieved with just
> adding a UsernameToken.
>
> regards
> robert
>
> 2008/6/23 Glen Mazza <gl...@gmail.com>:
>
>>
>> Hello, I have an architectural question about using UsernameTokens (which
>> I'm
>> trying to do with CXF, which of course uses WSS4J behind the scenes). If
>> we
>> are using the UsernameToken profile, I can see why we need to encrypt the
>> message with the server's public key (for confidentiality), but am unsure
>> if
>> we need to also sign the message with the client's private key. Is it
>> redundant with UsernameToken profile to also sign the SOAP request? My
>> first guess, is that by definition, one is using Usernames and Passwords
>> for
>> authentication, and hence would not need signing of the message as well,
>> but
>> am unsure here.
>>
>> Thanks,
>> Glen
>> --
>> View this message in context:
>> http://www.nabble.com/Using-UsernameTokens--also-need-to-sign-the-SOAP-message--tp18059742p18059742.html
>> Sent from the WSS4J mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Using-UsernameTokens--also-need-to-sign-the-SOAP-message--tp18059742p18258267.html
Sent from the WSS4J mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: Using UsernameTokens--also need to sign the SOAP message?
Posted by Fred Dushin <fa...@apache.org>.
Also, usernames and passwords are inherently weak, and do not provide
nearly the same level of authentication as a digital signature. If
you are anything like me, you have 1 password for n accounts, which
kind of defeats the idea of a "shared secret".
-Fred
On Jun 23, 2008, at 6:23 AM, Robert Wierschke wrote:
> Hi,
>
> when you additionally sign the SOAP message the recipient can be
> sure that the message was not altered in transit. This cannot be
> achieved with just adding a UsernameToken.
>
> regards
> robert
>
> 2008/6/23 Glen Mazza <gl...@gmail.com>:
>
> Hello, I have an architectural question about using UsernameTokens
> (which I'm
> trying to do with CXF, which of course uses WSS4J behind the
> scenes). If we
> are using the UsernameToken profile, I can see why we need to
> encrypt the
> message with the server's public key (for confidentiality), but am
> unsure if
> we need to also sign the message with the client's private key. Is it
> redundant with UsernameToken profile to also sign the SOAP request?
> My
> first guess, is that by definition, one is using Usernames and
> Passwords for
> authentication, and hence would not need signing of the message as
> well, but
> am unsure here.
>
> Thanks,
> Glen
> --
> View this message in context: http://www.nabble.com/Using-UsernameTokens--also-need-to-sign-the-SOAP-message--tp18059742p18059742.html
> Sent from the WSS4J mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>
Re: Using UsernameTokens--also need to sign the SOAP message?
Posted by Robert Wierschke <wi...@googlemail.com>.
Hi,
when you additionally sign the SOAP message the recipient can be sure that
the message was not altered in transit. This cannot be achieved with just
adding a UsernameToken.
regards
robert
2008/6/23 Glen Mazza <gl...@gmail.com>:
>
> Hello, I have an architectural question about using UsernameTokens (which
> I'm
> trying to do with CXF, which of course uses WSS4J behind the scenes). If
> we
> are using the UsernameToken profile, I can see why we need to encrypt the
> message with the server's public key (for confidentiality), but am unsure
> if
> we need to also sign the message with the client's private key. Is it
> redundant with UsernameToken profile to also sign the SOAP request? My
> first guess, is that by definition, one is using Usernames and Passwords
> for
> authentication, and hence would not need signing of the message as well,
> but
> am unsure here.
>
> Thanks,
> Glen
> --
> View this message in context:
> http://www.nabble.com/Using-UsernameTokens--also-need-to-sign-the-SOAP-message--tp18059742p18059742.html
> Sent from the WSS4J mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>