Home All Groups Group Topic Archive Search About

Using HttpContext from a web server?

Author
13 Apr 2005 4:01 PM
Jeff Connelly
This doesn't work like I'd expect.  Looking at this page
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetAP05.asp

Table 4 IIS Integrated Windows, impersonate false, authentication mode
Windows.  It seems to be saying that HttpContext.Current.User.Identity
should give the identity of the user that's been authenticated.  However,
it's always MACHINE\APSNET, just like WindowsIdentity.

For the web service side, I have anonymous access off, and Integrated
Windows Auth on.  There is a function called HelloWorld().  On the client
side, I have

localhost.Service1 myProxy = new localhost.Service1();
myProxy.PreAuthenticate = true;  // don't know if important, I just tried it
myProxy.Credentials = System.Net.CredentialCache.DefaultCredentials;
Response.Write(myProxy.HelloWorld());

On the server side (Service1), HelloWorld() simply returns
HttpContext.Current.User.Identity.Name, and it's always MACHINE\APSNET, not
the name of the currently logged on client user (which is what I thought
DefaultCredentials sent).  Any clues?

Author
13 Apr 2005 5:12 PM
Nicole Calinoiu
"Jeff Connelly" <nom***@thank.you> wrote in message
news:u0dM8IEQFHA.4024@TK2MSFTNGP10.phx.gbl...
> This doesn't work like I'd expect.  Looking at this page
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetAP05.asp
>
> Table 4 IIS Integrated Windows, impersonate false, authentication mode
> Windows.  It seems to be saying that HttpContext.Current.User.Identity
> should give the identity of the user that's been authenticated.  However,
> it's always MACHINE\APSNET, just like WindowsIdentity.
>
> For the web service side, I have anonymous access off, and Integrated
> Windows Auth on.

In IIS, or just in your web.config file?  If IIS is set to allow only
Windows integrated authentication for the web service file, you really
should be seeing the client user identified via the HttpContext user.  If
this still doesn't work, rebooting the machine might help.  If if doesn't,
could you please indicate what versions of Windows and the .NET Framework
you are using?




Show quoteHide quote
> There is a function called HelloWorld().  On the client side, I have
>
> localhost.Service1 myProxy = new localhost.Service1();
> myProxy.PreAuthenticate = true;  // don't know if important, I just tried
> it
> myProxy.Credentials = System.Net.CredentialCache.DefaultCredentials;
> Response.Write(myProxy.HelloWorld());
>
> On the server side (Service1), HelloWorld() simply returns
> HttpContext.Current.User.Identity.Name, and it's always MACHINE\APSNET,
> not the name of the currently logged on client user (which is what I
> thought DefaultCredentials sent).  Any clues?
>
Author
13 Apr 2005 6:06 PM
Jeff Connelly
Show quote Hide quote
"Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
news:uaPKGwEQFHA.508@TK2MSFTNGP12.phx.gbl...
> "Jeff Connelly" <nom***@thank.you> wrote in message
> news:u0dM8IEQFHA.4024@TK2MSFTNGP10.phx.gbl...
>> This doesn't work like I'd expect.  Looking at this page
>> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetAP05.asp
>>
>> Table 4 IIS Integrated Windows, impersonate false, authentication mode
>> Windows.  It seems to be saying that HttpContext.Current.User.Identity
>> should give the identity of the user that's been authenticated.  However,
>> it's always MACHINE\APSNET, just like WindowsIdentity.
>>
>> For the web service side, I have anonymous access off, and Integrated
>> Windows Auth on.
>
> In IIS, or just in your web.config file?  If IIS is set to allow only
> Windows integrated authentication for the web service file, you really
> should be seeing the client user identified via the HttpContext user.  If
> this still doesn't work, rebooting the machine might help.  If if doesn't,
> could you please indicate what versions of Windows and the .NET Framework
> you are using?

In web.config, I have <authentication mode="Windows"/>.  In IIS, I have
Anonymous access off and Integrated Windows authorization on.  Rebooting did
not seem to help.  I'm using Visual C# .NET 1.1, and Windows XP Pro version
2002 SP2.
Author
13 Apr 2005 7:58 PM
Nicole Calinoiu
Weird...  Is it remotely possible that the client application is actually
running in the context of the ASPNET account?  If not, is your web service
application using any custom HTTP handlers or modules (as specified in
machine.config or its web.config)?


Show quoteHide quote
"Jeff Connelly" <nom***@thank.you> wrote in message
news:O8zh2OFQFHA.248@TK2MSFTNGP15.phx.gbl...
>
> "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
> news:uaPKGwEQFHA.508@TK2MSFTNGP12.phx.gbl...
>> "Jeff Connelly" <nom***@thank.you> wrote in message
>> news:u0dM8IEQFHA.4024@TK2MSFTNGP10.phx.gbl...
>>> This doesn't work like I'd expect.  Looking at this page
>>> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetAP05.asp
>>>
>>> Table 4 IIS Integrated Windows, impersonate false, authentication mode
>>> Windows.  It seems to be saying that HttpContext.Current.User.Identity
>>> should give the identity of the user that's been authenticated.
>>> However, it's always MACHINE\APSNET, just like WindowsIdentity.
>>>
>>> For the web service side, I have anonymous access off, and Integrated
>>> Windows Auth on.
>>
>> In IIS, or just in your web.config file?  If IIS is set to allow only
>> Windows integrated authentication for the web service file, you really
>> should be seeing the client user identified via the HttpContext user.  If
>> this still doesn't work, rebooting the machine might help.  If if
>> doesn't, could you please indicate what versions of Windows and the .NET
>> Framework you are using?
>
> In web.config, I have <authentication mode="Windows"/>.  In IIS, I have
> Anonymous access off and Integrated Windows authorization on.  Rebooting
> did not seem to help.  I'm using Visual C# .NET 1.1, and Windows XP Pro
> version 2002 SP2.
>
Author
13 Apr 2005 9:07 PM
Jeff Connelly
"Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
news:Oix3dMGQFHA.2604@TK2MSFTNGP10.phx.gbl...
> Weird...  Is it remotely possible that the client application is actually
> running in the context of the ASPNET account?

Not sure what that means.  Is it that they're both web services?  I'm
thinking that might be the problem.  As I mentioned in my other post, it
seems to work fine in our real app, where the client is a standalone app.
In my test app, it was web service to web service.
Author
14 Apr 2005 12:44 AM
Joe Kaplan (MVP - ADSI)
Ah, web service to web service could result in the Context.User on the
target server being the ASPNET account.  If you have some code running in
ASP.NET which is not impersonating another account, it will run as the
process account which is the ASPNET account by default on Win2K.  Then, if
you do a web service call or use HttpWebRequest with DefaultCredentials to
call a different web service, the credentials sent with the web service
client will be the ASPNET account.

It might even work if there were both the same server.  I'd be very
surprised if that worked going to a different server though as the second
server probably would not be able to authenticate a local machine account on
a different machine.

Joe K.

Show quoteHide quote
"Jeff Connelly" <nom***@thank.you> wrote in message
news:%23S9z6zGQFHA.3544@TK2MSFTNGP12.phx.gbl...
>
> "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
> news:Oix3dMGQFHA.2604@TK2MSFTNGP10.phx.gbl...
>> Weird...  Is it remotely possible that the client application is actually
>> running in the context of the ASPNET account?
>
> Not sure what that means.  Is it that they're both web services?  I'm
> thinking that might be the problem.  As I mentioned in my other post, it
> seems to work fine in our real app, where the client is a standalone app.
> In my test app, it was web service to web service.
>
Author
14 Apr 2005 11:42 AM
Nicole Calinoiu
"Jeff Connelly" <nom***@thank.you> wrote in message
news:%23S9z6zGQFHA.3544@TK2MSFTNGP12.phx.gbl...
>
> "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
> news:Oix3dMGQFHA.2604@TK2MSFTNGP10.phx.gbl...
>> Weird...  Is it remotely possible that the client application is actually
>> running in the context of the ASPNET account?
>
> Not sure what that means.  Is it that they're both web services?  I'm
> thinking that might be the problem.  As I mentioned in my other post, it
> seems to work fine in our real app, where the client is a standalone app.
> In my test app, it was web service to web service.

As already mentioned by Joe, it makes perfect sense for
CredentialCache.DefaultCredentials to return the ASPNET account credentials
when run from a web service.  I'm a little curious as to which account
credentials you thought ought to have been returned instead and why?
Author
14 Apr 2005 2:05 PM
Jeff Connelly
"Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
news:ewmXDgOQFHA.1500@TK2MSFTNGP09.phx.gbl...
>
> As already mentioned by Joe, it makes perfect sense for
> CredentialCache.DefaultCredentials to return the ASPNET account
> credentials when run from a web service.  I'm a little curious as to which
> account credentials you thought ought to have been returned instead and
> why?

Well, not really knowing what I was doing, of course I expected the user
name of the person starting the first web service.  But in thinking about
it, I think I understand why the first web service would not have those
credentials by default.  It was not told any differently, as the second web
service was.  Thanks for the help all.
Author
13 Apr 2005 8:02 PM
Jeff Connelly
"Jeff Connelly" <nom***@thank.you> wrote in message
news:u0dM8IEQFHA.4024@TK2MSFTNGP10.phx.gbl...
> This doesn't work like I'd expect.  Looking at this page

When I went back and tried this in our actual application, it seemed to work
fine.  It didn't work in my simple test app, and I figured if I couldn't get
it to work there, why try the more complicated one?  It's a mystery, but it
seems to work, thanks all.