How to add username and password to a Web Service

[Anthony Biondo Jr]

I have seen examples of people saying that in the soap header you can pass a
username and password. Is there a reason why putting username and password
information in the header would be better than just including it as an input
in the web service?

thanks,
Anthony

[linhardt]

Passing a username/password in plain-text in either the header or input
of a web service is inherently unsecure.

Microsoft offers a more secure way to do this in Web Service
Enhancements (WSE). The sample code offers examples of how to use the
UserNameTokenManager.

A fairly good article the WSE 2.0 UserNameTokenManager can be found at
http://aspnet.4guysfromrolla.com/articles/071404-1.aspx

-Paul

Anthony Biondo Jr wrote:

I have seen examples of people saying that in the soap header you can pass a
username and password. Is there a reason why putting username and password
information in the header would be better than just including it as an input
in the web service?

thanks,
Anthony

[John Saunders]

"Anthony Biondo Jr" <an************@kmhp.comwrote in message
news:uF****************@TK2MSFTNGP02.phx.gbl...

>I have seen examples of people saying that in the soap header you can pass
a
username and password. Is there a reason why putting username and
password
information in the header would be better than just including it as an
input
in the web service?

"It depends." (anon)

If your web service has more than one operation which has to be secured by
username/password, then putting it in the header keeps them out of the
signature of each operation.

Also, you may be able to have a SOAP extension (I think they're called
handlers in the Java world) process that header for every operation, so that
the operations don't need to do anything. You could even prevent the
operations from even being called if the username and password were
incorrect.

Finally, if you later decide that you need something stronger than username
and password, you would only need to change the header, not each operation.

John