What's the best way to do authorization for my app?

Question

The authorization situation is somewhat complicated for my app.
Each component of the app is authorized based on not only the user, but also the page number, the value of at least one P0_ITEM.
From what I've seen so far, there are two different options of setting the authorization for the component:
1. Set its Condition
2. Set its Security Authorization Scheme
Here is my understanding for each (from my limited experience with APEX):
1. Set its Condition
+ Can pass in parameters such as :APP_USER, page numebr, P0_ITEM. So I can just create one function that does all the authorization
- Have to combine the SQL query with the component's non-authorization display conditions, if any.
2. Set its Security Authorization Scheme
+ By name, it seems like it should be used for authorization
- Cannot take in parameters relating to the page, such as the page number --> therefore I will need to create many different schemes, for all the different pages.
#2 will end up with a long list of schemes (each with its own SQL queries) for different pages, which doesn't seem as efficient as #1 with far fewer SQL queries and just take in parameters.
Which one should I pick?
Thanks!

Answer 1

953006 wrote:
Thanks fac586 for the detailed response, and also everyone else who replied. You guys are very helpful and respond promptly. And we'd appreciate it if you changed "953006" into a real handle promptly.
Andre mentioned using conditions:
The way I work around this is to have two functions, one which is used at the page level as a normal authorization scheme and one which can be passed variables which is called as a Condition and the name of the item is one of the variables, in effect giving it "self awareness".But fac586 said:
You can't pass "parameters" to authorization schemes. Use application items, APEX collections or application contexts to set current context before the authorization scheme is evaluated, and access these values in the functions.Does this mean, fac586, that we can avoid conditions altogether? No, it means that I prefer to use Authorization Schemes to control access to resources based on user privileges and security, and Conditions to control rendering and processing for functional reasons. Using the approach described above I have found it possible to maintain this separation.
Say if a page has two buttons, Button_A and Button_B. Button_A has a set of requirements for displaying and Button_B has its own set of requirements (some of which are shared with Button_A). So far, the only way that I can see of using pure authorization is to write 2 different authorization schemes, and set the authorization schemes for the two buttons respectively.What's the problem with that? Consider a more concrete example using a standard APEX report/form pattern for customer maintenance. Page 6 contains the report, and page 7 is the maintenance form with P7_CREATE and P7_SAVE buttons. Only users entitled to create new customers should have access to P7_CREATE, and only users able to edit customers access to P7_SAVE. This would be controlled by the CREATE_CUSTOMER and EDIT_CUSTOMER authorization schemes respectively. Functionally, conditions are used to show P7_CREATE if the P7_CUSTOMER_ID is null, and P7_SAVE if it's not null. We don't mix non-functional security considerations with functional requirements.
The CREATE_CUSTOMER and EDIT_CUSTOMER authorization schemes are of type PL/SQL Function Returning Boolean. These are implemented using package functions. Exactly how a user has create/edit customer privilege is determined in the package. Determinants that are shared by multiple schemes can be combined at this level. These implementations can be changed as necessary without requiring changes to the application.
The authorization schemes are reusable across pages and components. On page 6, CREATE_CUSTOMER can be used on the "Create New Customer..." button; EDIT_CUSTOMER on the report column containing the "Edit" links.
Each component of the app is authorized based on not only the user, but also the page number, the value of at least one P0_ITEM. So I guess this goes back to my original concern with Authorizations:
[Using purely authorizations] will end up with a long list of schemes (each with its own SQL queries) for different pages [and page items] ....
Re: VPD policies. Note that in the example above there's no need for the authorization schemes to "know" which pages/items are being evaluated. The P7_SAVE button and the page 6 link column are involved with the EDIT_CUSTOMER operation, so that authorization scheme is applied to them.