WS-Security Best Practice?

[Brian Greiwe]

I'm new to Webservices, but nonetheless have taken the leap!

I have a ws I'm writing that will be used in a subscription. Nothing
huge or confidential. The client will pass in standard parms and get
back a data string. There is no need for the return value to be
encrypted/protected/etc, as it does not contain any private data.

However, I want to ensure that the caller has priveleges to the
service...based on a subscription. Basically, I want to verify the
caller is who they say they are, and preferable make it so they can't
simply give away their username and password to a buddy and in essence
giving someone else a free subscription.

Any advice on the best approach here? I've read many blogs, postings,
and white papers...from custom made db security to WS-Security, to WSE
2.0. I'm looking for the best performance and cost effective
solution.

Any input and advice is welcomed!!!

Thanks,
Brian

 

[Jan Tielens]

Do you want to use your web service in a intranet, or through the internet?
The easiest solution is using integrated Windows authentication, but it will
only work in an intranet envirionment.

--
Greetz

Jan Tielens
________________________________
Read my weblog: http://weblogs.asp.net/jan

 

[Brian Greiwe]

This is intended to be provided over the internet on a subscription
basis. So, no not intranet, which I guess rules out Windows
Authentication.

 

[Jan Tielens]

A common used solution is to put a username/password (or ticket) in the soap
header. Here are some links:

http://www.codeproject.com/cs/webservices/authforwebservices.asp#xx561031xx

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnservice/html/service06182002.asp

 

[Brian Greiwe]

Jan -

Thanks for all the information. I've begun implementing the SOAP
headers and it makes sense, however, it is obvious that users could
simply pass off their usernames and passwords to others and then
"foil" the subscription. Is there a way to validate the origin? Say
capturing the IP address or anything?

Thanks,
Brian

 

[Jan Tielens]

Sure you can get the IP address of the computer that is calling.
this.Context.Request.ServerVariables["REMOTE_ADDR"]

Or you could use client and server side certificates to make it even more
secure.

--
Greetz

Jan Tielens
________________________________
Read my weblog: http://weblogs.asp.net/jan

 

[Brian Greiwe]

Jan -

Thanks again for the help.

I just read your article on MSDN on throwing Soap exceptions, so I
wanted to tie that into my validation.

Right now, my validation method (AuthenticateCall) has dual levels of
try/catch (one for the exception and one for the SOAP).

Since AuthenticateCall will be called from within each web method, do
I need to remove the SOAP exception from within the AuthenticateCall
and trap it at the top level? Or keep it there and mimic it again at
the top level call? I just wante do make sure that I can pass back
any appropriate messages for failures (first for authentication, and
secondly for any actual method/data failure).

thanks,
Brian

Sure you can get the IP address of the computer that is calling.
this.Context.Request.ServerVariables["REMOTE_ADDR"]

Or you could use client and server side certificates to make it even more
secure.

--
Greetz

Jan Tielens
________________________________
Read my weblog: http://weblogs.asp.net/jan

Jan -

Thanks for all the information. I've begun implementing the SOAP
headers and it makes sense, however, it is obvious that users could
simply pass off their usernames and passwords to others and then
"foil" the subscription. Is there a way to validate the origin? Say
capturing the IP address or anything?

Thanks,
Brian

 

[Brian Greiwe]

Never mind - answered my own question. Thanks though!

Jan -

Thanks again for the help.

I just read your article on MSDN on throwing Soap exceptions, so I
wanted to tie that into my validation.

Right now, my validation method (AuthenticateCall) has dual levels of
try/catch (one for the exception and one for the SOAP).

Since AuthenticateCall will be called from within each web method, do
I need to remove the SOAP exception from within the AuthenticateCall
and trap it at the top level? Or keep it there and mimic it again at
the top level call? I just wante do make sure that I can pass back
any appropriate messages for failures (first for authentication, and
secondly for any actual method/data failure).

thanks,
Brian

Sure you can get the IP address of the computer that is calling.
this.Context.Request.ServerVariables["REMOTE_ADDR"]

Or you could use client and server side certificates to make it even more
secure.

--
Greetz

Jan Tielens
________________________________
Read my weblog: http://weblogs.asp.net/jan

Jan -

Thanks for all the information. I've begun implementing the SOAP
headers and it makes sense, however, it is obvious that users could
simply pass off their usernames and passwords to others and then
"foil" the subscription. Is there a way to validate the origin? Say
capturing the IP address or anything?

Thanks,
Brian