A web proxy is established in an ASPX page which is directly called by the
browser. I set the WebProxy.Credentials =
System.Net.CredentialCache.DefaultCredentials
This works fine when the web app and web service are on the same machine. Is
there a way to uncouple the dependency of hosting the ASPX and ASMX on the
same box? How will this work under network load balancing when I can't
guarantee that they will be running on the same server?
The following scenarios work:
Browser on machine1
WebForm1.ASPX on machine1
WebService.ASMX on machine1
Browser on machine1
WebForm1.ASPX on machine1
WebService.ASMX on machine2
Browser on machine1
WebForm1.ASPX on machine2
WebService.ASMX on machine2
This returns an HTTP status 401: Unauthorized
Browser on machine2
WebForm1.ASPX on machine1
WebService.ASMX on machine2
Browser on machine3
WebForm1.ASPX on machine1
WebService.ASMX on machine2
-Vijay
"Mark Hoekstra" <mark_h...@hotmail.com> wrote in message
news:OUaCPn2rBHA.2520@tkmsftngp04...
<identity impersonate="true" />
<authorization>
<allow users="*" />
<deny users="?" />
</authorization>
"Vijay Upadya" <VijayU...@microsoft.com> wrote in message
news:#0SGWMCsBHA.2432@tkmsftngp07...
Thanks,
Rich
This posting is provided "AS IS" with no warranties, and confers no rights.
Unfortunately, it still behaves the same way when I remove the identity
element from the web.config file.
I am not an expert on the NT security system, but could it be a problem with
the authentication token being proxied through too many machines?
The following work, only passing my authentication token between two
comupters.
Browser -> ASPX -> ASMX
Machine1 -> Machine1 -> Machine2
Machine1 -> Machine2 -> Machine2
The following don't work, passing the token through, effectively, three
machines.
Browser -> ASPX -> ASMX
Machine2 -> Machine1 -> Machine2 (Even though Machine2 is the first and
third on the calling chain, the authentication is still being passed between
computers twice.)
Machine1 -> Machine2 -> Machine3
Any more help you could offer would be GREATLY appreciated!
"Rich Thurman [MS]" <rthu...@microsoft.com> wrote in message
news:P6dVTOzsBHA.1516@cpmsftngxa08...
"Mark Hoekstra" <mark_h...@hotmail.com> wrote in message news:<uNXKXI1sBHA.1452@tkmsftngp05>...
When impersonation is used, the thread is running in the context of the
request entity and will access resources on the server machine as that
entity. When code tries to leave the web server machine, another concept
known as delegation comes into play. When you try to leave the machine
with an impersonated identity, you only leave the machine as that identity
if the token has network credentials. Otherwise, you leave the machine as
the anonymous user (NT AUTHORITY\ANONYMOUS LOGON).
Unconstrained delegation is inherently dangerous: it gives the server the
right to act as the authenticated user anywhere they have access on the
network. For that reason, many corporations don’t have accounts and
machines configured in AD as trusted for delegation on corporate networks.
There are a number of factors that dictate whether or not the security
context is delegatable. For Windows 2000, if the anonymous account
configured in IIS
is a local account, it’s not delegatable unless both
machines have identical local accounts (passwords and all). If it’s a
domain account, it’s delegatable.
If Basic auth is used with local accounts, it’s delegatable if both local
accounts are identical (have the same password). With domain accounts, it’
s delegatable.
Digest is not delegatable.
Integrated auth usually results in the use of the SPNEGO protocol which
negotiates the use of Kerberos or NTLM.
NTLM is not delegatable.
Kerberos is delegatable if the environment is configured to support it.
For more information on this, please refer to “Designing Secure Web
Applications on Windows 2000” in the resources section.
Client Certificates is delegatable if used with IIS mapping and identical
local accounts or domain accounts. This works because credentials are
stored for the mapping on the machine and used to do an interactive logon.
If used with AD mapping, it’s not delegatable.
A great place to get more information on the various authentication types,
what privileges they require, and how they work with respect to delegation
can be found in Appendix D of “Designing Secure Web-Based Applications for
Windows 2000”.
In other words:
When IIS/ASP/ASP.NET impersonates using "Windows" auth., it uses
challenge/response to get a network logon token which can only be used
locally, it can’t go off the box which is what you want. Try it with basic
auth. instead. In that case the IIS server actually gets the password and
can do an interactive login, which can make one more hop, but really, this
is not always the case. The best thing I can recomend to you is to read
the following:
Q229694 How to Use the IIS Security "What If" Tool
http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q229694
"Scott Clark" <sco...@hotmail.com> wrote in message
news:22a17132.02021...@posting.google.com...