Security (Design) Patterns

[Roger Adams]

Hi everyone!

Are there any security related design patterns used in J2EE environment?

I've got a database containing (very) confidential data. I'd like to disallow certain users to access certain rows from the database, and I'd like to allow certain users to access every row.

Let's suppose we have a table called "Customer". It has 3 fields: ID, Name, Category. The value of Category can be 1 or 2. Let's suppose that there are two user roles called "poweruser" and "normaluser". I want that a "normaluser" can access only those customers that are of category 2, and a "poweruser" can access any customer.

To translate it to J2EE I want that the findAll() method in the CustomerHome (Home of an entity bean) returns all customers if a "poweruser" calls it, and only category 2 if a "normaluser" calls it.

Of course I need a solution that cannot be by-passed by a malicious user. For example the following idea is inappropriate, because it can be by-passed by modifying the data access code/layer:
if userinrole(normaluser)
{
return findByCategory(2);
}
else if userinrole(poweruser)
{
return findAll();
}

So the access control must be somehow enforced with the cooperation of the EJB and DB server (through JAAS, LDAP or anything). If there isn't a general solution, then a Weblogic AS and MSSQL/Oracle DBMS specific one is good, too.

[Dale Seng]

Originally posted by Roger Adams:
Of course I need a solution that cannot be by-passed by a malicious user. For example the following idea is inappropriate, because it can be by-passed by modifying the data access code/layer:
if userinrole(normaluser)
{
return findByCategory(2);
}
else if userinrole(poweruser)
{
return findAll();
}

If the code above is in an EJB, the only way to change it would be for the person to be able to redeploy the bean. If you are worried about your developers getting to data that their applications need to access, you've got a difficult proposition. If you are worried about a normal user somehow getting poweruser status, you have an authentication problem. This is why in many environments, the developers don't manage their own roles (develpers become an 'end-user' when it comes to authentication).

--Dale--

[Roger Adams]

Originally posted by Dale Seng:

If the code above is in an EJB, the only way to change it would be for the person to be able to redeploy the bean.

Ok. Let's suppose I do it like that. Would you put the code above into an entity bean directly, or into a session facade instead? And what if the roles required to access the rows are not known in advance, but can be assigned dynamically after deployment (stored in a table, etc.)? How would you do it?

If you are worried about a normal user somehow getting poweruser status, you have an authentication problem. This is why in many environments, the developers don't manage their own roles (develpers become an 'end-user' when it comes to authentication).

Even if the developers don't manage their roles it does not solve the problem. During development he would simply delete those if-else lines. To return to the original problem my goal is to prevent the users from accessing the db, not the developers.

In one of our older application (a client-server type), we solved it by defining a view for the table. We removed all access privileges from the original table, but allowed everyone to access the view. Every user was connected to the database with his own user id. The view filtered out all unwanted rows from the original table by joining the table with a table containing permission information and with some DB session information (for example user id). This way even if someone could modify the data access code or write his own client sw, cannot see any of the unwanted rows, because it was forbidden in the database level. The problem with this approach in a J2EE environment is that a user does not himself connect to the database, but the connection is acquired from a connection pool. Is it possible to somehow "impersonate" a connection in J2EE?



Problem #2:
We've got another design problem related to the previous one. Our application displays customer information in the browser. For example it displays the account number of the customer. There are some VIP customers, whose account number must not be displayed if the current user is not a poweruser. Where would you do the filtering? In an entity bean, when customer info is retrieved, or in a JSP where it is displayed, or somewhere between the middle? Whose responsibility is it?
[ June 24, 2004: Message edited by: Roger Adams ]