How to implement Administrator rights in Java Application?

I am developing a Data Modeling Software that is implemented in Java. This application converts the textual data (stored in a database) to graphical form so that users can interpret the data in a more efficient form. Now, this application will be accessed by 3 kinds of persons:

1. Managers (who can fill the database with data and they can also view the visual form of the data after entering the data into the database)

2. Viewers (who can only view the visual form of data that has been filled by managers)

3. Administrators (who can create and manage other administrators, managers and viewers)

Now, how to implement 3 diff. views of the same application.

Note: Managers, Viewers and Administrators can be located in any part of the world and should access the application through internet.

One idea that came in my mind is as follows:

Step1: Code all the business logic in EJBs so that it can be u开发者_开发问答sed in distributed environment (means which can be accessed by several users through internet)

Step2: Code 3 Swing GUI Clients: One for administrators, one for managers and one for viewers. These 3 GUI clients can access business logic written in EJBs.

Step3: Distribute the clients corresponding to their users. For instance, manager client to managers.

=================================QUESTIONS=======================================

Q1. Is the above approach is correct?

Q2. This is very common functionality that various softwares have. So, Do they implement this kind of functionality through this way or any other way?

Q3. If any other approach would be more better, then what is that approach?

1. no
2. no
3. yes

Making different clients for different security roles is a :

• security hole - what if a viewer obtains the administrator version?
• hard to maintain

The way to do this is:

• make the data transferred to the client dependent on a security check
• also make various parts of the UI visible/enabled depending on that security check
• the security check is made on the server
• the security check depends on the currently logged user
• the user logs in on startup, using his credentials (username/password or digital certificate)
• the security roles (administrator, moderator, viewer) are stored on the server side.

Then, if needed, you can extend the security model by adding:

• differentiation between per-user and per-role rights
• rights on specific resources
• transitive rights
• permissions for specific actions

But such a complex user rights and security model is perhaps not needed in your application.

I agree with @Bozho except for the following:

make various parts of the UI visible/enabled depending on a security check

You actually need to make sure that unwanted access to the data, etc is blocked on the server side, irrespective of whether the client-side UI is visible / enabled. The reason for this is that any client-side UI disabling code can be subverted. Indeed, a bad guy could even entirely bypass your UIs and reverse engineer the application-specific protocols between your client and server code.

This is not to say that you shouldn't also disable / hide parts of the UI that the user is not allowed to use. It is just not a good basis for decent security / access control.

(UPDATE : @Bozho has ammended his answer now to add server-side blocking to his list. So I now agree with it entirely. )

I agree with Bozho. Another points with the three client approach is: what if the user somehow figures out how to send the operations which isn't available in his client? What if the same user has two roles (hence is required to have two clients). And of course you will have plenty to do maintaining one client...