application level security

[Cathy Gorchkova]

Hello,
my personal opinion is that one of the biggest problem is application level security. Let us consider simple example. Customer enters orders and the manager approves or rejects orders. Administrator manages personal data of customers and manages. Here are the minimal security requirements for this application:
1. Administrator has no access to business data.
2. Customers and managers has no access to administration data.
3. Manager can approve/reject orders only from specific regions (region is a customer's attribute)
4. Customer can view/update only his orders
Suppose, this is j2ee application. EJB security is not enough, because it does not cover instance level security (points 3 & 4). Moreover, we should protect not only data but servlets(URLs) for points 1 & 2. If our application is integrated with some external system(for example, loading of orders from CSV files directly to database), we need protection on the database level. Does anybody know how to build the consistent security model for such applications? Are there books/tutorials that address these problems? I think this example is *TYPICAL*. Everybody is welcome to share his experience

[Michael Yuan]

I think Liberty Alliance is supposed to address the "access control" aspect you raised.
As of how to protect database data, you should devise an application model that the database is only access from approved J2EE servers. The database should refuse connection requests from any other host. All users, desktop GUI and web UI users, access data through the J2EE application server.

[Patrick Finnegan]

Strange as it may sound the security model for an application is not usually determined by the Application Development Team but by the existing security infrastructure which is integrated with the application server or by a model proposed by the Security Administrators.
For example let's say a WebSphere installation is already in place with an LDAP repository and a DB2 database. Access to various areas of the site is controlled by mapping roles against restricted URIs. Under J2EE role to URI mappings are specified in the EAR through a vendor development tool such as JBuilder or WSAD and then the roles themselves are mapped against groups held in a user repository when the ear is deployed into a vendor application server such as WebSphere. The application server provides the authentication service i.e it detects requests for the restricted URI then prompts for a logon id and password. Successful authentication depends on whether the user is in the required role for that link. The Developers simply specify which URI, servlet or EJB is protected then the Application Server administrators specify which groups have access rights. In this way the authentication mechanism is abstracted from the application and controlled by the App Server.
In your scenario there are four roles.
Administrator
Manager
Customer.
Access rights would be
Administration Data - Administrator Role
Spain - Manager Role1
Italy - Manager Role 2
Customer Data - Customer Role.
Users in the Administrator role have access to the admin data page only.
Users in Manager Role 1 have access to the Spain region page only and Spanish customer data on that page.
Users in Manager Role 2 have access to the Italian region page only and Italian customer data on that page.
Users in the Customer Role have access to their own page which is pulled up when they log on to the site.

[Cathy Gorchkova]

Patrick,
the decision you described is probably the best in terms of current technologies. But this model lacks a lot of things. The ideal variant will be:
- Do not create the role for each country, but create one parameterized role Manager<Country>. (All the roles share the same access rule).
- Do not create the page for each customer. There may be lots of customers and each of them has access to the page with exactly the same structure (but different data).
I also want some consistency checks. I want to be sure that user does not have access to the pages that show not his data. Is this the future? Does anybody work in this direction?