To the author of Enterprise Java 2 Security

[Yuriy Grechukhin]

No doubt that one of the most important aspects of security is the correct design of applications. I was wondering how much time does the book spends on the correct design, and are there any particular design patterns that are recommended by this book?

[Marco Pistoia]

Yuriy,
The book covers how to design an application security in great detail. We recommend the declarative approach, in which security is not hardcoded in the programs but rather configured in the external deployment descriptors and policy files.
Additionally, we explain how to set up all the components (clients, directory servers, firewalls, EJB containers, servlet containers, databases and other legacy systems, load balancers and reverse proxies) to make a better use of Java security.
I hope this helps,
Marco Pistoia

[Nicholas Cheung]

There are many books suggest that we should apply the security constraints to applications using the declarative approach, however, I sometimes wonder how this can be secure that the programmatic approach.
Take *access right* as an example. We can specify a collection of resources, and configure them so that only get or post method, or which user can access it. However, since we also need to code the user alias or we need to provide a whole user list to the app. server, why dont we simply building our ACL in the DB, and load it to the Filter during the application starts? Thus, all checkings can be located in the Filter.
Nick

[Ayesha Bux]

Hi Marco

Is there an Indian edition for your book?

Thanks in advance.

[Nicholas Cheung]

Is there an Indian edition for your book?

I remember Marco said that the book is just released for a few weeks or months only, I think it is too fast for having the translation, maybe it will take some more time to release other languages editions.
Nick

[bas duijzings]

hi,
If you want to provide security in your DB layer you may want to look into Row Level Security. This works as some sort of filter, but then on data level
e.g. when using the following:
Select * from products
it will return the following
Select * from products where userkey=3
drawback to this is that you cannot see the whole sql that is being processed, and therefore you never know if the outcome is correct. It is also more difficult to go into the DB with toad, since you have to bypass the row level security. But this has not much to do with java any more.
Yes, you can load the security in a filter. However we are not using the latest java specs where you can use filters. We loaded a code for businessfunctions in the database and we are checking in the requestprocessor whether the user has read/write access to that function (action). This is our own ACL. programmatic since it is in code. Declarative, since we only have to change the DB for changes in access.
regards,
baz

[Nicholas Cheung]

e.g. when using the following:
Select * from products
it will return the following
Select * from products where userkey=3
drawback to this is that you cannot see the whole sql that is being processed, and therefore you never know if the outcome is correct.

It depends on how you put in the WHERE clause of the SQL.
How about this way:
When the user logins, the Filter or the HttpSession object stores the userkey. For each request, the Filter retrieve the userkey from the HttpSession object and adds this constraint to the request, and thus, when the request comes to the DAO, the DAO adds this constraint into the WHERE clause.
By doing so, the developers or testers can always get a bump or info message about the SQL. And thus, we know the exact SQL during execution.
In fact, it is sometimes that we cannot know the SQL statement in execution. If we want to have better performance on a listing page, we may use PreparedStatement. In such case, your SQL becomes:

SELECT XXX FROM TABLE WHERE YYY=? AND ZZZ=?

Then, we will set the values into the PreparedStatement in runtime by:

ps.setInt(1, YYY_ID);
ps.setString(2, ZZZ_VALUE);

We also have no way to debug it, when the execution of SQL encounters some errors.

Yes, you can load the security in a filter. However we are not using the latest java specs where you can use filters.

One thing to mention is, for using Filter, we do not need the latest J2EE specification. Most of the application servers support Filter, becos it is not new in J2EE 1.4, it has been defined in J2EE 1.3 (Servlet 2.0).
[code]
We loaded a code for businessfunctions in the database and we are checking in the requestprocessor whether the user has read/write access to that function (action). This is our own ACL. programmatic since it is in code. Declarative, since we only have to change the DB for changes in access.

What we are doing now is, for each user (using his ID) to login, we load all his rights from the DB and stored it into the HttpSession object. Thus, within his session, only 1 DB query for ACL compilation. Of course, one drawback is, if we want to revoke his rights during his session, we cannot do so until he logins out. But still, changes in rights in the DB can be refreshed next time.
In the code, we dont need to hard code it as well, because for a certain request, we just need to check with the ACL stores in the session. And we just need 1 call to DB to create the ACL.
Nick

[bas duijzings]

...how you put in the WHERE clause of the SQL..DAO..clause..
please read about row level security before trying to give a lecture, because there where clause is added at database level, not at DAO-java level
Therefore you cant actually see which query is executed.
Your whole answer on performance is (even though correct) is not to the point.
Like I said we are using a spec where we cannot use filters (probably 1.2)

[Nicholas Cheung]

I guess you have some misunderstanding of my post. As I said, it depends on how you put the SQL statement. If you use row level security, the transformation is transparent, and thus, it raise the problem you stated.
Thus, if I am not use the row level security, while I try to use SQL generation with PreparedStatement to authenticate the user so that it avoid the problem you stated(the SQL statement in the execution cannot be seen).
I have never mention the term row security, and I dont think I am giving the lecture on row security, dont you? Cant you understand the focus in my post?
Sorry for making you misunderstood.
Nick

[Marco Pistoia]

Ayesha,
An Indian edition is not available yet. So far the book has been printed only in American English and can be purchased online (from amazon.com for example) also for other countries. As Nick said, the book was published less than two months ago, so it will take some time before it is translated into other languages. When it is translated into other languages, I can at most contribute to the Italian translation :-)
Thank you for your interest in my book.
Marco Pistoia