Google Grupper understøtter ikke længere nye Usenet-opslag eller -abonnementer. Tidligere indhold er fortsat synligt.

Network Credentials with Web Service Client Proxy

8 visninger
Gå til det første ulæste opslag

Mark Hoekstra

ulæst,
6. feb. 2002, 18.55.4306.02.2002
til
I built a web service which will be called by an ASPX page.

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 Upadya

ulæst,
7. feb. 2002, 17.01.5507.02.2002
til
Are you using impersonation on ASP.NET app or webservice?

-Vijay

"Mark Hoekstra" <mark_h...@hotmail.com> wrote in message
news:OUaCPn2rBHA.2520@tkmsftngp04...

Mark Hoekstra

ulæst,
8. feb. 2002, 14.00.4108.02.2002
til
Yes, the following is in both web forms WEB.CONFIG as well as the
webservice's WEB.CONFIG :
<authentication mode="Windows" />

<identity impersonate="true" />


<authorization>

<allow users="*" />

<deny users="?" />

</authorization>

"Vijay Upadya" <VijayU...@microsoft.com> wrote in message
news:#0SGWMCsBHA.2432@tkmsftngp07...

Rich Thurman [MS]

ulæst,
11. feb. 2002, 14.37.0111.02.2002
til
Remove the <identity impersonate="true" /> Tag in the <br>WebService's
web.config file. It should then work.

Thanks,

Rich

This posting is provided "AS IS" with no warranties, and confers no rights.

Mark Hoekstra

ulæst,
11. feb. 2002, 18.15.5211.02.2002
til
Thank you very much for the help.

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...

Scott Clark

ulæst,
12. feb. 2002, 13.58.5512.02.2002
til
NTLM is limited to a single network hop. Kerberos allows multiple
hops. I'm not sure how to specify Kerberos instead of NTLM. I
thought it was the default for Win2K machines. Are all of the
machines involved Win2K machines?

"Mark Hoekstra" <mark_h...@hotmail.com> wrote in message news:<uNXKXI1sBHA.1452@tkmsftngp05>...

Rich Thurman [MS]

ulæst,
12. feb. 2002, 15.35.2912.02.2002
til
I dont know what I was thinking when I sent that response, please excuse
me. I re-read your original post and I think I understand what is
happening in your scnearios. Acutally, in your last post the comment on NT
security made it go 'click'. When running a server application, there
are two modes of operation with respect to the current security context:
running everything in the context of the process or running a request in
the context of the entity making the request. This second concept is known
as impersonation and involves places the security token for the
authenticated or anonymous user on the thread used to service the request.

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

Mark Hoekstra

ulæst,
22. feb. 2002, 17.52.0322.02.2002
til
XP machines. Web Services are unstable under heavier loads on WIN2K boxes.


"Scott Clark" <sco...@hotmail.com> wrote in message
news:22a17132.02021...@posting.google.com...

0 nye opslag