.NET Remoting and Credential Caching

[Michael Bray]

I have a client/server application that utilizes Impersonation on a TCP
Channel. So I create the channel with the version of the constructor
that takes an IDictionary of channel properties, and specify
"impersonate = true".

OK great - everything works - I can confirm on the server that the
process runs in the context of the user that is making the remote call
from the client.

However, I also want to give the user the ability to specify the
credentials to use - so in the user interface I give a checkbox that
says "Use pass-thru authentication" and if they check it, it runs as
above, and if the uncheck it they can enter a username, password, and
domain, which I then specify in the channel properties of the same name.

OK great - this works too... I can specify the username and password,
and verify on the server that the connection runs as the user I've
specified.

BUT... when I switch between the two in the same instance of the
application, only the FIRST connection's credentials get used. So if I
select "Use Pass-thru" then on the server it shows the user that I'm
running the client as. If I then disconnect (and yes, I also Unregister
the channel), then change the option to specify the username and
password, and then reconnect, the connection is still successful, but as
the user that I'm running as. In fact, I can put anything I want, even
an invalid username and/or password, and it still connects as the user
I'm running as. It works the same way if I first connect as a specified
user - subsequent requests to connect with pass-thru authenticate only
as the user I entered.

Obviously there is some credential caching going on here... Is there a
way to disable this? I'm aware of socket caching, which I believe I
have disabled (using 'socketCacheTimeout=0' and
socketCachePolicy=absoluteTimeout') but it appears to still be caching
the credentials. I am also unregistering the channel before I re-
register the TCP channel with the new properties.

Any help? Thanks!

-mdb

 

[Mr. Arnold]

I have a client/server application that utilizes Impersonation on a TCP
Channel. So I create the channel with the version of the constructor
that takes an IDictionary of channel properties, and specify
"impersonate = true".

OK great - everything works - I can confirm on the server that the
process runs in the context of the user that is making the remote call
from the client.

However, I also want to give the user the ability to specify the
credentials to use - so in the user interface I give a checkbox that
says "Use pass-thru authentication" and if they check it, it runs as
above, and if the uncheck it they can enter a username, password, and
domain, which I then specify in the channel properties of the same name.

OK great - this works too... I can specify the username and password,
and verify on the server that the connection runs as the user I've
specified.

BUT... when I switch between the two in the same instance of the
application, only the FIRST connection's credentials get used. So if I
select "Use Pass-thru" then on the server it shows the user that I'm
running the client as. If I then disconnect (and yes, I also Unregister
the channel), then change the option to specify the username and
password, and then reconnect, the connection is still successful, but as
the user that I'm running as. In fact, I can put anything I want, even
an invalid username and/or password, and it still connects as the user
I'm running as. It works the same way if I first connect as a specified
user - subsequent requests to connect with pass-thru authenticate only
as the user I entered.

Obviously there is some credential caching going on here... Is there a
way to disable this? I'm aware of socket caching, which I believe I
have disabled (using 'socketCacheTimeout=0' and
socketCachePolicy=absoluteTimeout') but it appears to still be caching
the credentials. I am also unregistering the channel before I re-
register the TCP channel with the new properties.

Any help? Thanks!

I myself think you need to abandon this credential checking using the
Remoting application. It may come down to using one or the other but not
both. The one .Net Remoting application I have written was using SQL Server
table authentication using a user-id and password. Sometimes, it's best just
to keep things simple.

 

[Michael Bray]

I myself think you need to abandon this credential checking using the
Remoting application. It may come down to using one or the other but
not both. The one .Net Remoting application I have written was using
SQL Server table authentication using a user-id and password.
Sometimes, it's best just to keep things simple.

Unfortunately it is a requirement to support both. I know there must be a
solution buried deep down in the framework somewhere.

-mdb