M
Michael Ames
I have a mechanism for remoting that does authentication for both internal
users with network credentials and external users with custom credentials
simultaneously. I want to describe it here, and get feedback from some of
you smarties on it.
I have custom sinks on the client and the server. The IIS virtual directory
is set to allow anonymous users. The client application sets the
credentials property of the sink chain, just like normal. If they set it to
integrated credentials (like CredentialCache.DefaultCredentials), the client
sink basically passes the call down the chain untouched. The server sink
then checks to see if the credentials are actually present. If not, it
returns an HTTP 401 error, which automatically causes the credentials to be
resent. If at this point the credentials are authenticated and
non-anonymous, we're good to go.
Custom authentication is achieved through the WSE libraries. If the client
app sets custom credentials to the sink chain, the client sink sets the
appropriate hashed SOAP headers first (through the UsernameToken object),
and then passes the call along. The WSE framework then automatically calls
IPasswordProvider.GetPassword (just like a web service) to authorize the
caller.
Advantages:
1. Secure. Names and passwords are encrypted either through IIS's
integrated security mechanism or through WSE.
2. Seamless. Almost all the code is in the client and server sinks,
requiring little customization to the client and server apps.
3. Plays well with others. It shouldn't interfere with other security
settings in web.config, and the same IPasswordProvider.GetPassword
implementation can be used for web services that exist in the same server
app.
What do you think? Good? Bad? Any gaping holes? Better ideas?
Thanks very much,
-Michael
users with network credentials and external users with custom credentials
simultaneously. I want to describe it here, and get feedback from some of
you smarties on it.
I have custom sinks on the client and the server. The IIS virtual directory
is set to allow anonymous users. The client application sets the
credentials property of the sink chain, just like normal. If they set it to
integrated credentials (like CredentialCache.DefaultCredentials), the client
sink basically passes the call down the chain untouched. The server sink
then checks to see if the credentials are actually present. If not, it
returns an HTTP 401 error, which automatically causes the credentials to be
resent. If at this point the credentials are authenticated and
non-anonymous, we're good to go.
Custom authentication is achieved through the WSE libraries. If the client
app sets custom credentials to the sink chain, the client sink sets the
appropriate hashed SOAP headers first (through the UsernameToken object),
and then passes the call along. The WSE framework then automatically calls
IPasswordProvider.GetPassword (just like a web service) to authorize the
caller.
Advantages:
1. Secure. Names and passwords are encrypted either through IIS's
integrated security mechanism or through WSE.
2. Seamless. Almost all the code is in the client and server sinks,
requiring little customization to the client and server apps.
3. Plays well with others. It shouldn't interfere with other security
settings in web.config, and the same IPasswordProvider.GetPassword
implementation can be used for web services that exist in the same server
app.
What do you think? Good? Bad? Any gaping holes? Better ideas?
Thanks very much,
-Michael