views:

199

answers:

3

Hello guys,

We are programming a three tier application with a rich GUI client using swing and we need to add some authentication and authorization control. I'm completely new in this topic so I made a bit research in the web. My first intention was to use JAAS for this feature, but as far as I can see, JAAS only contains functionality to execute privileged methods/actions, but there seems to be no functionality to determine whether the access is granted for some "Actions" to control the GUI. e.g. hide/disable some menus etc.

Do I understand this wrong or is my approach wrong? Are there any alternatives to JAAS? Does any "best practice" exist to add authentication and authorization to GUI applications?

Thanks for help, Eny

+2  A: 

A rich GUI client is no different from a standard website. Both are client side, and in control of a potential attacker. So no matter what security you think of, a determined person can break it. Remember that the whole idea of hiding/disabling buttons on UI is Usability, not Security.

To start with, show all buttons to all users, but make sure that if a normal clicks on the admin button, the server doesn't allow it. Once you get your server side authentication right, add shims to hide/disable buttons on the UI. For this, you can write a service that returns the roles/priviliges the logged in user has.

JAAS is a perfect technology for server side authentication. You should be able to find a lot of documentation to protect server resources.

Your users will have to login to the Swing GUI, and must be authenticated by the server. This is the most important step. If you don't authenticate the user with the server, then its no security at all.

Thereafter, every button click, ever user action goes to the server which authenticates if the user has permission. If he doesn't, throw an exception back to the client. This way, if someone enables your buttons by some trickery, the server will catch it.

sri
So do I understand it correctly, that you suggest to implement the JAAS on the server side?The server works with a WebService, in this case I would need to pass the authentication information every time a WebService routine is called, or I would need to maintain the LoginContext over long time on the server, what we don't want.
Enyra
Don't pass the loginid/password with every request. Instead, just pass a session identifier/token, even the regular jsessionid would work. You can choose to expire the session after a period of inactivity, in which case you don't have to maintain LoginContext for long (but the user would have to login again). Or you can keep them long-lived, in which case you'd have to persist the session identifier in a database.
sri
A: 

While @sri's answer makes some good points the advice to 'just pass a session identifier/token' is dangerous because it's too easily spoofed. You need establish a common context that is verified by a trusted source. Take a look at org.ietf.jgss.GSSContext for details on this.

In order to get a GSS context working you'll come into contact with the concept of a Key Distribution Center (KDC), which normally lead to Kerberos and normal some sort of directory server - sorry I'm being a bit vague but without knowing just what you have in place it's hard to be specific and even then I've only done this with Active Directory.

Once you've got everything authenticating you can return to your original point of protecting certain functions.

The authentication process will provide with a javax.security.auth.Subject, which will contain one or more java.security.Principals. These principals can be used with JAAS to create a policy file that uses the principals as described here. Typically you use a principal to represent the roles a user has which are loaded from a directory server. In the past I've specialized the login module to do this, although there may be a better way.

That has everything locked down, so the final step is to make it look pretty to the user and here, to the best of my knowledge, you're on your own. You could simply leave everything enabled and warn the user if the operation cannot be performed or, as you've got the subject do something more sophisticated based on group membership.

Nick Holt
A: 

Use JAAS

JAAS is a generic framework and would not give any application specific features such as disable/enable buttons etc. you will have to embed that authorization logic into your application, JAAS provides you a handle to the authenticated/authorized Principal object that comes handy in such scenarios.

ring bearer