1) The client has the UT.
equiv. Regardless of (none, hashed, sendplain)
3) In the reply, just encrypt/sign with the UT.
reply automatically as the UT is cached. (maybe you need the cache the UT
That said, I would not use a UT for this anyway for security reasons. I
"Burton Rodman" <BurtonRodman@discussions.microsoft.com> wrote in message
news:E71C4034-58CF-46F7-BC06-296660FA5ECC@microsoft.com...
> since you are signing the message, one option you have is to set the
> client
> to not send the password. WSE will automatically "verify the password"
> based
> on verifying the message signature (since the password was used to
> generate
> the signature).
>
> depending on the level of security you're going for, you have two options
> to
> encrypt the response:
> echo the usernametoken back and resign and encrypt the message with the
> original token
> or
> sign and encrypt the response with an X.509 cert.
>
> i'm not real sure exactly how secure resigning the response with the
> original token is. could someone comment on this??
>
>
>
> "Chris Arnold" wrote:
>
>> Thanks Pablo.
>>
>> I am now attaching a UsernameToken to the Response message sent from the
>> server. However, when I try to implement my own UsernameTokenManager on
>> the
>> client it fails to load with the following exception ...
>>
>> System.Configuration.ConfigurationException: WSE032: There was an error
>> loading the microsoft.web.services2 configuration section. --->
>> System.Configuration.ConfigurationException: WSE040: Type
>> WSE_Test.ClientUsernameTokenManager, ClientUsernameTokenManager could not
>> be
>> loaded. Please check the configuration file.
>> at
>> Microsoft.Web.Services2.Security.Configuration.SecurityConfiguration.LoadSecurityTokenManager(String
>> typeName, String configSection, XmlNodeList configData)
>> at
>> Microsoft.Web.Services2.Security.Configuration.SecurityConfiguration.ParseSecurityTokenManager(XmlElement
>> child)
>> at
>> Microsoft.Web.Services2.Security.Configuration.SecurityConfiguration.Load(XmlNode
>> section)
>> at
>> Microsoft.Web.Services2.Configuration.WebServicesConfiguration.System.Configuration.IConfigurationSectionHandler.Create(Object
>> parent, Object configContext, XmlNode section)
>> at
>> System.Configuration.ConfigurationRecord.EvaluateRecursive(IConfigurationSectionHandler
>> factory, Object config, String[] keys, Int32 iKey, XmlTextReader reader)
>> at System.Configuration.ConfigurationRecord.Evaluate(String configKey)
>> at System.Configuration.ConfigurationRecord.ResolveConfig(String
>> configKey)
>> at System.Configuration.ConfigurationRecord.GetConfig(String
>> configKey)
>> at
>> System.Configuration.DefaultConfigurationSystem.System.Configuration.IConfigurationSystem.GetConfig(String
>> configKey)
>> at System.Configuration.ConfigurationSettings.GetConfig(String
>> sectionName)
>> at
>> Microsoft.Web.Services2.Configuration.WebServicesConfiguration.Initialize()
>> --- End of inner exception stack trace ---
>>
>>
>>
>> I have just copied the settings from the Web.config file of my web
>> service
>> and entered it in the App.config file of my client - but I'm obviously
>> doing
>> something wrong! Anyone got any examples of Authentication etc on the
>> client
>> side?
>>
>>
>>
>> "Pablo Cibraro" <pcibraro@hotmail.com> wrote in message
>> news:ekn7tf4wFHA.2212@TK2MSFTNGP15.phx.gbl...
>> > Hi Chris,
>> > The answer is no. You are only protecting the request message, so you
>> > will
>> > have to do the same for the response message.
>> >
>> > Regards,
>> > Pablo Cibraro
>> >
www.lagash.com >> >
>> >
>> > "Chris Arnold" <chris.arnold@data-interface.net> wrote in message
>> > news:%23xwxHy3wFHA.1488@TK2MSFTNGP10.phx.gbl...
>> >> Hi All,
>> >>
>> >> If I call a WebMethod and supply a UsernameToken, a MessageSignature
>> >> and
>> >> an EncrypedData object I know that my message to the server is secure.
>> >>
>> >> If I do nothing other than return the 'result' in my WebMethod, is the
>> >> Response sent back to the client secure?
>> >>
>> >> If so, is it automatically Encrypted & Signed with the Security Token
>> >> the
>> >> client sent in the Request?
>> >>
>> >> Chris
>> >>
>> >
>> >
>>
>>
>>