Design question: Dynamically changing GUI -> sending implementation classes as soap attachments.

Question

Here's a scenario: I have a java front end (RCP/SWT) app which currently has no authentication support. I have to however, add security to this application so that it gets deployed in different enterprise envinronments. I have a few approaches which I thought I would share with you all here and take your inputs. Please note that there are no strict requirements yet, so.. I would like you to consider typical and non-typical enterprise network security models.

Approach 1

• Create a 'Security' webservice that the thick client would invoke, on startup.
• The client queries the security for the current authentication mode and receives the implementation class of the authentication as a soap attachment. The class received, will not have the logic for authencation, rather it would just describe the UI and the events on the UI. (The client could make use of a GUI toolkit such as Thinlet?)
• Once the class is loaded, a UI relating to the currently set authentication method is displayed to the end user.

Advantages:

• This approach lets me handle different authentication schemes. For instance, if the app has to authenticate against user names and passwords stored in a database, a screen with UserName and password fields would suffice. However, say the user were to do a network logon that would involved typing in the network name, the UI would contain three fields. If the security model at the client network dictates ntlm/SSO based authentications, the user won't see a UI. This will also leave scope for future authentication methods - for instance, supporting a captcha specific logon screen/ biometric stuff / whatever.

Approach 2

KISS (Keepin in yea.., Simple)

• User name and password are usually the only two credentials required by all of the known authenticating mechanisms?
• Have the thick client query the webservice and let the webservice handle the entire authentication process.

I am not sure how realistic/feasible/commonly used the above mentioned approaches are. Appreciate your help.

Answer 1

I'd certainly not recommend transmitting class definitions as SOAP attachments. A network classloader would make more sense, but is still not needed in your situation.

Put in the client what belongs there - the UI. Have the multiple screen types ready (i.e. defined as classes) on the client and activate each of them depending on a single value passed by the server. For example if AuthenticationType.CREDENTIALS is passed, go for username/password. If Authentication.SMART_CARD is - go for smart card.

If you want to distribute the application and later implement different auth screens, then use Java Web Start. Thus all clients will be guaranteed to be running the latest version.

After knowing that your requirements impose some limitations, take a look at this network classloaders article.

Answer 2

@Bozho

However, your suggested approach still requires installing/writing UI knowledge at the application before going live. Which means the application code has to be edited/updated everytime a new auth logic is to be implemented. I believe what the authr is trying to avoid.