How to design authentication in a thick client, to be fail safe?

Question

Here's a use case:

I have a desktop application (built using Eclipse RCP) which on start, pops open a dialog box with 'UserName' and 'Password' fields in it. Once the end user, inputs his UserName and Password, a server is contacted (a spring remote-servlet, with the client side being a spring httpclient: similar to the approaches here.), and authentication is performed on the server side.

A few questions related to the above mentioned scenario:

1. If said this authentication service were to go down, what would be the best way to handle further proceedings? Authentication is something that I cannot do away with. Would running the desktop client in a "limited" mode be a good idea? For instance, important features/menus/views will be disabled, rest of the application will be accessible?
2. Should I have a back up authentication service running on a different machine, working as a backup?
3. What are the general best-practices in this scenario? I remember reading about google gears and how it would let you edit and do stuff offline - should something like this be designed?

Please let me know your design/architectural comments/suggestions. Appreciate your help.

Answer 1

The simple answer is: Don't let the authentication service go down!

Make sure your authentication service is running in a clustered, load balanced environment behind a virtual IP. That way, you can avoid downtime in the event that one of the individual servers goes down. This goes for not only the service itself, but any data sources that it relies on.

Obviously no system is completely fail-safe, but you should be able to get your uptime close enough to 100% that there is no need to build a "limited" mode for the desktop client.

Answer 2

Should I have a back up authentication service running on a different machine, working as a backup?

Yes! This would be the best solution. The issue should IMO be dealt with on the network/infrastructure level, not on the client.

If there are useful parts of the application that could still function with no network access (e.g. router down, NIC goes pop), option 1 might be considered. Offset the amount of work necessary against how likely this is and how critical your app is.

Answer 3

If said this authentication service were to go down, what would be the best way to handle further proceedings? Authentication is something that I cannot do away with. Would running the desktop client in a "limited" mode be a good idea? For instance, important features/menus/views will be disabled, rest of the application will be accessible?

Running the desktop client in a limited way is a very good idea. Imagine if you were unable to write an email, perpare attachments, or do anything in an email client if you were not logged in. A good user experience demands the ability to work offline.

Should I have a back up authentication service running on a different machine, working as a backup?

This has been answers very well by others already although I don't agree entirely with dbyrne. Even though all your networks and servers may be running fine, downtime is inevitable and the communication between the desktop client and the server will not always be perfect.

Answer 4

1. If said this authentication service were to go down, what would be the best way to handle further proceedings? Authentication is something that I cannot do away with. Would running the desktop client in a "limited" mode be a good idea? For instance, important features/menus/views will be disabled, rest of the application will be accessible?

Is the client useful without the server? Are there things the user can do? If so, do you want the user to be able to do these things without authenticating? That's the answer to your question.

It isn't clear what you mean when you say: "Authentication is something that I cannot do away with." what you mean. Do you mean that there are some features that require the user to be authenticated, or that it is a requirement imposed by someone else, or ? (Why can't you do away with it?)

1. Should I have a back up authentication service running on a different machine, working as a backup?

How useful is your client in the situation above? If it is very useful, then you can base this decision and how much to spend on maintaining a backup server on how valuable the authenticated features are alone.

If your application is useless without authentication, then base your decision as to how much to invest in a backup authentication server on how much it costs you when your users cannot authenticate.

1. What are the general best-practices in this scenario? I remember reading about google gears and how it would let you edit and do stuff offline - should something like this be designed?

If there is a way to keep useful data offline, I think that's a good idea, but I am biased against keeping my information in the cloud where I can't control it or back it up. It will cost time and implicitly money to develop the ability to do both online and offline versus just one of the two. This is a judgement call on how valuable the application is to your users when offline.