NTD Authentication and Authorization Issues

Greg Robinson has an interesting No-Touch Deployment scenario. From what Greg has said on his blog, and the comments he has posted to my blog (here and here), it looks like he has a couple of interesting security related issues to resolve – the first is how to prevent unauthorized access to the application on the web server, and the second is how to prevent unauthorized use of the application by a recently ‘departed’ employee.

Let’s look at securing the application on the web server and preventing unauthorized users from accessing it…

Securing access to a NTD smart client application is very similar to securing any other web server located artifact, such a web page, etc. The key to securing something on the web server comes down to authenticating the users trying to access it. IIS provides a number of authentication mechanisms, such as Windows Integrated, Digest or Basic, and you can use whatever authentication mechanism is most appropriate to your situation.

[Side Note : However you choose to secure the application on the web server, you will probably want to obfuscate the code to prevent people from reverse engineering it - See Ivan Medvedev’s article about obfuscation]

Once you have selected the desired authentication mechanism and IIS can identify the user via their credentials, you can secure the application and its dependent assemblies by setting the appropriate file permissions on the application’s exe and dll files. Normally you would provide access to a Windows group (say ‘SmartClientAppUsers’) and put individual users into that group. If a particular user is fired, simply remove them from the group and they will no longer be able to download the application.

Note that all authorized users must have a Windows identity on the server side so that IIS can secure access to the application and its assemblies, but they do not need to be logged onto the client machine using this identity. When the user clicks on the link which points to the application’s exe, they will be prompted for a username and password before it is downloaded to the client and run. If you choose to use Windows Integrated security the credentials of the logged on user will be used to try and gain access to the application. This allows for seamless but secure access when the user is logged on with an identity common to both the client and server. If these credentials are not valid, they will be prompted to enter an alternate username and password.

On the other hand, you might choose to enable anonymous access to the application and allow anybody and everybody to download and run it. Once the application is running on the client, though, it will probably need to access the server to obtain data and services before it becomes very useful. Access to data and services through web services, or whatever mechanism, will need to be secured to prevent unauthorized access. There are many ways in which you might secure the web services, but usually you will need the user’s credentials to pass to the web service for authentication. Again, using Windows Integrated security makes this seamless and easy to implement.

Choosing to provide anonymous access to the application but securing most or all of the web services it accesses may be suitable for situations in which you want to make the client widely available but restrict its usefulness or functionality until the user has been properly authenticated. For example, you might have an application which provides basic functionality to anonymous users but allow users to subscribe to a premium level of service where they sign up for an account and get access to more features. A great example of this kind of smart client is Windows Media Player or Napster – you can run either anonymously but you can also sign up for an account and get personalized content and features.

As well as securing access to the application’s artifacts and the services that it interacts with, you might also need to consider additional security checks on the client to prevent unauthorized users from running the application and/or from accessing locally held sensitive data.

If your application provides valuable functionality that you want to protect, then you may want to authenticate users as they start the application. If the application is online, then you can authenticate the user against a remote security authority. If the application is offline, you may need to cache valid credentials on the client so you can re-authenticate the user against them when they start the application. If you do this, you will probably want to enforce online re-authentication after a particular time period to prevent unlimited use of the application.

A smart client application will often cache data that it has obtained from a remote service. This data may be sensitive and, while you might allow an unauthenticated user to run the application, you will definitely want to authenticate them before they access any sensitive data. Again, you can either authenticate the user against a remote security authority when online, or against valid cached credentials when offline. Locally held data will be held in a secure location (for example, isolated storage) and/or encrypted, but however the user is authenticated, you will typically use their credentials in some way to gain access to the data.

In both these cases, you can either use the default credentials that the user used to log into the client machine, or obtain custom credentials which you can use to authenticate the user against a remote security authority. The former is most suitable for applications running in an intranet situation, while the latter is suitable for applications running in an internet or extranet situation where the users are typically not in the same domain as the remote services they access. One of the benefits of using Windows security is that the operating system takes care of authenticating the user, securing the application and local data, and can cache the user’s credentials when the user is offline.

Now let’s have a look at the issue of preventing a recently departed employee from using an application that is already on the client machine…

This is a more complex problem since the exact solution you will need depends heavily on what your application does and how you want it to operate. The key decision is how much you need to restrict the user. You might need to instantly prevent them from accessing the application and/or any local data, or it might be enough to let their authorization time-out, allowing them to run the application for a short time period. In either case, you will most likely be able to prevent them from accessing any remote data and services by removing their authorization on the server side.

To instantly remove a user’s ability to run an application or to access local data, you will need to re-authorize them every time they run the application by making a remote service call to check the user’s status. This means that the application is not likely to offer any offline capability. Since NTD is not really a robust way of providing offline access to an application, this technique may work pretty well for NTD applications.

If you are happy to let the user run the application for a short time, then you may be able to rely on cached credentials or authorization data which times out after a short period. When the user comes to be re-authenticated or re-authorized they will be locked out of the application. Some applications are not useful unless they are able to connect to their remote services, so this model may be all that you need. Remember, you are most likely able to instantly lock users out of remote services so they cannot change or obtain any new data, so allowing user to access the application and its local data may not be an issue.




Copyright © David Hill, 2004.