Fine Grained Access ERROR on INSERT when generating unique keys

Question

I'm using VPD/Fine Grained Access Control (FGAC) to implement security on my 9i backend. I created a security policy function that returns the predicate 'owner = USER'; - each of the tables has an additional column titled OWNER which contains the name of the logged-in user. Every time a user inserts a record, a BEFORE INSERT trigger fires (for every row) and inserts the USER name into the OWNER column. This is fairly straightforward and ensures that users can see only their rows. Using the DBMS_RLS.add_policy procedure, I attached the security policy to several tables and made it effective upon SELECT, UPDATE, INSERT, and DELETE statements.
However, the frontend Java application (custom-made) generates unique IDs (sequences are not used) by selecting max(ID)+1 from the primary key columns of the tables. The problem is that the predicate is appended to the SELECT max(ID)+1 query to limit the max(ID) to only those rows where 'owner = USER'. Therefore, the max(ID) generated is not the largest ID for the entire table, but only the largest among the USER rows.
So unless that USER happens to have the the largest ID in the whole table (and it has worked then), a primary-key violation error will be returned and the INSERT operation will be aborted.
How can I allow every USER to select from AND get the absolute largest ID from the PK column without allowing that user to select records that don't belong to him? If I had developed the application, I would have made use of sequences on the back-end to generate unique primary key IDs. Unfortunately, I don't have this option and must work with the application as is.
NOTE: the front-end Java application understands only the base table names, NOT Views created by me on the server. If the answer to this problem involves views, how can I make use of them on the backend when the front-end code does not recognize them?
Any help is greatly appreciated!
Michael

Answer 1

first you could use default column values, not a trigger, which is more expensive.
if your apps already assumes full access to table to get max id ( another RT ), this is bad. Current RLS can not really help if you can not change the apps because of this flaw logic ( you can store the maxid anywhere, why scanning the whole table to find it )