T
Terry Mitchell
I was just scanning through some groups looking for info
on a somewhat related issue, and noticed this thread. Not
sure if this will help, but here's some of what I've
discovered during my research on Web Services and security.
If you are using any type of authentication on the Web
Service Site, the first request will always fail because
the credentials are not in the initial post to the site.
As was noted (i think) in an earlier message, the site
returns an access denied to the browser (including the
necessary credential type for the site), or calling IIS
server. Then the browser send the correct type and the
second try works.
If you are using I.E. to call the service directly, then
the browser will keep the connection open and won't have
to keep re-connecting and re-authenticating. If you are
using a .NET site (code behind or component) then you are
creating a proxy to call the site. In this case there is
a property that can be set called PreAuthenticate that is
supposed to send the header the first time, eliminating
the multiple trips (though there seems to be issues when
using NTLM authentication).
The bad news is that the current release of 1.0 (with
service packs) won't keep a connection open between an
IIS/ASP.NET web application and another IIS/ASP.NET web
service when using NTLM authentication. So, if you make
multiple calls in a single page, you will get tagged wtih
a serious performance hit (this is the problem I'm trying
to solve) because the connection has to be re-established
and authentication renegotiated. There is a hot fix that
I'm trying to get from MS to help with this connection
dropping business by keeping connections open and sharing
them between requests, but this too will have issues if
the authenticated context can't be shared between users
(which it likely cannot in most applications, becuase you
would lose the granularity of per-user security).
Hope this has helped some. If not, at least I got my
fingers warmed up for the rest of the day...
Terry
on a somewhat related issue, and noticed this thread. Not
sure if this will help, but here's some of what I've
discovered during my research on Web Services and security.
If you are using any type of authentication on the Web
Service Site, the first request will always fail because
the credentials are not in the initial post to the site.
As was noted (i think) in an earlier message, the site
returns an access denied to the browser (including the
necessary credential type for the site), or calling IIS
server. Then the browser send the correct type and the
second try works.
If you are using I.E. to call the service directly, then
the browser will keep the connection open and won't have
to keep re-connecting and re-authenticating. If you are
using a .NET site (code behind or component) then you are
creating a proxy to call the site. In this case there is
a property that can be set called PreAuthenticate that is
supposed to send the header the first time, eliminating
the multiple trips (though there seems to be issues when
using NTLM authentication).
The bad news is that the current release of 1.0 (with
service packs) won't keep a connection open between an
IIS/ASP.NET web application and another IIS/ASP.NET web
service when using NTLM authentication. So, if you make
multiple calls in a single page, you will get tagged wtih
a serious performance hit (this is the problem I'm trying
to solve) because the connection has to be re-established
and authentication renegotiated. There is a hot fix that
I'm trying to get from MS to help with this connection
dropping business by keeping connections open and sharing
them between requests, but this too will have issues if
the authenticated context can't be shared between users
(which it likely cannot in most applications, becuase you
would lose the granularity of per-user security).
Hope this has helped some. If not, at least I got my
fingers warmed up for the rest of the day...
Terry