I am doing a client-server application and with server app both in web and local network.
In my application,i need user authentication.I need five user security levels.and functionalities of the application is restricted according to user secrity levels.for eg: admin will access all functionalities,and trial user will be restricted to some of functionalities.and all the clients will get the same application in client-side.so restriction is based on their authentication.
The client is not a brawser.It's a swing app.
What i actually need is,i want to restrict some users from accessing some database tables.
I dont like to create user in database(there will be a users table,but i mean dont like to create db permissions to each users).But i wanna do it in java layer.Since the client is similer to all security level users,which pattern will be ideal to tackle this situation?.
I am thinking abt creating a 'user state' variable in client application,which server will return after authentication.so i can disable some buttons for some users.
But any other good patterns for it?.
I need some 'user' security level patterns and advice in serverside.I need some alternative thoughts and advice. [ June 21, 2004: Message edited by: Murasoli Maran ]
There was a question like this a while ago, I think, and some ranchers were able to cite some authorization tools. I can only reference my own project experience. On the last three or four apps, we've had good luck saying a user can have any number of roles, and roles can grant access to any number of resources. We make a resource (just a string name in a row in a database) for anything one user can do that another cannot. When it comes time in code to do something we query a simple API that tells if the current user can access the associated resource.
I'm currently using a vendor framework that for each role-to-resource linkage has grant or deny create, read, update or delete access. If there are two paths from user->role->resource a "deny" link wins over a "grant" link. All that may be overkill.
One thing we learned the hard way is to have the role in the middle. We tried authorizing by testing user group. If user in group A they can do this. Wait, there's a new group B that can do some of A's things but not all of them. Touch some but not all points in code to say if user in group A or B but not C. Bad.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi