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>[EMAIL PROTECTED]</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> >> [EMAIL PROTECTED] >> </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="[EMAIL PROTECTED]"/> >> <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 <[EMAIL PROTECTED]>: >>>>> >>>>>> 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: [EMAIL PROTECTED] >>>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>>> >>>>>> >>>>> >>>> -- >>>> 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: [EMAIL PROTECTED] >>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
