How do I use Oracle Database Security in my HTML DB App?

Question

I have an existing client server application that each user has a database account. These accounts are set up currently to allow and disallow appropriate access to data via Database Rolls. I want to augment the client server application with a HTML DB application and want to use the already created database accounts. Can this be done?

Answer 1

Chris,
HTML DB parses the SQL and PL/SQL in your application as the "parse as" schema, or owner, of the application. The new database session created for each page view runs for the connected user HTMLDB_PUBLIC_USER (for DADs with stored credentials) or for the user authenticated by the basic authentication challenge (your situation).
You can access the USER pseudo-column within the session to set audit columns with the name of the connected user. This is not the name of the application schema.
Basic Authentication is not the only way to authenticate against database accounts. You can easily implement a login page of your own with a PL/SQL process that checks the user's credentials against the database account. Our team implemented HTML DB extensions to (and ultimately replacements for) a very complex Forms-based system having an architecture probably very similar to yours. In this environment we would set the APP_USER item to the authenticated username and use it for audit columns and for authorization checks within the application. During this 2-year project, we adopted a couple of best practices that you might want to consider: 1) All DML is performed using table-level APIs (which are easy to generate automatically), and 2) Table-level APIs are called only from transaction-level APIs, which often involve multiple calls to table-level APIs. We would implement all authorization checks at the transaction level, either within the APIs themselves, or also on the HTML DB controls around them (buttons, processes, etc.). Abstracting the security rules away from the database objects allowed them to be formulated in terms of business processes and relates them more closely to the logical data model.
That's an approach you can think about. If you do continue to use basic authentication and direct or role-enabled object privileges, you can still make your DML, triggers, and APIs user-aware as I noted above or by using invoker's rights packages/procedures.
Finally, HTML DB is not a client-server emulation tool. Its security model facilitates flexible and secure database access appropriate for a declarative development environment (possible hosted) and application deployment to web-based users.
Do let us know if we can help with specific issues as you go forward.
Scott