Set a break point in the AuthenticateToken method. If the break point is
not hit (I had this problem before), check:
1) You are actually sending a UT.
2) The token is already cached. In which case the Auth method is not run as
it finds the UT in cache.
3) Related to 2. If client and server is in same AppDomain, I think the UT
is cached when you create it on the client side so the server side "sees" it
cached, hence does not run the Auth method. IIRC, you can get other strange
side effects using the same appdomain. The solution is to break the app
into two projects. A client and a server. Have your default project in the
solution be the server project and start it. Start the client project from
the right-click "Debug/Start new instance" menu command in Solution
explorer. Now you have two processes/appdomains and you should hit your
break point in the Auth method the first time. The next time it will have
been cached and method should not run until the UT expires (see Note).
Note: You can also override CacheSecurityToken() method and just return so
as not cache the UT. That way, the Auth method should run each time. You
can use that for testing to verify things. Normally, you would not override
this method.
--
William Stacey, MVP
http://mvp.support.microsoft.com
"Buddy Ackerman" <bu**********@buddyackerman.com> wrote in message
news:#l**************@TK2MSFTNGP12.phx.gbl...
hmmmmmmmmm....
Somethings not right because I did what you suggest and it doesn't appear
to be working and by "doesn't appear" I mean it isn't working. I'm creating a derived UsernameTokenManager class and
overiding the AuthenticateToken method so I can authenticate the user to my database but I see no activity on my database
indicating that it is trying to authenticate the user.
--Buddy
Stephany Young wrote: I'm not sure of the finer nuts and bolts of how it actually does it but
what I am talking about is:
The client PC is joined to a domain
The IIS server is on a member server in the same domain
The current user is logged in to the domain
When the web service and, of course, the hosting web site as configured
for Windows Integrated Security, and the url is registered as a trusted
intranet url then what happens is:
Client uses url to access the web site
Web site asks client for authentication information
Client sends current security token to web site
Web site does whatever it needs to do with this and passes request
on to the web service
No security related code is required in the client application.
You can test this by getting a web method to write all the server
variable and/or session variables out to a file and it will show that the web
site/web service knows all that it needs to know authentication wise.
If the web site is exposed to the internet then it is a different kettle
of fish.
"Buddy Ackerman" <bu**********@buddyackerman.com> wrote in message
news:ux**************@TK2MSFTNGP10.phx.gbl...
It is the latter (on a LAN). So, if the current client code (which I
did not write) has the following in it
proxy.RequestSoapContext.Security.Tokens.Add(new
UsernameToken(username, password, PasswordOption.SendHashed));
proxy.RequestSoapContext.Security.Timestamp.TtlInS econds =
TimeToLive;
should I remove this? Will the the client then automatically send the
local security token (as a UserNameToken)?
--Buddy
Stephany Young wrote:
Are we talking about a web service that is 'polled' over the internet
ora web service that is 'polled' over a LAN where the user is already
logged in to the same domain as the web service.
If it is the latter, simply change the web service to allow Windows
Integrated Authentication only and, on the client, add the url of the
webservice to the trusted intranet sites.
"Buddy Ackerman" <bu**********@buddyackerman.com> wrote in message
news:Om**************@TK2MSFTNGP14.phx.gbl...
>My app is a .NET forms app that runs in the taskbar and periodically
>polls a web service. I have a client that wants the app to integrate
>with their Active Directory. They do not want the user to have to
>provide the username and password to login to the application/web
>service. I need to be able to send the users authenticated security
>token to the web service. I have looked at the UserNameToken class of
the>WSE 2.0 Security.Tokens namespace but it requires that you pass it the
>users password which is not available programatically. Is there a way
to>send the security context of the locally logged in user to the web
>service so that it can authenticate the user to the AD without
requiring>the user to enter their username and password into the application?
>
>
>--Buddy
