Hi Shailendra,

Ahhh.  I see.  Your choices for not breaking any existing clients are
indeed limited, if, that is, there have previously been no attempts to
ascertain the identity of the callers.  The simplest option is to use
windows domain security (e.g. turn off basic authentication).  But this
requires a line of code be added to the calling client applications so that
the current user credentials are set in the client proxy.

In your case, you will I think have to decide how big a break you want to
introduce.  One approach is to keep the current interface while preparing a
new one, and then telling people that the time window for the unsecured
access is limited and that to have uninterupted use of the application,
they will have to upgrade.  Then in the upgraded client, simply add in
windows security and make it point to a copy of the service on a different
VROOT that has basic auth turned off.  This will let you gracefully start
kicking people off.

Another option you might want to consider is port filtering.  If you can be
assured of the TCP/IP ranges or address of authorized callers, you can add
these to the IIS port filtering list in the existing web service.  This can
be somewhat disruptive as it takes some time to fill the list, and as soon
as you enable port filtering, only those ranges or addresses in the list
will be allowed to place a call to the endpoint.

Adding in WSE or WS-Security is something to still consider - but it is a
pretty heavy hammer if you are in a position to use domain credentials.

Hope this helps,

Dan Rogers
Microsoft Corporation

--------------------

<YwDZLjCzEHA.764@cpmsftngxa10.phx.gbl>

cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP14
.phx.gbl

microsoft.public.dotnet.framework.aspnet.webservices:26641

microsoft.public.dotnet.framework.aspnet.webservices,microsoft.public.dotnet

framework.webservices,microsoft.public.dotnet.framework.webservices.enhance

cpmsftngxa10.phx.gbl!TK2MSFTFEED01.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP14