Web Service and Application Security
My application software is deployed across two tiers; a WinForms workstation client and a Web Services layer. My application will require authentication, however I'm not keen on building my own authentication services into the application. Rather, I'd like to leverage Windows domain security. I can think of three scenarios:
1. The user is logged in to the domain. In this case, I'm assuming that the user's credentials will be used automatically when calling secured web services.
2. The user is not logged in to the internal network. When accessing the secured web service without credentials, will the user be automatically prompted for credentials, or will I need to trap for access denied and solicit credentials myself? I'm hoping that this will work transprently since I'm not interested in getting involved with the solicitation and validation of login credentials.
3. A kiosk scenario: A user is logged in to the domain and the software is running under this session, however this session is merely used to host a running instance of the Winforms Client. In actuality, the logged in user will not have permissions to access the web services at all. In this scenario, I need to facilitate temporary login and then subsequent logout (i.e. application login/logout - the underlying windows session should remain undisturbed) for every temporary user who steps up to the kiosk to use the application. Are there any whitepapers or examples how this can be done?
Thanks very much for any advice which you can provide.
Actually, the default is anonymous access. If you set the Credentials property on the web service proxy to DefaultCredentials, then the proxy will first attempt anonymous access, see that the server requires credentials, and then supply the credentials of the logged on user.
If you want to leave Windows logged on under one account but let users run the application under a different account, then the most straightforward way is to set up a shortcut with the "Run with different credentials" option checked. When the user opens the shortcut, Windows will prompt for alternate credentials and use them to create a new logon session in which the application will run. This of course requires that the machine be on the domain so that it can validate the logon.
If the machine is not on the domain, then it is up to you to solicit and implicitly validate the logon to be used. When the connection fails because the logged on user, say just a local user, does not have permission, you can trap that error, prompt for alternate credentials, and construct a NetworkCredential for the proxy to use, much like IE does. Then your application process is still running as the logged on user, but is authenticating to the server with the specified account.
Hi anfortas,
You say that I can 'trap the error and then prompt for alternate credentials'. While I understand how this can work, I'm still a bit hesitant to take my application down this road. Should my application be in the business of soliciting my customers' domain user credentials? Windows domain services have a very high security rating. There's no way that I can engineer my application to be as secure a custodian for this information. Moreover, why should a customer tolerate a third party application which solicits domain credentials? Who knows what the application is doing with these credentials? And even with the best of intentions, if the third-party application is not securely engineered, it can possibly be used as an entry point to gain access to otherwise secure domain credentials.
If an access fails due to security, isn't there a way to 'pass-the-buck' to Windows itself? To allow the Windows authentication service to take care of the authentication step and then to simply report back to the application that A, the authentication has succeeded, and B, here is the new UserID (but not password, of course) to be used for future access. Wouldn't this be more secure than having my own application solicit domain user names and passwords?
Thanks for your advice,
These are all very good points. If Windows can process the logon for you, then by all means use the shortcut approach. But what if it cannot, say, because the client and server are on different domains with no trust relationship?
Ideally Windows would offer some mechanism to securely collect a logon and create a sort of token for a user who cannot be authenticated locally, which could be used by an application to authenticate remotely through NTLM without revealing the password to the application. If any such thing is possible today, you would probably have to write a service and get your hands really dirty in the OS. Maybe someday InfoCard will improve our plight.
What the Windows shell and Internet Explorer do when faced with this very problem, accessing a protected network share or web site, is to handle the collection and application of credentials at the application level, though still relying on the server OS for authentication, storage, management, etc. It is true that the system otherwise strives for a single sign-on protected with Ctrl+Alt+Del, but sometime that just isn't enough.
Yes, divulging any credentials to any application is inherently a bit risky. But allowing a user to securely authenticate to a remote server is a fundamentally hard problem.
One alternative worth mentioning, for this scenario where a user out there has his own laptop that is not on the domain, is client certificates. There is still the theoretical risk of your application having access to the private key, but once the client and server are set up with the certificate there is no need to prompt for a logon, and the server can choose to map client certificates to Windows accounts.
